Frame: Button OnClick handler manchmal nicht zugewiesen?

[TurboMagic]

Hallo,

gegeben ist ein Delphi 11.1 VCL-Frame mit u.a. 2 Buttons drauf.
Dieses Frame ist in 2 Dialogen eingebunden.

In einem funktionieren beide Buttons, im anderen feuert nur
der eine seinen OnClick Handler im Frame.

Schaut man die Ereignisse beider Buttons in beiden Formularen an,
ist jeweils kein OnClick Handler definiert. Das scheint aber richtig
zu sein, da dieser ja jeweils im Frame definiert ist.

Woran kann das liegen?

Grüße
TurboMagic

[hoika]

Hallo,
du klickst die Buttons mit der Maus an?
Ist auf dem 2. Form ein Grid?

[Der schöne Günther]

Schau dir unbedingt die DFM-Dateien der beiden Formulare an.

Mir ist das schon untergekommen dass auf einem Formular dann tatsächlich explizit stand

Delphi-Quellcode:

meinFrame.meinButton.OnClick = nil

. Im Objektinspektor bekommt man davon nichts mit.

[bcvs]

Mir passiert es manchmal, dass ein Event, der im Frame nachträglich hinzugefügt wurde, von dem Form aus, auf dem der Frame liegt, nicht feuert.

Dann erzeuge ich den Event nochmal vom Form aus und lasse ihn leer. Bein nächsten Speichern wird er wieder automatisch entfernt, aber die Verbindung zum Event auf dem Frame ist wieder hergestellt. Was da intern genau passiert, weiß ich allerdings auch nicht.

[TurboMagic]

1. Nein, es ist kein Grund drauf

2. Danke für die Tipps mit dem dfm prüfen und Event neu zuweisen.
Zu letzterem wäre Mal zu schauen ob das in QP erfasst ist
und wenn nicht dann bitte erfassen und Nummer hier melden.

3. Ich habe auch schon Mal das Frame entfernt und neu hinzugefügt
aber ohne Erfolg

Grüße
TurboMagic

[TurboMagic]

Zitat:

Zitat von Der schöne Günther (Beitrag 1505759)

Schau dir unbedingt die DFM-Dateien der beiden Formulare an.

Mir ist das schon untergekommen dass auf einem Formular dann tatsächlich explizit stand

Delphi-Quellcode:

meinFrame.meinButton.OnClick = nil

. Im Objektinspektor bekommt man davon nichts mit.

Keine Ahnung woher sowas kommen kann aber: das war wirklich das Problem!
Aber achtung: man darf wirklich nur die Zeile mit dem nil löschen, die darüber mit dem
inherited button darf man nicht löschen, sonst sind plötzlich alles icons und so im ganzen Formular weg ;-)
Aber wozu gibt's ja Versionskontrolle? ;-)

[hoika]

Hallo,
MMX EventView wäre vielleicht hier ein Check-Instrument.

[Uwe Raabe]

Zitat:

Zitat von hoika (Beitrag 1505790)

MMX EventView wäre vielleicht hier ein Check-Instrument.

:-D

[dummzeuch]

Wegen solcher spaßigen Probleme, bei denen man dann ggf. stundenlang nach der Ursache sucht, bin ich dazu übergegangen, Frames nicht mehr zur Designtime auf Formularen zu platzieren. Es gibt nur noch ein Panel als Platzhalter und die Frames werden zur Laufzeit erzeugt und platziert. Dann kann sowas nicht mehr passieren.

[TurboMagic]

Hallo,

danke für den Tipp das zur Laufzeit zu platzieren.
Die Frage wäre jetzt halt, ob alle diese Probleme schon in QP erfasst sind, in der Hoffnung,
dass die dann der Reihe nach mal abgearbeitet werden.

Man möchte sein RAD Tool ja schließlich auch als RAD Tool benutzen... ;-)

Grüße
TurboMagic

[Uwe Raabe]

Könnte dies hier sein: Removing Click event on form blocks same event on frame

[TurboMagic]

Sieht ganz danach aus. Habe gleich mal dafür gestimmt ;-)

[Der schöne Günther]

Zitat:

Zitat von dummzeuch (Beitrag 1505794)

Wegen solcher spaßigen Probleme, bei denen man dann ggf. stundenlang nach der Ursache sucht, bin ich dazu übergegangen, Frames nicht mehr zur Designtime auf Formularen zu platzieren. Es gibt nur noch ein Panel als Platzhalter und die Frames werden zur Laufzeit erzeugt und platziert. Dann kann sowas nicht mehr passieren.

Genau das mache ich mittlerweile meistens auch. Bonus: Der Formular-Designer lädt auch schneller und flackert sich beim Seitenaufbau nicht mehr so einen zurecht.

[Uwe Raabe]

Weiterer Bonus: Man kann die Frame-Units in die Uses-Clause des Implementation Teil verlagern oder gleich die Frames über ein Factory-Pattern erzeugen. Das reduziert den Dependency-Wert oft gewaltig und sorgt nebenbei für eine strukturiertere Architektur.

[bernau]

Zitat:

Zitat von Uwe Raabe (Beitrag 1505819)

Weiterer Bonus: Man kann die Frame-Units in die Uses-Clause des Implementation Teil verlagern oder gleich die Frames über ein Factory-Pattern erzeugen. Das reduziert den Dependency-Wert oft gewaltig und sorgt nebenbei für eine strukturiertere Architektur.

Sollte man nicht units im Implementation-Teil vermeiden. Die Gefahr der zirkulären Abhängigkeit wird damit reduziert, wenn man die Units im Interface-Abschnitt auflistet.



Siehe auch https://docwiki.embarcadero.com/RADS..._Units_(Delphi)

Zitat:

To reduce the chance of circular references, it's a good idea to list units in the implementation uses clause whenever possible. Only when identifiers from another unit are used in the interface section is it necessary to list that unit in the interface uses clause.

[Uwe Raabe]

Zitat:

Zitat von bernau (Beitrag 1506015)

Sollte man nicht units im Implementation-Teil vermeiden. Die Gefahr der zirkulären Abhängigkeit wird damit reduziert, wenn man die Units im Interface-Abschnitt auflistet.

Davon bin ich ein strikter Gegner! Das ist zwar einfacher für den Entwickler, unterstützt aber meiner Meinung nach nur die Faulheit nicht über eine entsprechende Architektur nachdenken zu müssen.

[Frickler]

Zitat:

Zitat von bernau (Beitrag 1506015)

Sollte man nicht units im Implementation-Teil vermeiden. Die Gefahr der zirkulären Abhängigkeit wird damit reduziert, wenn man die Units im Interface-Abschnitt auflistet.

Nee genau andersherum. Steht da doch auch:

Zitat:

To reduce the chance of circular references, it's a good idea to list units in the implementation uses clause whenever possible. Only when identifiers from another unit are used in the interface section is it necessary to list that unit in the interface uses clause.

[Uwe Raabe]

Abgesehen davon sagt das Zitat das genaue Gegenteil von dem was es meint...

[himitsu]

Ja, ich versuche auch immer ALLES, was möglich ist, im Interface anzugeben.
Da ist dann auch die Reihenfolge sichergestellt.

Es gibt aber auch Kollegen, die sind vehement der Meinung, dass man ALLES was möglich ist, in die Implementation machen MUß! :wall:


Im Interface wird ALLES so wie es da steht, in der Reihenfolge vor der eigenen Unit geladen/initialisiert.
Wenn etwas in den eingebundenen Units geladen wird, dann das natürlich entsprechend auch wieder zuerst.

In Implementation kann unterliegt die Reihenfolge im USES dem Gutdünken des Compilers und es kann sogar passieren, dass Units erst nach dem eigenen Initialization, bzw. nach eigenen Class-Constructor's vorhanden ist.
Greift man also im Initialization/ClassConstructor auf eine Variable/Funktion zu, kann es sein, das diese noch garnicht initialisiert ist, wenn die Unit im Implementation steht ... wenn in Interface, dann ist es immer schon da.
Genau andersrum beim Finalizaition, da kann es, wenn im Uses der Implementation, dann schon weg sein, bevor das eigenen Finalization/ClassConstructor anläuft.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1506026)

Es gibt aber auch Kollegen, die sind vehement der Meinung, dass man ALLES was möglich ist, in die Implementation machen MUß!

Genau! Und das ist auch richtig :)
Damit verbirgt man die Details der Implementierung, die ja niemanden was angehen.

Natürlich gibt es keine Regel ohne Ausnahme, aber für mich gehört nur das in den Interface-Teil was da unbedingt nötig ist. (We agree to disagree)

[himitsu]

Zitat:

Damit verbirgt man ...

Security through Obscurity :roll:


Im Idealfall hab ich so aber auch nur ein Uses, was ich irgendwie schon bissl übersichtlicher empfinde.


Im Interface ist es immer in der selben Reihenfolge.
In der Implementation könnte, selbst bei unverändertem Code, bei jedem Compilieren was in einer anderen Reihenfolge geladen werden, was bei einer Fehlersuche besonders viel Spaß macht.

Aber das Wichtigste, im Interface habe ich nie "ausversehn" mal unbemerkte Kreisreferenzen drin ... in der Implementation fällt dir das nie auf,
außer da unten steht nur das drin, was absichtlich dort steht, wegen einer bekannten Kreuz-/Kreisreferenz.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1506028)

Security through Obscurity

Eher Information hiding.

Zitat:

Zitat von himitsu (Beitrag 1506028)

In der Implementation könnte, selbst bei unverändertem Code, bei jedem Compilieren was in einer anderen Reihenfolge geladen werden

Das kann nur bei zyklischen Abhängigkeiten passieren, aber die lassen wir ja nicht zu.

Zitat:

Zitat von himitsu (Beitrag 1506028)

im Interface habe ich nie "ausversehn" mal unbemerkte Kreisreferenzen drin ... in der Implementation fällt dir das nie auf,

Das ist genau das obige Argument mit der Faulheit. Bei einer sauberen Architektur entstehen erst gar keine Zyklen und zur Sicherheit gibt es ja Code-Checks, die das spätestens beim Einchecken monieren.

Aber ich denke, das Thema ist zumindest hier nun ausreichend diskutiert. Wir können das gerne an anderer Stelle vertiefen wenn du möchtest.

[bernau]

Zitat:

Zitat von himitsu (Beitrag 1506028)

Aber das Wichtigste, im Interface habe ich nie "ausversehn" mal unbemerkte Kreisreferenzen drin ... in der Implementation fällt dir das nie auf, außer da unten steht nur das drin, was absichtlich dort steht, wegen einer bekannten Kreuz-/Kreisreferenz.

Genau so. Das hat auch nichts mit Faulheit zu tun. Es ist lediglich eine Hilfe, das diese "schrecklichen" zirkulären Referenzen sich nicht einschleichen.

[dummzeuch]

Ich sehe das wie Uwe. Weiterer Vorteil: Änderungen an Units, die in der Implementation Uses-Liste stehen, erfordern kein Neuerstellen der sie verwendenden DCUs. Nicht, dass das bei einem One-Pass-Compiler groß in's Gewicht fiele.

[Frickler]

Btw: gibts eigentlich ein Tool, welches

• Units, die im Interface-Teil angegeben werden, aber dann nur im Implementation-Teil verwendet werden, vom Interface- in den Implementation-Teil verschieben kann?
• Units, die gar nicht verwendet werden, aus der jeweiligen Unit-Liste löschen kann?

[Uwe Raabe]

Peganza's Pascal Analyzer (vermutlich auch die Lite Version) gibt das zumindest als Report aus. Eine automatische Änderung ist auch nicht immer sinnvoll, da gelegentlich die IDE auf bestimmte Units im Interface-Teil pocht und auch andere Gründe gegen eine Verlagerung in den Implementation-Teil sprechen können (z.B. Reihenfolge von WinApi.Windows und System.Sysutils o.ä.).

Für die manuelle Verschiebung vom einen in den anderen Teil verwende ich immer die entsprechende Funktion (Shift-Ctrl-Alt-Up/Down innerhalb einer uses-Anweisung) im MMX Code Explorer.

[himitsu]

"gar nicht verwendet" ist auch nicht immer zutreffend.

Ich kann eine Unit einbinden, welcher im Initalization sich irgendwo registriert, was ich dann später benötige,
aber dennoch nirgendwo anschließend im Code direkt auf diese Unit direkt zugreifen.

Automatisch rausgeworfen darf also garnicht werden.

[Frickler]

Zitat:

Zitat von himitsu (Beitrag 1506077)

Ich kann eine Unit einbinden, welcher im Initalization sich irgendwo registriert, was ich dann später benötige, aber dennoch nirgendwo anschließend im Code direkt auf diese Unit direkt zugreifen.

Sollte so etwas in meinen Projekten vorkommen, erstelle ich eine eigene Unit "indirectimports.pas" oder so, die diese Units einbindet, und die ich dann einbinde. So weiß ich, dass ich das nicht rauswerfen darf.

[Uwe Raabe]

Man kann diese Units auch explizit im Projekt einbinden. Die Units in der DPR werden überwiegend sowieso dort nicht direkt verwendet.

In letzter Zeit spendiere ich solchen Units wenn möglich eine Register/Unregister Prozedur, die dann bei Bedarf aufgerufen werden.