AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein GUI-Design mit VCL / FireMonkey / Common Controls Delphi Korrekter Umgang mit Delphi Styles und eigenen Komponenten

Korrekter Umgang mit Delphi Styles und eigenen Komponenten

Ein Thema von Whookie · begonnen am 7. Aug 2014 · letzter Beitrag vom 18. Aug 2014
Antwort Antwort
Seite 3 von 3     123
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
3.058 Beiträge
 
Delphi 10.4 Sydney
 
#21

AW: Korrekter Umgang mit Delphi Styles und eigenen Komponenten

  Alt 13. Aug 2014, 13:59
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!
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
3.058 Beiträge
 
Delphi 10.4 Sydney
 
#22

AW: Korrekter Umgang mit Delphi Styles und eigenen Komponenten

  Alt 13. Aug 2014, 14:00
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?
  Mit Zitat antworten Zitat
Whookie

Registriert seit: 3. Mai 2006
Ort: Graz
441 Beiträge
 
Delphi 10.3 Rio
 
#23

AW: Korrekter Umgang mit Delphi Styles und eigenen Komponenten

  Alt 13. Aug 2014, 22:57
... ja genau das ist das problem (oder eben nur mangelndes know how) ...
Whookie

Software isn't released ... it is allowed to escape!
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
3.058 Beiträge
 
Delphi 10.4 Sydney
 
#24

AW: Korrekter Umgang mit Delphi Styles und eigenen Komponenten

  Alt 14. Aug 2014, 10:34
Warum ist das ein Problem?
Es wäre äußerst ungünstig, wenn mehrere Styles für verschiedene Komponenten geladen werden könnten.
  Mit Zitat antworten Zitat
Whookie

Registriert seit: 3. Mai 2006
Ort: Graz
441 Beiträge
 
Delphi 10.3 Rio
 
#25

AW: Korrekter Umgang mit Delphi Styles und eigenen Komponenten

  Alt 17. Aug 2014, 12:19
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...
Whookie

Software isn't released ... it is allowed to escape!
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
3.058 Beiträge
 
Delphi 10.4 Sydney
 
#26

AW: Korrekter Umgang mit Delphi Styles und eigenen Komponenten

  Alt 18. Aug 2014, 11:21
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!

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.
  Mit Zitat antworten Zitat
Whookie

Registriert seit: 3. Mai 2006
Ort: Graz
441 Beiträge
 
Delphi 10.3 Rio
 
#27

AW: Korrekter Umgang mit Delphi Styles und eigenen Komponenten

  Alt 18. Aug 2014, 14:38
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!

bzw. wie mit der obigen Situation umgegangen werden muss...
Als Komponentenhersteller oder als Anwender der Komponenten?
Aus Sicht des Komponentenherstellers

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.


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...


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).
Whookie

Software isn't released ... it is allowed to escape!
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:18 Uhr.
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