UI Nachrichtenverarbeitung in mehreren Units/Klassen

[optiman]

Hallo,

ich verwende Delphi 10 Seattle zur Entwicklung einer Windows Desktop Applikation mit VCL.

Meine Haupt-Form enthält UI-Elemente (Menü, Button, Edit usw).
Ich möchte nun Gruppen von UI-Elementen in eigenen Klassen abarbeiten.
Die Menünachrichten sollen also in der Klasse TUiMenu in der Unit UiMenu verarbeitet werden.
Ein logisch zusammengehörender Satz von Button, Edit, Combobox soll auch in einer eigenen Unit verarbeitet werden.
So werden die einzelnen Klassen kleiner und übersichtlicher.

Geht das? Wie?

[Der schöne Günther]

Hallo und Herzlich Willkommen in den Heiligen Hallen des Wissens und des Wahnsinns.

Du meinst "Frames", oder?

http://docwiki.embarcadero.com/RADSt...rames_arbeiten

Du bearbeitest einen Frame fast exakt wie ein Formular, kannst aber, neben Buttons, Edits und all dem, auch Frames auf dein Formular (oder Frame) werfen. Deinem Frame kannst du im Code-Editor wieder öffentliche Methoden und Eigenschaften verpassen welche du vom Formular aus nutzen kannst.

[optiman]

Danke für die schnelle Antwort.

Also ein neues Frame erzeugt (Frame_1). Da ist jetzt ein TEdit (Edit1) drauf.

Das Frame (Frame_1A) lege ich in meine MainForm.

OnChange für Edit1 wird nun in der MainForm verarbeitet.
(procedure TMainForm.Frame1AEdit1Change(Sender: TObject))

Wenn man mehrere Instanzen der Form hat (also auch ein Frame_1B), dann scheint das ja sinnvoll.

Wenn ich 10 Forms mit je 10 Controls auf meine MainForm packe, habe ich mindestens 100 Ereignismethoden in der MainForm.

Die Form soll selbst wissen, was sie bei einem Ereignis zu tun hat, soll also selbst auf die Nachricht reagieren. Das geht nicht.

Wie kann ich aus der MainForm die Nachricht an den Frame leiten? Das würde ja auch helfen.

[Zacherl]

Du kannst das Event doch einfach im Frame setzen statt im Formular.

[optiman]

Das OnChange wird leider nicht an den Frame durchgereicht.

MainForm ohne Eventhandler

Code:

  TMainForm = class(TForm)
    Frame1A: TFrame1;
  end;

Frame mit nie gerufenem Eventhandler

Code:

  TFrame1 = class(TFrame)
    Edit1: TEdit;
    procedure Edit1Change(Sender: TObject);
  end;

...

procedure TFrame1.Edit1Change(Sender: TObject);
begin
    // Wird nie gerufen
    // Edit1.Text verarbeiten
end;

Was mache ich falsch?

[jaenicke]

Der Eventhandler, den du im Frame zugewiesen hast, steht bei OnChange beim Edit aber noch drin?
Nicht dass du den jetzt im Formular quasi deaktiviert hast. Am einfachsten siehst du das im Formularquelltext (Alt + F12 in der Formularansicht). Da sollte OnChange nicht auftauchen. Nur im Frame.

[bernau]

Frames sind klasse, aber haben auch so ihre Macken.

Geh mal im TMainForm in die Textansicht. (Rechte Maustaste auf das Form und dann "Ansicht als Text)

Schau mal ob dort Edit1Change=nil steht. Wenn ja, dann einfach herauslöschen.

[optiman]

Edit1Change=nil in der TMainForm DFM war Schuld.

Super, so geht das. Besten Dank für die Hilfe.

Jetzt kann ich anfangen meine 29000 Zeilen MainForm in Forms zu zerlegen.

Mein Ansatz wäre je eine Form für das Menü, die Toolbar und die Statuszeile.
Dann habe ich da noch einige TabSheets als Hauptinfofläche.
Mal sehen, ob ich eine Form pro Sheet hinbekomme.

Einen schönen Tag noch.

[Der schöne Günther]

Eine Sache solltest du noch wissen:

So unverzichtbar Frames oft sind, das doofe

Delphi-Quellcode:

Edit1Change=nil

zeigt einen riesigen Haken: Der Frame-Inhalt wird auf seinem Container (wie einem Formular oder wieder einem Frame) redundant gespeichert. Das führt nicht nur zu solchen Problemen wie du es gerade hattest, sondern auch anderen.

Wenn du beispielsweise eine ImageList oder einen Button mit einem Glyph auf einem Frame hast, dann findet sich der Inhalt noch ein zweites mal auf dem Formular wieder. Völlig unsinnig. Ich bin unzählige male am Tag damit beschäftigt die redundanten Bestandteile in der DFM wieder herauszulöschen :x

[bernau]

Deshalb habe ich mir mittlerweile angewöhnt Frames dynamisch auf dem Form zu erzeugen.

Sind drei Zeilen im OnCreate des Forms.

Hat auch den Vorteil, daß bei einer Änderung im Frame (Kompenente umbenannt oder gelöscht) keine Fehlermeldung zur Laufzeit erscheint. Denn eigentlich muss man bei einer Änderung des Frames alle Formulare öffnen, bei denen das Frame verwendet wird um diesen blöden Nebeneffekt nicht zu haben.

[bernau]

Zitat:

Zitat von Der schöne Günther (Beitrag 1335530)

Der Frame-Inhalt wird auf seinem Container (wie einem Formular oder wieder einem Frame) redundant gespeichert.

Aber nur, wenn die Properties sich vom ursprünglichen Frame unterscheiden.

[Der schöne Günther]

So wäre es richtig. Ist es aber leider nicht. Seit ich in Delphi dabei bin, spuckt er redundant alles in seinen Container. Es reicht wohl schon, den Frame nur einen Pixel in der Größe zu ändern und schon denkt er sich wohl "Wow, alles ist anders".

Ich werfe die Frames mittlerweile auch immer seltener direkt zur Designzeit ins Programm sondern erstelle sie auch immer öfter zur Laufzeit. Ist zwar alles nicht mehr sonderlich "RAD" aber man kommt trotzdem schneller voran.

[bernau]

RAD ist mir mittlerweile Wurscht. Ist zwar zuerst einmal schneller. Aber für die Wartung aufwändiger.

Frames und nicht visuelle Komponenten werden bei mir mittlerweile immer dynamisch erzeugt. Warum ein OpenDialog auf das Form ziehen, wenn ich das mit einer zentralen Procedure auch machen kann. Vorallem kann ich der zentralen Procedure etwas ändern, dass dann Programmweit Auswirkung hat.

[Stevie]

How to improve the use of delphi frames