Guten abend,
gibt es die Möglichkeit ein SpeedButton1.click gleich in
einer 2ten unit einzubinden und nicht immer in Hauptunit Unit1.?

mfg schuby

markieren

Delphi-Quellcode:

procedure TForm1.SpeedButton1Click(Sender: TObject);
begin
  Memo1.Clear;
end;

markieren

Delphi-Quellcode:

procedure TForm1.SpeedButton1Click(Sender: TObject);
begin
  form2.Memo1.Clear;
end;

Ich glaube Schuby meint das anders rum. Der Button soll in Unit 1 bleiben, das Event aber in Unit 2.

Sowas könnte man zwar konstruieren, sehe aber keinen Nutzen.

Also etwa so umbiegen:

  SpeedButton1.onClick := form2.speedbuttonX.onclick; Würde ich nicht machen. Mag ja funktionieren, gefällt mir aber nicht.

Ich denke der Nutzen soll der sein, dass die Hauptunit von Code befreit wird, auslagern von Event-bezogenem Code in Extraunits.

Zitat von Neumann:

Sowas könnte man zwar konstruieren, sehe aber keinen Nutzen.

Also etwa so umbiegen:

  SpeedButton1.onClick := form2.speedbuttonX.onclick; Würde ich nicht machen. Mag ja funktionieren, gefällt mir aber nicht.

Oder irgendwo im Quelltext der Unit2:Form1.SpeedButton1Click(Sender); Aber:

Schön ist das nicht.

Wenn, dann baut man eine Unit, die die entsprechenden Funktionen, Prozeduren ... enthält und ruft dann in dem entsprechenden OnClick-Ereignnis die benötigte Funktion, Prozedur, WasAuchImmer auf.

Also, das würde ich dann so machen:

markieren

Delphi-Quellcode:

procedure TForm1.SpeedButton1Click(Sender: TObject);
begin
  MyBusinessobj.doSpeedbutton1click;
end;

Die 4 Zeilen können doch eigentlich nicht stören.

Oder irgendwo im Quelltext der Unit2:Form1.SpeedButton1Click(Sender);

Ganz schlimm

Zitat von DieDolly:

Ich denke der Nutzen soll der sein, dass die Hauptunit von Code befreit wird, auslagern von Event-bezogenem Code in Extraunits.

Genau das meinte ich, ich wollte gerne das alles was an Unit 2 gehört auch in
Unit 2 ist, einfach das man den Code besser lesen kann.


Das werde ich gleich mal versuchen
SpeedButton1.onClick := form2.speedbuttonX.onclick;


Danke für die Antworten.


Gruß schuby

Irgendwie finde ich dieses "Hinundherverknüpfenvonunits" sagen wir mal suboptimal.

Schonmal was von TActionlist gehört?

Wenn z. B. diverse Aufgaben, die per Button, Menü, ShortCut ... gesteuert werden sollen, an einer zentralen Stelle versammelt werden müssen / sinnvollerweise sollten, dann kann man dafür z. B. ein Datenmodul nehmen und das mit 'ner TActionList "bestücken". Für jede Aufgabe wird der TActionList eine TAction spendiert und in deren Ereignisroutine die entsprechende Aufgabe erledigt.

Buttons, Menü, ... haben u. a. eine Eigenschaft Action. Dieser kann man dann die zugehörige Action aus der TActionList des Datenmoduls zuweisen.

Dies ist (für meine Begriffe) deutlich einfacher zu implementieren und deutlich lesbarer, als eine (mehr oder weniger große) Unmenge von "kreuzweisen" Uses auf Unit1, Unit2, ... (und den ggfls. vom Kompiler geworfenen Fehlermeldungen, weil er das nicht mehr aufgelöst bekommt) und dann im Quelltext das Ansprechen der jeweiligen, globalen Formular-...-variabeln.

Aber: Nur so als Idee für einen anderen Lösungsansatz für das bestehende Problem gedacht.

Und: Das mit dem Datenmodul funktioniert auch noch, wenn man es in unterschiedlichen Programmen nutzen möchte.
Alles, was irgendwie zentral, wiederholt in unterschiedlichen Zusammenhängen, ... benötigt wird, bekommt halt Zugriff auf das Datenmodul und die entsprechenden Steuerelemente werden einmal mit den entsprechenden Actions verbunden und gut iss.

Und: Natürlich gibt es für derartige Problemstellungen unterschiedliche Lösungsansätze, mindestens soviele, wie Wege nach Rom