GUI Modifikation während Entwicklung

[Klausi1305]

Hallo zusammen,

Ich schlage mich, eigentlich seit dem ich mit Delphi rumhantiere rum, mit dem Problem der "perfekten Benutzeroberfläche (GUI)" rum....
Bei jedem Projekt komme ich oder andere auf die Idee ala" ohh, wenn de dann noch ne Checkbox..dann dort alles im Treeview" etc.

Mir gehts es auf den Sack, jedesmal alles neu umzubauen (visible, enabled etc)...

Macht es Sinn, zusätzlich zu einem Forumlar, eine Extra Unit zuschreiben, wo genau ich diese "Handlungsroutinen" nur für die GUI hinterlege und ich im eigentlichen Formular z.b. beim Button "Löschen" nur noch Löschen123; setze...??

Danke für eure Hirnanstrengungen

[stahli]

Ich kann Dein Anliegen nicht so recht nachvollziehen.
Wenn es um Wiederverwendbarkeit mehrer Komponenten geht, dann kannst Du Dir mal "Frames" anschauen.
Ansonsten ist doch die IDE gerade dafür da, alles optisch sichtbare auf einem Formular bestmöglich aufbauuen zu können.

[generic]

Klausi1305 kennst du die TAction Komponenten?

Literatur:

Zitat:

Entwickler Magazin (Ausgabe: 04.10) Artikel: Action in Delphi - TActionlist und TAction im Detail

[Namenloser]

Nutz doch einfach die Objektablage :wink:

[Klausi1305]

Dann werd ich mir mal TAction Komponenten reinziehen....

@Stahli: In der IDE kann ich ja nur die "Start" Optionen des Frames, Formulars festlegen, und nicht "wenn Button1 gedrückt, dann Button 2-6 enabled:=False; Oder liege Ich da falsch...Ich meinte damit das mir diese ewige rumkopiererei der Propertys im Quelltext auf den Sack geht..

[generic]

Auf der Entwickler Homepage kannst du den Beispiel Source runterladen.
Es gibt auf einen Code-Rage Video auch Beispiele dazu.

[alzaimar]

Zitat:

Zitat von Klausi1305 (Beitrag 1078546)

...Ich meinte damit das mir diese ewige rumkopiererei der Propertys im Quelltext auf den Sack geht..

Dann machst Du etwas Fundamentales falsch: Wer rumkopiert, verstößt gegen das DRY-Prinzip.

Erweitere deine Form doch einfach um Verhaltenseigenschaften, hinter denen sich komplexe Änderungen der GUI verbergen. So kann z.B. die Eigenschaft 'DataModified' einen 'Save'-Button steuern: Sind die Daten geändert, ist der Save-Button aktiviert, sonst nicht.

Beim Speichern der Daten wird dann einfach 'DataModified' auf FALSE gesetzt. Jedes OnChange-Ereignis eines Datensteuerelementes setzt DataModified auf TRUE.

Dazu verwendet man zwar i.A. datensensitive Steuerelemente, aber das war ja auch nur als Beispiel gedacht.

[Klausi1305]

DRY Prinzip...Ok ich werd mal die Suche und den Gockel bemühen...

Entschuldige das Ich seit Jahren dagegen verstosse...Aber ich mach das nur Hobbymäßig, und nicht für die Schule oder so.

Aber genau deswegen frage Ich ja hier nach, da mir meine Fachliteratur darüber auch nur sehr wenig Auskunft gibt..

[DeddyH]

DRY = Don' t Repeat Yourself ;)

[Klausi1305]

Also willst du mir damit sagen das Ich z.b. 40 mal die selbe Methode in einer Klasse neu per Hand schreibe und nur den Variablenname ändere?????

Wenn ja...mmmhh..unschön