Klar kann man das auch in einer
Unit kapseln, aber im Grunde würde sogar eine INCLUDE-Datei reichen.
Ich meine nicht
Unit sondern
Klasse. Dass die Klasse in einer eigenen
Unit steht, bietet sich logischerwese an, heißt aber erstmal nicht viel und könnte auch anders geregelt sein.
Zitat:
Das basiert ja alles auf Werten der
Unit "Forms".
Ja klar, deswegen hab ich ja meine Klasse von TForm abgeleitet.
Zitat:
Im Grunde steht doch alles Wesentliche im Typ "TMonitor" drin. Es kommt also allenfalls darauf an, Schnittstellen bereitzustellen, mit denen das Hauptprogramm dann kommunizieren kann.
Ja, eben. Und dafür sind globale Variablen ungeeignet.
Zitat:
Aber erzähl doch mal, was Du gekapselt haben willst, bzw. auch wie.
Ich kann meine
Unit nehmen und - so wie sie ist - wiederverwenden. Beispiel: Ich erstelle ein neues Projekt, binde diese
Unit ein, erstelle ein weiteres Formular, ändere dort die Ableitung von TForm auf TFormEx und benutze dann simpel z.B. den Aufruf
neueForm.Show(fmActive, Self.Handle)
. Fertig. Ich brauche keine weiteren Variablen (vor allem keine globalen), ich muss nichts mehr an der Form rumschieben (auch wenn das natürlich weiterhin möglich ist) oder mich in irgendeiner Weise mit der Ermittlung von Monitoren rumschlagen, weil das alles die Klasse TFormEx bereits macht. Oder ich geb die
Unit weiter an jemand anders, und der kann sie ohne viel Gefummel einbinden. Wiederverwendung von Code eben.
Zitat:
Die Sache mit nicht gefundenen Resourcen läßt sich in der Regel per Übergabeparameter regeln.
Nein, tut es nicht. Jedes Formular einer von TForm abgeleiteten Klasse braucht eine passende
DFM(-Ressource).
Zitat:
Das mit "ShowModal" läßt sich wohl auch noch rausfinden, aber ich würde sowas eher mit FormStyle "fsStayOnTop" und BorderStyle "bsToolWindow" machen, wie z.B. bei diversen Grafikprogrammen.
Ein modales Fenster hat nichts mit einem immer im Vordergrund befindlichen Fenster zu tun. Das sind zwei völlig verschiedene Dinge.
MfG Dalai