Zitat:
Zurecht wie ich meine. Wie auch immer die abgelegten Formulare aussehen mögen, es ist doch meistens etwas dabei was man nicht haben will.
Es lebe der Fundamentalismus. Break und exit sind böse, with ist urböse, für die Verwendung von goto ist Steinigung die adäquate Stafe, und neuerdings ist Vererbung auch schon ganz schlecht.
Wenn ich bestimmte Features einheitlich in allen meinen Formularen haben will, dann ist die Ableitung meiner Formulare von einem Vorfahr, der alle diese Features beinhaltet, die ADÄQUATE Vorgangsweise. natürlich gibt es auch andere Möglichkeiten, man kann Frames definieren, man kann Helper-Komponenten auf alle Formulare ziehen, man kann sich mit einer Factory behelfen etc. etc. Alle diese Möglichkeiten würde ich auch ins Auge fassen, wenn es in Delphi nicht zum Glück die einfachste und beste Lösung, nämlich die Vererbung, geben würde.
Zitat:
Zitat von Hansa:
Auch speichern des aktuellen Standes.
Dafür gibt es Komponenten wie z.B. TFormStorage. Diese Komponenten können jedes Property des Formulars und aller darauf enthaltenen Komponenten in die Registry oder eine Ini-Datei speichern und auch wieder laden.
Wenn ich das will, macht es sicher Sinn, so eine Komponente zu verwenden. Wenn ich in einer einfachen Anwendung einfach nur die Formularposition beim Schliessen in ein Ini-File schreiben und beim Öffnen wieder aus dem Ini-file lesen will, gibt es kein vernünftiges Argument, die entsprechenden Vierzeiler nicht direkt im Code des Formulars zu integrieren. Aber auch wenn ich eine eigene Komponente verwende, kann ich den Aufruf der entsprechenden Funktionalität in mein zu vererbendes Urformular einbauen. Dass ein Formular weiss, wo es zuletzt zugegangen ist und dort auch wieder aufgeht, verstösst bestimmt auch nicht gegen das Allerwichtigste, nämlich das Single Responsability Prinzip.