Eventhandler im Code ja, im OI nein?

[Medium]

Mahlzeit!

Mein Delphi 7 ärgert mich grad. Ich möchte einer Komponente einen OnClick-Handler im OI zuweisen, die Methode ist allerdings nicht Methode dieses Formulares, sondern eines anderen in einer anderen Unit. Diese Unit steht auch in der Uses-Liste.
Mache ich das im Code, klappt das ganz wunderprächtig:

Delphi-Quellcode:

procedure TMyForm.FormCreate(Sender: TObject);
begin
  btnS63.OnStartClick := frmAnwahl.StartClick;
end;

Versuche ich selbiges aber im OI, und trage dort "frmAnwahl.StartClick", "TfrmAnwahl.StartClick", "uAnwahl.frmAnwahl.StartClick" oder "uAnwahl.TfrmAnwahl.StartClick" ein, quittiert Delphi dies mit einem Fensterchen, das sagt "[eingetragener Name] ist kein gültiger Bezeichner". Ich bin mir aber doch sehr sicher, dass dies einer ist - im Create geht es ja! :evil:

Kann man da was dran drehen?

[Luckie]

Sorry, aber warum reißt du den Code auseinander? Formular und Ereignisbehandlungsroutine gehören einfach zusammen. Und wenn in mehreren Formularen der gleiche Code ausgeführt werden soll, lagere ihn in eine separate Methode aus, die du aus den jeweiligen Ereignisbehandlungsroutine aufrufst. Es ist immer schlecht, wenn man sich die zugehörigen Ereignisbehandlungsroutinen in allen möglichen Units zusammensuchen muss. außerdem verringerst du so die Abhängigkeit von Oberfläche und Code.

[Medium]

Rate mal, was dieser Handler in frmAnwahl ist ;) Das ist eben genau als meine Sammelstelle konzipiert. Ich möchte jedoch nur ungern in jedem der weiteren Formulare einen Dummy-Hanlder erstellen müssen, der den Aufruf an die Sammelstelle weiter reicht - ich könnte ja direkt verknurpseln. Nur lässt mich der OI nicht. Ich will dadurch vor allem verhindern, dass im Nachgang doch wieder formularspezifische Spezialhandler zugefrickelt werden. Diese Events sind absolute Standardhandler. Semantisch macht das alles durchaus Sinn.
Warum mich das etwas irritiert: Properties vom Typ einer anderen Komponente (wie z.B. die Connection einer Query) lassen sich problemlos Unitübergreifend referenzieren.

[Luckie]

Ich glaube, wir reden aneiander vorbei. Lass die Ereignisbehandlungsroutine im Gleichen Formular und pack den Code, den die Routine ausführt in eine separate Unit.

[Medium]

Ich glaub auch ;) Das ist doch genau, was ich vermeiden will. Die geünschte Vereinfachung wäre ja eben, dass es so viele Formulare sind, auf denen Komponenten mit diesen Handlern ausgestattet werden - ich möchte eben auf diesen Einzeiler in allen diesen Verzichten, da er ohnehin nichts anderes Täte, als eine Methode identischer Signatur, nur eines anderen Formulars aufzurufen.

[himitsu]

Im OI kannst du eben nur Eventhandler angeben, welche der DFM-Loader an dieser Stelle auch kennt, denn was er nicht kennt, das kann er nicht verlinken/umwandeln.

Da wirst du also im OnCreate deine zuweisung machen müssen, oder eben doch die Dummy-Methoden nutzen.

[Medium]

Wattn Käse :( Beibringen wird vermutlich auch keine Dreiklickaufgabe, hm? Mich hat eben nur verwundert, dass Komponenten auf anderen Formularen im OI durchaus auftauchen, Methoden dagegen nicht, obgleich sie problemlos zuweisbar wären. Schade, aber danke euch!

[Luckie]

Zitat:

Zitat von Medium (Beitrag 1094409)

da er ohnehin nichts anderes Täte, als eine Methode identischer Signatur, nur eines anderen Formulars aufzurufen.

Nein tut er nicht. Ausführender Code gehört nicht in die Unit eines Formulars, sondern in eine extra Unit. Und in den Ereignisbehandlungsroutinen rufst du den ausführenden Code in der extra Unit auf. So hast du eine schöne Trennung zwischen ausführenden Code und Oberfläche. Will dein Chef jetzt eine Konsolenanwendung, brauchst du nur den Code in der extra Unit aufrufen, fertig. So musst du wieder alles auseinanderpflücken und neu zusammensetzen.

[Medium]

Luckie, dein Idealbild in allen Ehren, aber der praktische Anwendungsfall übertönt hin und wieder auch die schönste Theorie. Zudem ist das Projekt dermaßen Maßgeschneidert, man könnte diese Dinge bestenfalls als Gerüst für ein anderes nehmen, aber man muss zwangsweise an den Code ran.

Die Prozesslogik liegt vor allem auch in meiner Variante nicht im Formular! Das "frmAnwahl", dass die Standardhandler beherbergt, tut genau eben auch nur das, und es existierte nur, weil ich hoffte damit an diese Handler im OI zu kommen. Glaub mir, ich habe über Softwaredesign in meinem Leben mehr als genug gehört, nur macht es Delphi einem stellenweise auch nicht gerade leichter.