Frame: Button OnClick handler manchmal nicht zugewiesen?

[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)