Falsche Änderung in einem Frame rückgängig machen

[himitsu]

Toolpalette "Frames" und dann geht ein Helper auf, der z.B. Frames im selben Projekt auflistet.

[Perlsau]

Ahh! Jetzt! Das hatte ich bisher nie verwendet ... Der Ursprungsframe enthält eine Checkbox mit zugewiesenem OnClick-Ereignis. Ich wechsle ins Mainform und platziere darauf den Frame via Toolpalette -> Standard -> Frames. Okay. Danach klicke ich die auf dem jetzt eingebetteten Frame befindliche Checkbox an und sehe im OI -> Ereignisse, daß in dieser Kopie des Original-Frames der Checkbox keine Ereignisbehandlung zugewiesen wurde. Wenn ich jetzt im OI via Doppelklick der Checkbox im Frame auf dem Formular ein Ereignis zuweisen will, erstellt mir Delphi folgende Procedure in der Mainform:

Delphi-Quellcode:

procedure TFormMain.Frame_Test1CheckBox1Click(Sender: TObject);
begin
  Frame_Test1.CheckBox1Click(Sender);
end;

Das ruft dann die bereits implementierte Ereignisbehandlung für die Checkbox auf und funktioniert tatsächlich wie erwartet. Wenn ich jetzt im OI das Ereignis lösche, steht tatsächlich in der DFM der Mainform:

Delphi-Quellcode:

inherited CheckBox1: TCheckBox
          OnClick = nil

Nachdem ich das Ereignis im OI wieder zugewiesen habe, steht dort:

Delphi-Quellcode:

inherited CheckBox1: TCheckBox
          OnClick = Frame_Test1CheckBox1Click

Damit dürfte das Problem gelöst sein

[idefix2]

Zitat von himitsu:

Oder du weißt das Event wieder zu (wenn man es kennt) ... findest du es denn im DropDown nicht?

Nein, im Dropdown kann man es nicht zuweisen, da scheinen nur die Ereignisbehandlungsroutinen der Form-Unit auf, aber die geerbte Routine ist ja in der Frame-Unit deklariert.
Wenn man sich im OI der Form die Ereignisse anschaut, die der Komponente eines Frame zugeordnet sind, ist das komplett leer, die geerbten Ereignisse sind da nicht sichtbar, die sieht man nur, wenn man das Original-Frame bearbeitet.

Ist auch nicht weiter schlimm, man kann es ja direkt in der DFM-Datei löschen - ich habe das nur gefragt, weil ich in dem File nicht besonders gerne herumfuhrwerke, weil man da sehr schnell irgendwas gröber ruiniert: beim Herauslöschen dieses inherited habe ich in der DFM Datei zuerst das zugehörige "end" nicht mitgelöscht, daraufhin waren beim ersten Versuch, die neue Version zu kompilieren, plötzlich die Hälfte der Formularkomponenten weg, da hab ich im ersten Moment recht dumm dreingeschaut

@Perlsau
Frame_Test1Checkbox1Click ist aber eine Ereignisbehandlungsroutine der Form, die ihrerseits die Routine der frame aufruft, was zumindest überflüssiger Overhead ist. Deshalb wollte ich das so nicht stehen lassen. Aber offenbar bringt man das nicht mehr via OI weg, sondern nur direkt in der DFM Datei.

[himitsu]

Zitat von idefix2:

Wenn man sich im OI der Form die Ereignisse anschaut, die der Komponente eines Frame zugeordnet sind, ist das komplett leer, die geerbten Ereignisse sind da nicht sichtbar,

Auch nicht, wenn du den Fokus in das Property-Edit setzt?
Ich kenn z.B. Komponenten von einem globalen DataModul, deren "Link" man nur sieht, wenn der Fokus sich im Edit befindet und sonst ist der auch unsichtbar,
außer die Datenmodul-Unit ist ebenfalls gerade im Editor geladen,

bzw. sie war es in dieser Session mal geladen, wenn das Datenmodul sich zudem in einem Designpackage innerhalb der IDE befindet.

Zitat von idefix2:

sondern nur direkt in der DFM Datei.

Im Kontextmenü des Formdesigners gibt es keine Funktion?

[idefix2]

Zitat von himitsu:

Auch nicht, wenn du den Fokus in das Property-Edit setzt?

Nein, auch dann nicht.

Zitat von himitsu:

Zitat von idefix2:

sondern nur direkt in der DFM Datei.

Im Kontextmenü des Formdesigners gibt es keine Funktion?

Ha! Gibt es doch!
"Geerbte Einstellungen wiederherstellen"
Danke für den Tipp.

[Perlsau]

Zitat von idefix2:

Frame_Test1Checkbox1Click ist aber eine Ereignisbehandlungsroutine der Form, die ihrerseits die Routine der frame aufruft, was zumindest überflüssiger Overhead ist. Deshalb wollte ich das so nicht stehen lassen. Aber offenbar bringt man das nicht mehr via OI weg, sondern nur direkt in der DFM Datei.

Wenn du den Frame zur Designzeit in das Form einbettest, wird jedes Ereignis im Frame zu einem Ereignis im Form. Da die eigentliche Ereignisbehandlung jedoch im Frame steht, muß die Ereignisbehandlung im Form die im Frame aufrufen. Der Frame wird dabei zu einer Komponente des Forms. Wenn du nun deine Checkbox im Frame, das bereits in die Form eingebettet ist, markierst, siehst du im OI keine Zuweisung einer Ereignisbehandlung. Die Ereignisse des Frames sind im OI offenbar nicht verfügbar. Wenn du diese Zuweisung nicht machst, funktioniert dein Klick auf die Checkbox zur Laufzeit nicht (eben nochmal getestet). Ergo ist es kein überflüssiger Overhead, sondern Notwendigkeit. Etwas anders sieht es aus, wenn du den Frame erst zur Laufzeit in der Form unterbringst. Dabei reagiert der Frame vollkommen eigenständig. Ob das jetzt ein Bug ist oder so gewollt, kann ich dir mangels tiefergehender Kenntnisse über die Eingeweide der Delphi-IDE auch nicht sagen ...

Alles falsch, hab eben das Frame aus der Form gelöscht und den Frame nochmal "frisch" auf die Form verpflanzt und siehe da: Die Ereignisbehandlung der Checkbox funktioniert auch ohne diesen Overhead. Das heißt: Nach dem Einbetten des Frame in das Form steht im OI kein Ereignis für die Checkbox, und es funktioniert dennoch. Du mußt also vor dem Löschen selber was eingetragen haben, was dann natürlich nur über die Form funktioniert.

Sorry für die Irreführung, für mich stellt dieser Fall auch Neuland dar, weil ich zuvor noch niemals einen Frame zur Designzeit in eine Form eingebettet habe. Immerhin: Wieder was dazugelernt ...

[idefix2]

Zitat von Perlsau:

Du mußt also vor dem Löschen selber was eingetragen haben, was dann natürlich nur über die Form funktioniert.

Richtig, im Eingangspost habe ich geschrieben:

Zitat von idefix2:

...
Nun habe ich im Formular via Objektinspektor irrtümlich ein Onclick Ereignis eingetragen und das dann wieder gelöscht. Daraufhin steht im Dfm-File:
...

Und richtig hätte ich das falsche onclick mit Hilfe des Kontextmenüeintrags weggebracht, auf den mich Himitsu aufmerksam gemacht hat, statt es zu löschen.

[Dejan Vu]

Wenn man 'Geerbte Einstellungen' wiederherstellen anwendet, werden natürlich alle Änderungen ggü. dem Original entfernt. Das will man aber manchmal nicht. Leider hilft hier 'nur' das direkte Editieren der DFM. Das finde ich allerdings nicht schlimm. Ich mache viele Refactorings über die DFM direkt. So eine IDE kann eben nicht alles. Schön wäre hier ein Syntaxhighlightning der DFM und ein paar Hilfen, so wie es bei WPF oder ASP.NET der Fall ist.