gestern habe ich die Diskussion über "MDI vs Tabbed Interface" begonnen. Ich habe gefragt, ob ich meine App weiterhin als MDI-basiert entwickeln sollte, oder ob ich die untergeordneten Formulare in Tabs einbetten soll. Jemand hat darauf hingewiesen, dass ich stattdessen TFrames verwenden soll ... Meine Frage ist: Warum?
Was sind Vorteile bei der Verwendung von TFrames beim Einbetten des Formulars über TFrame? Bisher kenne ich keine, ich müsste nur einige Teile des Codes neu schreiben ...
(Ich werde die Einbettung sowieso nicht zur Entwurfszeit verwenden!)
Vielen Dank im Voraus
Beantworten Sie den Kommentar, um einen Grund für die Verwendung von Frames anzugeben:
Ich würde Frames als Bausteine der GUI betrachten, mit Design-Zeit-Kombination von bestehenden Komponenten zu fortgeschritteneren Komponenten. Vor Delphi 5 hätte man ein TCustomPanel -Dekendant mit untergeordneten Steuerelementen verwendet und dies als neue Komponente registriert, die bereit ist, auf ein Formular abgelegt zu werden. Frames ermöglichen das gleiche mit weniger Aufwand.
Sie können sich darauf konzentrieren, genau die Funktionalität zu entwickeln, die Sie brauchen, und nicht mehr. Fertig gemacht können Sie sie dann in Registerkarten, in modale oder nicht modale Dialoge, in MDI-Child-Frames und in Standard-Frames einbetten. Sie können sogar mehrere davon zu einem Formular hinzufügen - etwas, das man mit eingebetteten Formularen wahrscheinlich nicht machen würde. Der Punkt ist, dass für maximale Wiederverwendbarkeit oft ein mehrschichtiger Ansatz notwendig ist und Frames dabei helfen.
Ein Rahmen ist für die Einbettung von unterwegs geeignet. Ein Formular muss so angepasst werden, dass keine Titelleiste und Rahmen angezeigt werden. In der Regel würde man CreateParams() überschreiben und den Fensterstil entsprechend anpassen. Es gibt eine Menge mehr Formulareigenschaften im Inspektor, die für ein eingebettetes Formular einfach keinen Sinn ergeben. IMHO sollte man die grundlegendste und generische Entität verwenden, die ausreicht. Ein Formular ist einfach viel mehr als ein Steuerungscontainer für die Einbettung.
OTOH Ich kenne keinen Nachteil beim Einbetten eines Frames, den ein Formular nicht einbetten würde.
Bearbeiten:
Es gibt einen Kommentar zu Ereignissen wie OnCreate oder OnShow , die Frames nicht haben. Eigentlich würde ich das als einen weiteren Vorteil von Frames betrachten, da Event-Handler keine Parameter haben, also wird eine Menge von Dingen in Formularen notwendigerweise fest codiert.
Berücksichtigen Sie den Fall von Benutzereinstellungen: In OnCreate stehen nicht viele Informationen zur Verfügung, daher wird immer eine Konstante oder der Name des Formulars für den INI-Dateiabschnitt verwendet, was es sehr schwierig oder sogar unmöglich macht das Formular erneut verwenden oder mehrere Instanzen davon erstellen. Bei Frames hingegen ist eine Methode LoadSettings die naheliegendste Art, dies zu tun, und sie kann die notwendigen Parameter tragen. Auf diese Weise wird die Steuerung dorthin zurückgeführt, wo sie hingehört, in den Container des eingebetteten Rahmens / Formulars. Wiederverwendbarkeit ist nur möglich, wenn das Verhalten von außen einstellbar ist.
Für enthaltene Objekte, die keine Komponenten sind und lebenslang verwaltet werden müssen, gibt es beispielsweise AfterConstruction und BeforeDestruction .
Vielleicht finden Sie in diesem Thread einige Antworten: gui-design-multiple-forms-vs-simuliert-mdi-tabs-vs-pagecontrol
Frame verwendet die schnellste Ladezeit und ohne Verzögerung beim Erstellen des Frames.
Aber der Rahmen sollte ein Elternteil haben, um ihn einzubetten. Nachteil ohne onCreate oder onShow Event wurde ausgelöst. aber Sie können mit Nachricht für Trigger onShow Ereignis wie dieses aufrufen:
setze privaten Teil des Frames:
%Vor%und dann den Code wie folgt erstellen:
%Vor%Hope kann Ihnen helfen, eingebettete Frames für die GUI in Betracht zu ziehen.
Sie können in Kombination mit PageControl die Rahmenöffnung steuern.
Manz
Ich hatte dieselbe Entscheidung vor einigen Jahren für eine unserer Anwendungen, wir wollten es eingebettete Formulare aussehen lassen, zuerst habe ich die Frames verwendet und ich habe eine Klasse geschrieben, um es zu verwalten.
Später fand ich die TLMDDisplayForm-Komponente von LMDTools , was das Einbetten von Formularen sehr einfach machte, es reduzierte den verwendeten Code und wir haben mehr Funktionen.
Eines der Hauptziele, die wir von Frames auf Forms geändert haben, waren einige Ereignisse von TForm wie OnCreate, OnShow, OnActive, die wir für einige Aufgaben in unseren Anwendungen verwenden, sowie fehlende Eigenschaften wie ActiveControl und andere Dinge, die ich nicht verwende Erinnere dich.
Wenn Sie mit Formularen arbeiten möchten, rate ich Ihnen, LMDTools zu verwenden, die Ihnen die Aufgabe erleichtern, neben den grundlegenden Version ist kostenlos: -)
Für dynamisch eingefügte Formulare / Frames bevorzuge ich persönlich eingebettete Formulare über Frames. Mehrere Versionen zurück, wenn man einen Frame bearbeiten würde, der auf alClient gesetzt wurde, würde der Frame zwischen den Edits skalieren und alle Controls, die auf der rechten Seite des Frames ausgerichtet waren, würden die Position ändern. Bei eingebetteten Formularen ist das nicht passiert, also habe ich den Switch gemacht. Ich glaube, dieses Problem ist jetzt mit späteren Versionen von Delphi behoben.
Ich stimme den Punkten, die Mghie zuvor gemacht hat, in Bezug auf die Unfähigkeit, Informationen durch eingebettete Ereignisse an das eingebettete Formular weiterzuleiten, vorbehaltlos zu. Um dies zu lösen, implementiere ich in der Regel eine Reihe von Schnittstellen in jede eingebettete Form für die Kommunikation. Dies vereinfacht den Code und ermöglicht allgemeinere Implementierungen, bei denen Sie einen einzelnen "Container" haben, der mit vielen verschiedenen Arten von eingebetteten Formularen / Frames umgehen wird. Ein paar Beispiele dafür finden Sie in meinem Blog als Teil des von mir entworfenen Assistenten-Frameworks.
Ich denke, beide sollten verwendet werden. Zum Beispiel habe ich einen "Standard" -Rahmen, der eine dbnavigator-, dbgrid- und Datenquellen-Komponente hat, was sehr praktisch für das typische Durchsuchen von Daten ist. Anstatt solche Komponenten jedes Mal einzufügen, füge ich einen Rahmen ein, der auch die Möglichkeit hat, seine Daten (mit JVCL: D) in mehrere Formate zu exportieren ... aber ich weiß, was ich zur Entwurfszeit anzeigen möchte, also schlage ich ein sehr vor Einfache Regel: Wenn es zur Entwurfszeit bekannt ist, verwenden Sie Frames, andernfalls verwenden Sie eingebettete Formulare.
Beachten Sie jedoch, dass Formulare nicht eingebettet werden sollten. Wenn man sie so benutzt, ist es unnatürlich (wie ein Vampir sagt, wenn sie ihre 80 Jahre alte Tochter begräbt und sie wie 30: D aussieht). Die eingebettete Form weiß wenig über den Besitzer und kann (logisch) davon ausgehen, dass sie nicht eingebettet ist.
Zusätzlich dazu ist ein Frame eine Komponente, und wenn er in ein Formular eingebettet ist, weiß das Formular davon und der Frame kennt das Formular (kann seine Methoden und Eigenschaften verwenden. Ein eingebettetes kann auch Tun Sie das, aber erfordert zusätzliche Codierung)
Vielleicht könnte Embarcadero uns helfen, indem wir ein TEmbeddableForm oder eine Schnittstelle für solche Zwecke erstellen
Grüße, Alvaro Castiello