Delphi-PRAXiS
Seite 3 von 3     123   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   Delphi FMX-Styles? (https://www.delphipraxis.net/174552-fmx-styles.html)

greenmile 1. Mai 2013 22:34

AW: FMX-Styles?
 
So langsam schaut es so aus, als wenn ich mit dem ssFrameWork einige nervige Bugs vom FM umgehen kann. Wird spannend ... Und vielleicht wird es ja, wie bei Delphi bekannt, irgendwann mal aufgekauft. ;)

stahli 1. Mai 2013 23:11

AW: FMX-Styles?
 
:bounce2::angel2::drunken::stupid::spin2::bounce2:
Jetzt kann ich nicht einschlafen und muss morgen früh raus... :-)

stahli 5. Mai 2013 11:09

AW: FMX-Styles?
 
Liste der Anhänge anzeigen (Anzahl: 1)
Ich habe jetzt mal versucht, den Stil-Designer zu verwenden. :-(
Kennt jemand Videos dazu (für FMX unter XE3)?
(in XE2 sah das ja noch anders aus)

Ohne Hilfe ist das für mich nicht zu durchschauen.
Außerdem scheinen die Positionen der Graphiken irgendwie nicht zu passen.


@MEissing:

Wie wäre es mit einem Webinar konkret zu der Verwendung der FMX-Styles (unter XE3/4!).
Immerhin ist das doch eine Emba beworbene neue Arbeitsweise...

Wünschenswertes Beispiel für eine neue Komponente, die einen Zahlenwert zur Bearbeitung bereit stellt.:
Diese soll rechts drei Buttons haben (möglichst auch mit eigenen Bitmaps und Effekten, damit man das auch mal sieht).
Pfeil hoch und runter (wie Spinbuttons) und dazwischen einen dritten, der ein Formular aufruft (z.B. einen Rechner).
Links soll ein Schalter sitzen, der das Vorzeichen (+/-) wechselt.
Außerdem soll der Zahlenwert optional editierbar sein (CanEdit = True).

Die Komponente soll in sich geschlossen sein (also überall einsetzbar, Datenbindung ist nicht notwendig) und unter verschiedenen Styles funktionieren.

Kannst Du mal zeigen, wie und ob bzw. wie weit sich so etwas umsetzen lässt?
Ich kann mir vorstellen, dass daran allgemein Interesse bestehen würde.

stahli 5. Mai 2013 22:37

AW: FMX-Styles?
 
Mein Problem mit den Styles beschreibe ich auch hier: http://www.delphipraxis.net/173360-s...ml#post1214250

stahli 6. Mai 2013 19:50

AW: FMX-Styles?
 
Aus der Hilfe:

Zitat:

Verschachtelte Stile

Stile können auf andere, mit Stilen versehene Komponenten verweisen. Wie üblich werden Stile im TStyleBook-Objekt anhand des Namens ihrer obersten Ebene gefunden. Um beispielsweise denselben Verlauf zu verwenden, gehen Sie folgendermaßen vor:
1. Speichern Sie im FireMonkey-Stil-Designer die vorhandenen Stile in einer .style-Datei.
2. Bearbeiten Sie diese Datei mit einem Texteditor, um ein TBrushObject zu erstellen. Verwenden Sie einen geeigneten StyleName.
3. Laden Sie die .style-Datei.
4. Wählen Sie den neu definierten Stil aus, damit er im Objektinspektor angezeigt wird.
5. Öffnen Sie die Eigenschaft Brush: 1. Bearbeiten Sie die Eigenschaft Gradient mit dem Pinsel-Designer (wählen Sie im Dropdown-Menü des Eigenschaftswertes Bearbeiten).
2. Setzen Sie die Eigenschaft Kind auf bkGradient.

6. Führen Sie für jede Komponente, die den Verlauf verwendet, Folgendes aus (z.B. für die Eigenschaft Fill von TRectangle): 1. Setzen Sie die Eigenschaft Kind auf bkResource.
2. Öffnen Sie die Eigenschaft Resource (eine TBrushResource) und setzen Sie StyleLookup auf den in Schritt 2 festgelegten Namen.


Suchreihenfolge für Stilressourcen

Ein Steuerelement sucht nach einem Stil anhand der folgenden (näherungsweisen) Suchsequenz und hält bei der ersten Übereinstimmung an:
1.Wenn die Eigenschaft StyleBook des Formulars gesetzt ist, wird dieses TStyleBook anhand zweier Namen durchsucht: 1.Der Eigenschaft StyleLookup des Steuerelements, sofern gesetzt.
2.Ein Standardname, der aus dem Klassennamen des Steuerelements gebildet wird: 1.Der erste Buchstabe (das Präfix 'T' im Standardschema zur Klassenbenennung) wird weggelassen.
2.'style' wird hinzugefügt.


2.Die fest codierten Standardstile werden anhand von drei Namen gesucht: 1.Der Eigenschaft StyleLookup des Steuerelements, sofern gesetzt.
2. Der Standardname, der aus dem Klassennamen des Steuerelements gebildet wird.
3. Ein Standardname, der aus dem Klassennamen des übergeordneten Steuerelements nach demselben Muster gebildet wird.


Zum Beispiel lauten die Standardnamen für TPanel "Panelstyle" und "Controlstyle". Für TCalloutPanel lauten die Standardnamen "CalloutPanelstyle" und "Panelstyle".

Die Namenssuche berücksichtigt die Groß-/Kleinschreibung nicht. Wenn keine Übereinstimmung gefunden wird, hat das Steuerelement keinen Inhalt und ist eigentlich nicht sichtbar. Code, der vom Auffinden von Unterkomponenten abhängt, schlägt fehl. (Dies dürfte nur bei unvollständigen oder inkorrekt zusammengestellten, benutzerdefinierten Steuerelementen vorkommen, weil alle integrierten Steuerelemente über zugehörige fest codierte Stile verfügen. Direkte Nachkommen von integrierten Klassen hätten den Inhalt ihrer Basisklasse; Nachkommen der zweiten Generation wären leer.)

Formularstil

Obwohl TForm kein Steuerelement und keine Unterklasse von TStyledControl ist, kann TForm dennoch ein Stil zugewiesen werden. Die Eigenschaft StyleLookup eines Formulars hat den Standardwert "backgroundstyle". Die Standard-Stilressource mit diesem StyleName ist ein graues TRectangle-Objekt.

Die Eigenschaft Align der Ressource wird beim Laden auf alContents gesetzt, um den Hintergrund des Formulars damit zu füllen. Dies ist das erste Objekt, das gezeichnet wird, vor den anderen untergeordneten Objekten des Formulars.
Somit wird klar (sofern ich das richtig interpretiere), dass die "Notlösung" über einen Texteditor der offizielle Weg ist.
Insofern ist auch nicht zu erwarten, dass Emba ein schickes Video über das perfekte und unkomplizierte Erstellen einer neuen Komponente erstellen wird. :-(

Hinzu kommt, dass der Bitmap Stil Designer auch nicht besser funktioniert. Wenn man von dem aus dann einen Style exportiert (z.B. wegen einem überarbeiteten png) werden die mühselig erstellten eigenen Stile überschrieben bzw. gelöscht.

Aus der Hilfe wird auch erkennbar, warum Ableitungen von Komponenten plötzlich "falsch" oder gar nicht mehr gezeichnet werden.

Also entweder ist das Konzept totaler Blödsinn oder es bedarf einer grundlegenden Erklärung.
Auf Grund der gesammelten Erfahrungen denke ich, dass sich das Konzept nicht halten wird.

Wenn Emba das mit einem Video widerlegen könnte, wäre das natürlich super.

Union 6. Mai 2013 20:07

AW: FMX-Styles?
 
Also ich gleube mich zu erinnern dass es bei der CR eine Präsentation gab, wo eine Komponente ausschließlich mithilfe der Bordmittel erstellt wurde.

stahli 6. Mai 2013 21:31

AW: FMX-Styles?
 
Danke für den Link.
Meine hauptsächlichen Fragen werden aber leider nicht beantwortet.

Wo kommt z.B. bei 18 min der newstyle1 her? Den muss er wohl über einen Texteditor hinein gezaubert haben - oder?
Und was passiert mit der LED-Komponente bei 27 min, wenn ich sie in ein neues Projekt setze und keinen passenden Style dazu lade (oder mich später für einen anderen Style entscheiden will) - ist sie unsichtbar?.
Letztlich noch die Frage, wie bekomme ich neue Bitmaps (z.B. für diverse Schalter in einer eigenen Komponente) in einen eigenen Style definiert und verwende diese?

@Matthias: ?

Union 6. Mai 2013 22:16

AW: FMX-Styles?
 
Man kann Stile hinzufügen über die Komponentenpalette. Also z.b. einen TButton auswählen und den in die TStyleContainer-Struktur in den Baum ziehen.

stahli 6. Mai 2013 22:44

AW: FMX-Styles?
 
Ahhh! Danke!
Das hilft schon mal bei ein paar Aspekten weiter. :thumb:

stahli 7. Mai 2013 09:39

AW: FMX-Styles?
 
Mal eine Überlegung:

Wäre es nicht sinnvoller, wenn die StyleObjekte (Layouts, Rects, Texte, Bitmaps etc) direkt in der Komponente hinterlegt wären (als Bestandteile der Komponente) und zur Laufzeit lediglich passende Fülleigenschaften für Flächen und Rahmen und Effekte aus dem zugewiesenen Style verwendet würden?

Im Resultat hätte man geschlossene Komponenten (wie in der klassischen Weise), nur dass man die mit einem Designer designen könnte.
Ggf. könnte man regeln, dass sich Komponenten nachträglich weitere Styles zuweisen und dann wechseln lassen (dann aber immer gekapselt IN einer Komponente).

Die gewählten Styles hätten dann Auswirkungen auf die Optik aller Komponenten (im Sinne eines Skinnings).

Man hätte so nicht das Problem, dass Komponenten plötzlich nicht mehr gezeichnet werden wenn man einem Projekt einen neuen Style zuweist oder dass Komponenten optisch nicht zueinander passen.


Alle Zeitangaben in WEZ +1. Es ist jetzt 14:56 Uhr.
Seite 3 von 3     123   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz