UI Nachrichtenverarbeitung in mehreren Units/Klassen

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

[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 von Der schöne Günther:

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.