![]() |
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; |
AW: Unit2 nicht unit1
Delphi-Quellcode:
procedure TForm1.SpeedButton1Click(Sender: TObject);
begin form2.Memo1.Clear; end; |
AW: Unit2 nicht unit1
Ich glaube Schuby meint das anders rum. Der Button soll in Unit 1 bleiben, das Event aber in Unit 2.
|
AW: Unit2 nicht unit1
Sowas könnte man zwar konstruieren, sehe aber keinen Nutzen.
Also etwa so umbiegen:
Delphi-Quellcode:
Würde ich nicht machen. Mag ja funktionieren, gefällt mir aber nicht.
SpeedButton1.onClick := form2.speedbuttonX.onclick;
|
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.
|
AW: Unit2 nicht unit1
Zitat:
Delphi-Quellcode:
Aber:
Form1.SpeedButton1Click(Sender);
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. |
AW: Unit2 nicht unit1
Also, das würde ich dann so machen:
Delphi-Quellcode:
Die 4 Zeilen können doch eigentlich nicht stören.
procedure TForm1.SpeedButton1Click(Sender: TObject);
begin MyBusinessobj.doSpeedbutton1click; end; |
AW: Unit2 nicht unit1
Oder irgendwo im Quelltext der Unit2:Form1.SpeedButton1Click(Sender);
Ganz schlimm |
AW: Unit2 nicht unit1
Zitat:
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 |
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 00:14 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz