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

[Aphton]

Lol, ne, das haste falsch aufgegriffen.

Da ich Analogien so liebe, hier eine:
Du kannst die drei vor dir liegenden Kisten einzeln tragen, oder sie übereinander stapeln und musst daher nicht 3 mal hin und her!

Konkret - Lagere alles in Methoden aus und halte die DRY-Regel ein!

MfG :P

[mquadrat]

Mag nicht mal jemand die VCL um Property-Changed-Notifications und Commands mit Can-Execute erweitern? Und dann beides noch mit einem gescheiten Data-Binding aneinander anhängen. Oh und am Besten via Convention-Over-Configuration.

:-D

Naja, man wird doch noch träumen dürfen :lol:

[stahli]

Zeig doch mal ein Stückchen Code damit wir sehen, was Du tust und willst...

[Klausi1305]

Ich habe soweit alle Einstellungen der GUI in Proceduren wie(Allesleer, NurDas,NurJenes) hinterlegt wo ich sie jetzt problemlos ändern/ und erweitern kann.

So funktionierts jetzt auch....

Thema kann geschlossen werden