AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Delphi Wann ist die Zeit für eine eigene VCL-Komponente gekommen?
Thema durchsuchen
Ansicht
Themen-Optionen

Wann ist die Zeit für eine eigene VCL-Komponente gekommen?

Offene Frage von "Sir Rufo"
Ein Thema von Der schöne Günther · begonnen am 17. Jun 2013 · letzter Beitrag vom 17. Jun 2013
Antwort Antwort
Seite 1 von 2  1 2      
Der schöne Günther

Registriert seit: 6. Mär 2013
6.154 Beiträge
 
Delphi 10 Seattle Enterprise
 
#1

Wann ist die Zeit für eine eigene VCL-Komponente gekommen?

  Alt 17. Jun 2013, 15:54
Hallo-

So langsam mache ich immer mehr sichtbare Dinge und nicht nur die Zahnräder im Hintergrund. Nachdem mir für mein Einsatzgebiet Firemonkey anscheinend keinen Zusatznutzen bringt (siehe hier) beschränke ich mich hierbei auf die VCL.

Es geht, beispielhaft, um eine Diagnose-Oberfläche:

Ich möchte einfach nur eine Handvoll Objekte ("Container") visualisieren.
Die Anzahl ist nicht fest, in der Regel werden es wohl 6-16 sein. Diese Objekte beinhalten in der Regel bis zu 16 Kindobjekte ("Child").

Zu Container möchte ich nicht viel mehr als einen "Status" mitteilen, da reichen wohl drei verschiedene Farben aus. Weiterhin noch wieviele Children er hat und ob diese "an" oder "aus" sind. Dafür reichen auch drei Farben (an, aus, nicht existent). Ein konretes Beispiel in Form zweier Bilder im Anhang. Realisiert ist das (optisch natürlich ziemlich unschön) durch ein Panel (Hintergrundfarbe für "Container" auf dem ein DrawGrid für "Child" sitzt.


Im abgebildeten Beispiel habe ich ein TabControl für 3 Container. Das ist blöd. Ich möchte, dass der Benutzer alle auf einen Blick hat und dachte an ein FlowPanel. Da kann ich einfach TControl-Objekte hineinwerfen und das Teil ordnet mir das automatisch an.

Anstatt nun ständig in diesem FlowPanel mir die richtigen Unter-Controls (wie das DrawGrid oder Panel) herauszusuchen dachte ich, das ganze als eine visualle Komponentene zu basteln wäre der richtige Ansatz. Vor allem könnte das Teil dann einfach eine Referenz auf ein Container-Objekt haben und ich müsste nur noch (z.B. timergesteuert) sagen: "Aktualisiere dich!".


Wieviel Aufwand habe ich hier vor mir? In Sachen VCL bin ich bislang immer nur froh, wenn er kompiliert, wirklich Ahnung habe ich nicht. Auch brauche ich nicht so weit zu gehen, eine tolle zur Entwicklungszeit platzierbare Komponente mit Icon in der Tool-Palette zu haben. In diesem Fall (und wohl auch in allen kommenden) würde es reichen, eine Komponente zur Laufzeit zu erzeugen und irgendwo hin zu setzen.
Miniaturansicht angehängter Grafiken
eins.png   zwei.png  
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
9.573 Beiträge
 
Delphi 11 Alexandria
 
#2

AW: Wann ist die Zeit für eine eigene VCL-Komponente gekommen?

  Alt 17. Jun 2013, 16:27
Grundsätzlich ist Kapselung meistens eine Vereinfachung, da du nach außen veröffentlichst was du brauchst und dich dort dann nicht mehr drin kümmern musst warum und wie das funktioniert.
Zudem lässt sich so viel einfacher testen, da du die Klasse losgelöst von deinem Programm testen kannst.
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
6.154 Beiträge
 
Delphi 10 Seattle Enterprise
 
#3

AW: Wann ist die Zeit für eine eigene VCL-Komponente gekommen?

  Alt 17. Jun 2013, 16:32
Ich habe gerade aus Neugier einfach einmal angefangen. Insgesamt ja viel einfacher als ich erst dachte.

Insgesamt frage ich mich nur, ob es irgendwie "schlechter Stil" ist, wenn ich in einem halben Jahr wieder auf meine Tool-Palette schaue und drei Dutzend super-spezielle eigene Komponenten da drin habe wenn es doch auch eigentlich genauso mit den bekannten Standard-Komponenten und ein paar Methoden extra gegangen wäre...
  Mit Zitat antworten Zitat
nahpets
(Gast)

n/a Beiträge
 
#4

AW: Wann ist die Zeit für eine eigene VCL-Komponente gekommen?

  Alt 17. Jun 2013, 16:42
Wenn es so aussehen soll, wie auf den Bildern, könnte hier aber auch erstmal ein Nachfahre von TFrame ausreichen.
Einmal ein entsprechendes Frame erstellen, dort die erforderliche Logik für die Komponenten im Frame implementieren.

Frame beliebig oft auf einen oder mehrere Tabreiter legen.

Wenn ich das richtig sehe, kannst Du so ein Frame eigentlich dann wie eine eigene Klasse betrachten.

Eigentlich ist ein Frame auch "nur" ein Container für beliebige Komponenten, der einmal erstellt, beliebig oft wiederverwendet werden kann.

Eine eigene Komponente machen, abgeleitet von wem auch immer, ist nicht wirklich schwierig. Eigene Komponenten so bauen, dass sie möglichst oft wiederverwendbar sind, nicht für jedes Kinkerlitzchen eine eigene Komponente bauen, die sich nur marginal von einer oder einem anderen dutzend Komponenten unterscheiden.
Ein bisserl Ordnung in der Komponentenpalette halten, die sinnvoll ordnen und das Ganze ist eigentlich kein Problem.
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
6.154 Beiträge
 
Delphi 10 Seattle Enterprise
 
#5

AW: Wann ist die Zeit für eine eigene VCL-Komponente gekommen?

  Alt 17. Jun 2013, 16:51
Vor Schwierigkeiten stehe ich nur, die Komponente mit einem Geschäftslogik-Objekt zu verknüpfen. Das ist allerdings meine eigene Schuld, da ich das Thema "Delphi und Interfaces" bislang immer weiter aufgeschoben habe: Ich kann ja schlecht die Komponente von der konkreten Klasse abhängig machen, denn das zieht durch den implementation-Teil einen Rattenschwanz hinter sich her.

Wie auch immer, das ist wohl mein ganz eigenes Verschulden und hat mit Komponenten an sich nichts mehr zu tun. Hier frage ich mich allerdings nur: Die Komponente macht ohne eine Referenz auf ein bereits bestehendes zu visualisierendes Objekt keinen Sinn. Würde ich Probleme bekommen, wenn ich die Parameterliste des Konstruktors abändere?
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.429 Beiträge
 
Delphi 12 Athens
 
#6

AW: Wann ist die Zeit für eine eigene VCL-Komponente gekommen?

  Alt 17. Jun 2013, 16:58
Die Komponente macht ohne eine Referenz auf ein bereits bestehendes zu visualisierendes Objekt keinen Sinn. Würde ich Probleme bekommen, wenn ich die Parameterliste des Konstruktors abändere?
Vielleicht nicht sofort, aber sicher später. Das Streaming-System verwendet den virtuellen Constructor mit dem Owner als Parameter.

Was spricht dagegen, das zu visualisierende Objekt über ein schreibbares Property zuzuweisen? So wird das in der VCL eigentlich generell gelöst.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.343 Beiträge
 
Delphi 11 Alexandria
 
#7

AW: Wann ist die Zeit für eine eigene VCL-Komponente gekommen?

  Alt 17. Jun 2013, 17:04
Das ist genau richtig so. Dafür ist die OOP doch da.
Unter dem Register "SchöneKomponenten" findest Du immer Deine Komponenten und kannst sie als Package sogar weiter geben.
Geringere Abweichungen bzw. Styles o.ä. würde ich in einer Komponente über eine Eigenschaft Mode oder Style regeln.

Das Verhalten kannst Du jederzeit erweitern oder verbessern und die Controls dabei im Formular belassen. Wenn Du Eigenschaften entfernst würde Dich die IDE ggf. warnen, dass entsprechende Einstellungen verloren gehen.

Wenn Du Deine Komponenten nur zur Laufzeit erstellst brauchst Du sie natürlich nicht für die IDE registrieren.

Über Frames lässt sich das Ganze natürlich auch regeln. Wenn sie aber in verschiedenen Projekten eingesetzt werden sollen ließen sich Komponenten m.E. besser händeln.

[OT]Seit XE gibt es m.E. machmal Probleme, wenn man Komponenten neu installiert, die bereits in der Projektgruppe verwendet werden. Das kann bei mir aber auch damit zusammen hängen, dass ich an einem Frameworkpackage arbeite, das in einem Designtime-Package verwendet wird. Aus dem Grund hat der Schöpfer vermutlich auch erst das Ei erfunden und dann das Huhn (oder anders rum). So einfach will ich es mir aber halt nicht machen.

Mein Ansatz ist dabei noch, ein Databinding zu realisieren. Ich bastle einfach irgendwelche Controls und kann denen Datenobjekte bzw. deren Eigenschaften zuweisen. Das übertragen der Werte in beide Richtungen wird dann vom Framework übernommen.
[/OT]


EDIT: Als Datenobjekt kannst Du entweder eine bestimmte (eigene) Klasse vorsehen oder ein beliebiges Objekt, welches dann mit der RTTI näher analysiert wird. Interfaces sind in dem Zusammenhang nicht zwingend notwendig. Kompliziert ist eigentlich nur, beide Schichten (Controls und Datenobjekte) gegenseitig über Änderungen zu informieren.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)

Geändert von stahli (17. Jun 2013 um 17:49 Uhr)
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
6.154 Beiträge
 
Delphi 10 Seattle Enterprise
 
#8

AW: Wann ist die Zeit für eine eigene VCL-Komponente gekommen?

  Alt 17. Jun 2013, 17:47
So wird das in der VCL eigentlich generell gelöst.
Genau solche Informationen suche ich, danke

Geringere Abweichungen bzw. Styles o.ä. würde ich in einer Komponente über eine Eigenschaft Mode oder Style regeln.
Und wenn ich gut aufgepasst habe, dann sieht man diese Sachen im Objektinspektor nur, wenn sie den Sichtbarkeitsmodifikator published haben, richtig?

Mein Ansatz ist dabei noch, ein Databinding zu realisieren. Ich bastle einfach irgendwelche Controls und kann denen Datenobjekte bzw. deren Eigenschaften zuweisen.
Kompliziert ist eigentlich nur, beide Schichten (Controls und Datenobjekte) untereinander bei Änderungen zu informieren
Bitte erzöhl mehr
Da ich immer noch viel Delphi-Standardklassen nicht kenne, weiß ich bsp. nicht, inwiefern man hier mit einem normalen Observer-Pattern arbeiten könnte (hier fehlen mir wieder die Interfaces ) oder es doch etwas komplizierter wird.
Bei mir ist es wohl noch etwas einfacher, da ich ja nur stumpf etwas beobachten will, Änderungen an den Objekten soll die Komponente keine vornehmen können. Nur etwas anzeigen.

Ich glaube ein klassisches Beispiel findet man in dem Zusammenspiel von TDataSource->TDataSet->TCustomConnection ? Das schaue ich mir mal näher an...
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.343 Beiträge
 
Delphi 11 Alexandria
 
#9

AW: Wann ist die Zeit für eine eigene VCL-Komponente gekommen?

  Alt 17. Jun 2013, 18:14
Und wenn ich gut aufgepasst habe, dann sieht man diese Sachen im Objektinspektor nur, wenn sie den Sichtbarkeitsmodifikator published haben, richtig?
Exakt.

Ok, wenn man mich zwingt:
erste Variante: http://www.delphipraxis.net/162362-m...s-preview.html
aktuell: http://www.delphipraxis.net/173360-s...framework.html

Da ich immer noch viel Delphi-Standardklassen nicht kenne, weiß ich bsp. nicht, inwiefern man hier mit einem normalen Observer-Pattern arbeiten könnte (hier fehlen mir wieder die Interfaces ) oder es doch etwas komplizierter wird.
Bei mir ist es wohl noch etwas einfacher, da ich ja nur stumpf etwas beobachten will, Änderungen an den Objekten soll die Komponente keine vornehmen können. Nur etwas anzeigen.
Ich glaube ein klassisches Beispiel findet man in dem Zusammenspiel von TDataSource->TDataSet->TCustomConnection ? Das schaue ich mir mal näher an...
Richtig, aber evtl. für Dich nicht notwendig. Die Frage ist, wie komplex Du es brauchst.

Beispiel TDataAmpel und TVisibleAmpel.
Wenn TVisibleAmpel eine Eigenschaft TDataAmpel hat, kann sie jederzeit auf deren Farbwert zugreifen und sich neu zeichnen.
Machst Du das in einem Timer ist nix weiter notwendig als VAmpel1.DAmpel := DAmpel1 auszuführen. Das würde schon reichen.
Willst Du keinen Timer verwenden muss DAmpel wissen, in welcher/n VAmpel/n sie verwendet wird (Observer bzw. RegisterListe) und muss bei Datenänderungen ihre VAmpeln informieren.
Alternativ kann ein "Vermittler" alle VAmpeln informieren, wenn in einer DAmpel eine Änderung erfolgt.
Wenn Du eine 1:1 Beziehung hast, kannst Du es Dir natürlich leicht machen und VAmpel und DAmpel gegenseitig miteinander bekannt machen.
In jedem Fall muss man beachten, dass die sichtbaren Controls darüber informiert werden, wenn das gebundene Datenobjekt aufgelöst wird.

Ich weise meinen sichtbaren Controls ein Objekt zu und einen Eigenschaftsnamen. Der Objekttyp muss dem sichtbaren Control dabei nicht bekannt sein.
Im Prinzip etwa:
VAmpel1.Ctrl.Object := DAmpel1; VAmpel1.Ctrl.PropName := 'Color'; bzw. real:
VAmpel1.Ctrl.ObjName := '#EineId_Oder_ComponentName.Color';
Die Auflösung erfolgt dann zur Laufzeit. Datenänderungen durch das Control oder durch die BusinessLogic werden in beide Richtungen über ein Framework automatisch übermittelt.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)

Geändert von stahli (17. Jun 2013 um 18:19 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von sx2008
sx2008

Registriert seit: 16. Feb 2008
Ort: Baden-Württemberg
2.332 Beiträge
 
Delphi 2007 Professional
 
#10

AW: Wann ist die Zeit für eine eigene VCL-Komponente gekommen?

  Alt 17. Jun 2013, 18:37
Komponenten bzw. Controls sollten immer so programmiert sein, dass sie keine Geschäftlogik enthalten sondern allgemein genug sind um auch in anderen Anwendungen verwendet zu werden.

Als Vorbild dient hier die VCL.
Alle Komponenten der VCL können prinzipiell in allen Anwendungen benützt werden gerade so wie Legobausteine die man immer wieder neu zusammenstecken kann.

Der Sourcecode einer Anwendung wird normalerweise in einer Versionsverwaltung gespeichert.
Es ist kein Problem mal auf die Schnelle eine alte Version rauszuholen und zu kompilieren.
Komponenten sind in diesem Ablauf ein Fremdkörper denn sie sind meistens nicht in der Versionsverwaltung gespeichert.

Ich habe vor einigen Jahren den Fehler gemacht zwei spezielle Komponenten mit anwendungspez. Logik zu schreiben.
Im Laufe der Zeit mussten die Komponenten mehrfach angepasst werden.
Das hat die Umschaltung zwischen verschiedenen Version erheblich behindert.
Selbst als im aktuellen Programmstand die Komponenten durch ganz anderen Code ersetzt wurden und überflüssig waren musste ich sie immer noch in der IDE mitziehen damit ich auch ältere Versionen kompilieren kann.
Pain in the ass!

In deinem speziellen Fall würde ich sagen du brauchst entweder einzelne LED-Controls mit OnClick-Event oder gleich ein LED-Array-Control.
Anregungen gibt es z.B. auf Torry's.
fork me on Github
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      

 

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:45 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