Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   Delphi Unit2 nicht unit1 (https://www.delphipraxis.net/207699-unit2-nicht-unit1.html)

Schuby 23. Apr 2021 18:06

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

mfg schuby


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

Neumann 23. Apr 2021 18:38

AW: Unit2 nicht unit1
 
Delphi-Quellcode:
procedure TForm1.SpeedButton1Click(Sender: TObject);
begin
  form2.Memo1.Clear;
end;

DieDolly 23. Apr 2021 18:39

AW: Unit2 nicht unit1
 
Ich glaube Schuby meint das anders rum. Der Button soll in Unit 1 bleiben, das Event aber in Unit 2.

Neumann 23. Apr 2021 18:57

AW: Unit2 nicht unit1
 
Sowas könnte man zwar konstruieren, sehe aber keinen Nutzen.

Also etwa so umbiegen:

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

DieDolly 23. Apr 2021 19:00

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

Delphi.Narium 23. Apr 2021 19:07

AW: Unit2 nicht unit1
 
Zitat:

Zitat von Neumann (Beitrag 1487711)
Sowas könnte man zwar konstruieren, sehe aber keinen Nutzen.

Also etwa so umbiegen:

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

Oder irgendwo im Quelltext der Unit2:
Delphi-Quellcode:
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.

Neumann 23. Apr 2021 19:07

AW: Unit2 nicht unit1
 
Also, das würde ich dann so machen:

Delphi-Quellcode:
procedure TForm1.SpeedButton1Click(Sender: TObject);
begin
  MyBusinessobj.doSpeedbutton1click;
end;
Die 4 Zeilen können doch eigentlich nicht stören.

Neumann 23. Apr 2021 19:09

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

Ganz schlimm

Schuby 23. Apr 2021 19:11

AW: Unit2 nicht unit1
 
Zitat:

Zitat von DieDolly (Beitrag 1487712)
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

Delphi.Narium 24. Apr 2021 17:16

AW: Unit2 nicht unit1
 
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 ;-)


Alle Zeitangaben in WEZ +1. Es ist jetzt 13:53 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz