Frame: Button OnClick handler manchmal nicht zugewiesen?

[himitsu]

Zitat:

Damit verbirgt man ...

Security through Obscurity


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 von himitsu:

Security through Obscurity

Eher Information hiding.

Zitat von himitsu:

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 von himitsu:

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 von himitsu:

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 von himitsu:

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.