AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Unit2 nicht unit1

Ein Thema von Schuby · begonnen am 23. Apr 2021 · letzter Beitrag vom 24. Apr 2021
Antwort Antwort
Seite 1 von 2  1 2      
Schuby

Registriert seit: 25. Dez 2018
93 Beiträge
 
#1

Unit2 nicht unit1

  Alt 23. Apr 2021, 19:06
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;
  Mit Zitat antworten Zitat
Neumann

Registriert seit: 6. Feb 2006
Ort: Moers
536 Beiträge
 
Delphi 12 Athens
 
#2

AW: Unit2 nicht unit1

  Alt 23. Apr 2021, 19:38
Delphi-Quellcode:
procedure TForm1.SpeedButton1Click(Sender: TObject);
begin
  form2.Memo1.Clear;
end;
Ralf
Gruß vom Niederrhein
  Mit Zitat antworten Zitat
DieDolly

Registriert seit: 22. Jun 2018
2.175 Beiträge
 
#3

AW: Unit2 nicht unit1

  Alt 23. Apr 2021, 19:39
Ich glaube Schuby meint das anders rum. Der Button soll in Unit 1 bleiben, das Event aber in Unit 2.
  Mit Zitat antworten Zitat
Neumann

Registriert seit: 6. Feb 2006
Ort: Moers
536 Beiträge
 
Delphi 12 Athens
 
#4

AW: Unit2 nicht unit1

  Alt 23. Apr 2021, 19:57
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.
Ralf
Gruß vom Niederrhein
  Mit Zitat antworten Zitat
DieDolly

Registriert seit: 22. Jun 2018
2.175 Beiträge
 
#5

AW: Unit2 nicht unit1

  Alt 23. Apr 2021, 20:00
Ich denke der Nutzen soll der sein, dass die Hauptunit von Code befreit wird, auslagern von Event-bezogenem Code in Extraunits.
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
2.508 Beiträge
 
Delphi 7 Professional
 
#6

AW: Unit2 nicht unit1

  Alt 23. Apr 2021, 20:07
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.

Geändert von Delphi.Narium (23. Apr 2021 um 20:10 Uhr) Grund: Text ergänzt.
  Mit Zitat antworten Zitat
Neumann

Registriert seit: 6. Feb 2006
Ort: Moers
536 Beiträge
 
Delphi 12 Athens
 
#7

AW: Unit2 nicht unit1

  Alt 23. Apr 2021, 20:07
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.
Ralf
Gruß vom Niederrhein
  Mit Zitat antworten Zitat
Neumann

Registriert seit: 6. Feb 2006
Ort: Moers
536 Beiträge
 
Delphi 12 Athens
 
#8

AW: Unit2 nicht unit1

  Alt 23. Apr 2021, 20:09
Oder irgendwo im Quelltext der Unit2:Form1.SpeedButton1Click(Sender);

Ganz schlimm
Ralf
Gruß vom Niederrhein
  Mit Zitat antworten Zitat
Schuby

Registriert seit: 25. Dez 2018
93 Beiträge
 
#9

AW: Unit2 nicht unit1

  Alt 23. Apr 2021, 20:11
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
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
2.508 Beiträge
 
Delphi 7 Professional
 
#10

AW: Unit2 nicht unit1

  Alt 24. Apr 2021, 18:16
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
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 07:48 Uhr.
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