Korrekter Umgang mit Delphi Styles und eigenen Komponenten

[TiGü]

Zitat von Whookie:

Damit befinden sich aber jetzt auch neue Elemente im Style die vielleicht gerade von deinen eigenen Erweiterungen überschrieben wurden (die älteren png's in den Styles hatten rechts-unten ein bischen Freiraum, der ist jetzt weg).

Und was interessiert mich das in meinen eigenen Style?

Nochmals:
Meine VSF-Datei wird nicht über Project Options -> Application -> Appearance in das Programm eingebunden.
Die VSF-Datei wird vom Installer in das Programm-Verzeichnis gelegt.
Das Programm lädt diesen Style bei Vorhandensein.

Im Style selber sind die Elemente (die Objects im Bitmap Style Designer) und deren Aussehen (Images -> style.png) fix und fertig einkompiliert.
-> Die VSF-Datei selber ist wie eine DLL.

Da können die bei Embarcadero in den zukünftigen XE-Versionen ja fröhlich weitere Objects in ihre mitgelieferten Styles einfügen und das Style.png ergänzen, dass ist von meinen eigenen Style ganz unabhängig!

[TiGü]

Zitat von Whookie:

Zitat von mkinzler:

Da ist aber kein Unterschied zu einem konmplett selber entwickelten Skin.

Dann schon wenn du etwa Komponenten von drei verschiedenen Herstellern hast und die auf die Idee kämen alle "ihren Eigenen" Style mitzuliefern ... dann kannst du nämlich schlechtestenfalls nur mehr von einem Drittel deines Programms das aussehen bestimmen...

Wie soll das gehen?
Es kann in der gesamten Applikation nur ein Style geladen werden, oder habe ich irgendwas übersehen?

[Whookie]

... ja genau das ist das problem (oder eben nur mangelndes know how) ...

[TiGü]

Warum ist das ein Problem?
Es wäre äußerst ungünstig, wenn mehrere Styles für verschiedene Komponenten geladen werden könnten.

[Whookie]

Zitat von TiGü:

Warum ist das ein Problem?
Es wäre äußerst ungünstig, wenn mehrere Styles für verschiedene Komponenten geladen werden könnten.

Das will ja auch keiner. Vieleicht versuche ich es noch mal zu erklären, ich glaube nämlich, dass noch nicht ganz klar ist, worauf ich hinaus will.

1. Hersteller A hat eine Komponentenbibliothek und liefert für jeden Delphi Style einen Zusatz (etwa in Form von "Styleerweiterungsdateien: zB.: Amakrits_A.vsf, AmethystKamri_A.vsf, ... , SmokeyQuartzKamri_A.vsf, TurquoiseGray_A.vsf).
Diese Styledateien enthalten NUR Styledaten die für die Bibliothek relevant sind aber KEINE Allgemeinen Daten wie für TForm usw..

2. Hersteller B hat auch eine Komponentenbibliothek und liefert dafür auch entsprechende Dateine (Amakrits_B.vsf, AmethystKamri_B.vsf, ...

3. Wir kommen zu Hersteller C der hat dann: Amakrits_C.vsf, AmethystKamri_C.vsf, ...

4.
Du selber hast auch noch eine tolle Komponente und machst dir auch entsprechende Dateien (also Amakrits_Z.vsf, AmethystKamri_Z.vsf, ...

5.
Bei der Installation der Komponentenbibliotheken der drei Hersteller bei dir am PC registrieren sich nun die Erweiterungen jedes Herstellers ZUM dazugehörigen Delphistyle (also Amakrits_A, Amakrits_B, Amakrits_C und Amakrits_Z bei Amakrits.vsf; AmethystKamri_A, AmethystKamri_B, AmethystKamri_C, AmethystKamri_Z bei AmethystKamri.vsf usw.

6.
Jetzt kannst du als Programmierer deine Applikation erstellen und ein Fenster designen in dem du sowohl ein paar Delphi Komponenten als auch welche von Hersteller A von Hersteller B von Hersteller C und natürlich auch deine eigene verwendest. Du wählst dir 2-3 Styles aus zwischen denen dein Anwender wählen kann und erstellst die Applikation.

Damit sieht dein Fenster wie aus einem Guss aus, obwohl es visuelle Komponenten von 5 verschiedenen Quellen enthält und wenn der Anwender den Style ändert funktioniert das auch.....


... die Frage ist, gibt es eine Möglichkeit sowas zu bewerkstelligen bzw. wie mit der obigen Situation umgegangen werden muss...

[TiGü]

Zitat von Whookie:

1. Hersteller A hat eine Komponentenbibliothek und liefert für jeden Delphi Style einen Zusatz...

... die Frage ist, gibt es eine Möglichkeit sowas zu bewerkstelligen

Das geht nicht, wird es nicht geben und ist auch nicht sinnvoll!

Zitat von Whookie:

bzw. wie mit der obigen Situation umgegangen werden muss...

Als Komponentenhersteller oder als Anwender der Komponenten?

Letztendlich basieren die meisten Komponenten auf schon bekannten (Windows-)Komponenten (Panel, Edit, Label) oder heben sich bewusst vom herkömmlichen Stil ab (bspw. http://www.tmssoftware.com/site/advsmoothgauge.asp).
Erstere sollten sich entsprechend der Definitionen im verwendeten Stil verhalten.
Letztere sollen sich bewusst abheben bzw. möchte ich als Enwickler immer selber entscheiden können, wie Gradienten, Farben und Texte darin auszusehen haben.

Bleiben wir bei deinem abstrakten Beispiel vor einigen Posts mit dem Diagramm/Chart:
Auch wenn mein gerade verwendeter Style sehr dunkel ist (z.B. Carbon, Metro Black) möchte ich vielleicht, dass der Diagrammhintergrund weiterhin weiß ist oder ein Gradient ist von beige bis hellblau.

Einfach aus Gewohnheit oder besserer Lesbarkeit oder weil es der Auftrag/Pflichtenheft so vorgibt.

Die Komponente muss mir also immer die Möglichkeit geben, das Styling selektiv über die published property StyleElements ein- oder auszuschalten.

Du hast als Komponentenhersteller gar nicht die Zeit und Möglichkeit für alle RAD Studio eigenen Styles dir irgendwelche speziellen Sachen für jede deiner Komponenten auszudenken.
Ganz zu schweigen von den Styles aus der Delphi-Community selbst bzw. vom jeweiligen Anwender.

[Whookie]

Zitat von TiGü:

Zitat von Whookie:

1. Hersteller A hat eine Komponentenbibliothek und liefert für jeden Delphi Style einen Zusatz...

... die Frage ist, gibt es eine Möglichkeit sowas zu bewerkstelligen

Das geht nicht, wird es nicht geben und ist auch nicht sinnvoll!

Warum sollte sowas nicht sinnvoll sein?
...
Ich gehe sogar so weit zu sagen, dass sowas (ähnliches) Grundvoraussetzung ist, um ein einigermaßen brauchbares System zu erhalten... sonst kann ich ja auch Insellösungen wie AlphaControls oder ähnliches verwenden!

Zitat von TiGü:

Zitat von Whookie:

bzw. wie mit der obigen Situation umgegangen werden muss...

Als Komponentenhersteller oder als Anwender der Komponenten?

Aus Sicht des Komponentenherstellers

Zitat von TiGü:

Letztendlich basieren die meisten Komponenten auf schon bekannten (Windows-)Komponenten (Panel, Edit, Label) oder heben sich bewusst vom herkömmlichen Stil ab (bspw. http://www.tmssoftware.com/site/advsmoothgauge.asp).
Erstere sollten sich entsprechend der Definitionen im verwendeten Stil verhalten.

Gerade für erstere kann es aber nötig sein, styleabhängige Erweiterungen zu haben (etwa ein TEdit, das abhängig vom Inhalt (zB.: gültig/ungültig) ein Symbol darstellt, kleinere Grafiken hängen viel stärker vom Hintergrund ab, wie Große.

Komponenten wie die TMS Gauges sind ja für sich schlüssig und benötigen nur einen zum Stil passenden Hintergrund aber Komponenten wie TChart sind so komplex, das sie eine Menge von
Elementen benötigen um einen gutaussehenden Gesamteindruck zu hinterlassen.

Zitat von TiGü:

Bleiben wir bei deinem abstrakten Beispiel vor einigen Posts mit dem Diagramm/Chart:
Auch wenn mein gerade verwendeter Style sehr dunkel ist (z.B. Carbon, Metro Black) möchte ich vielleicht, dass der Diagrammhintergrund weiterhin weiß ist oder ein Gradient ist von beige bis hellblau.

Einfach aus Gewohnheit oder besserer Lesbarkeit oder weil es der Auftrag/Pflichtenheft so vorgibt.

Die Komponente muss mir also immer die Möglichkeit geben, das Styling selektiv über die published property StyleElements ein- oder auszuschalten.

Davon, dass man es nicht deaktivieren darf war hier nie die Rede...

Zitat von TiGü:

Du hast als Komponentenhersteller gar nicht die Zeit und Möglichkeit für alle RAD Studio eigenen Styles dir irgendwelche speziellen Sachen für jede deiner Komponenten auszudenken.

Warum nicht? Mir als Komponentenhersteller könnte es doch am Herzen liegen, dass ich für jeden Style etwas passendes liefere (das der Anwender natürlich überschreiben kann - so er den möchte).
Und gerade für die größeren, wäre das sogar Pflicht.

Ich denke auch, dass das nicht immer so ein großer Aufwand sein muss, in der Regel reichen vielleicht ein paar passende Farben und ein paar Grafiken.

Ob die nun irgendwelche Community-Komponenten das auch können (wollen) oder nicht spielt hier keine Rolle, es sollte eigentlich um ein schlüssiges System gehen, dass einen Umgang mit den Styles ermöglicht der über hardcoding im source code hinausgeht (auch wenn Emba. das erst noch umsetzen muss ... wie ich aus dieser Diskussion momentan feststellen muss).