Keine Frames unter Firemonkey (Teil 2)

[Neutral General]

Achja: Update 1 habe ich bei mir nicht installiert. Kann also nicht ausschließen, dass es dort evtl. verfügbar ist.

Vllt. kommts auch erst im nächsten Update.
Oder es ist ein Fehler im Wiki.
Oder wir sind nur zu blöd

[Uwe Raabe]

Ich vermute, das Wiki ist seiner Zeit voraus.

[bernau]

Zitat von Uwe Raabe:

Ich vermute, das Wiki ist seiner Zeit voraus.

Dann ist hoffen angesagt.

Übrigens gibt's im QC einen Eintrag wegen fehlenden Frames.

(Bitte jetzt voten!)

[mkinzler]

Bei FMX benötigt man keine Frames. Da ja jedes Control als Container für andere Controls dienen kann.
Siehe hierzu auch die Präsentation von der CodeRage 6
http://cc.embarcadero.com/item/28563

[Uwe Raabe]

Zitat von mkinzler:

Bei FMX benötigt man keine Frames. Da ja jedes Control als Container für andere Controls dienen kann.
Siehe hierzu auch die Präsentation von der CodeRage 6
http://cc.embarcadero.com/item/28563

Die Begründung zieht leider nicht. Auch in der VCL kann ein TPanel als Container für andere Controls dienen. Damit kann ich aber immer noch nicht die Fähigkeiten von Frames nachbilden. Mit Frames kann man schließlich ein Form in mehrere logisch getrennte Module aufteilen, wobei dabei auch die Programmlogik in unterschiedlichen Units liegt. Diese Module lassen sich dann sowohl in unterschiedlichen Forms als auch in einem Form mehrfach instanzieren. Ich sehe auch nicht den Ansatz einer solchen Funktionalität in den bei FMX zur Zeit verfügbaren Bordmitteln.

Unabhängig davon kann ich mich an eine Aussage im Q&A einer CodeRage-Session erinnern, bei der Frames in FMX als "on the roadmap" bezeichnet wurden.

[mkinzler]

In diesem Fall kann man dann anstatt eines Frames eine Form verwenden.

[bernau]

Zitat von mkinzler:

Bei FMX benötigt man keine Frames. Da ja jedes Control als Container für andere Controls dienen kann.
Siehe hierzu auch die Präsentation von der CodeRage 6
http://cc.embarcadero.com/item/28563

Habe mir das Video mal angeschaut. Es ist nicht direkt das selbe, da ich bei Frames zur Designzeit sehe, wie es von der Größe passt. Form in Form (wie es im Video beschrieben ist) sieht man erst mal nicht zur Designzeit. Man sieht nur ein Trägerpanel. Sonst hat es aber die gleiche Funktion wie ein Frame.

Muss aber sagen, es hat auch einige Vorteile. Mich hat es immer genervt, daß man ein eingefügtes Frame nicht sperren kann. Wenn ich zufällig eine Eigenschaft von einem Element in einem eingefüten Frame geändert habe (z.B. ausversehen verschieben), dann bleibt die Eigenschaft dort. Wenn ich das original Frame verändere, z.B. durch Neupositionierung der Controls, dann bleibt das veränderte Control an der Stelle stehen. Das passiert bei einer zur Laufzeit eingefüten Form natürlich nicht.

[Uwe Raabe]

Zitat von bernau:

Muss aber sagen, es hat auch einige Vorteile. Mich hat es immer genervt, daß man ein eingefügtes Frame nicht sperren kann. Wenn ich zufällig eine Eigenschaft von einem Element in einem eingefüten Frame geändert habe (z.B. ausversehen verschieben), dann bleibt die Eigenschaft dort. Wenn ich das original Frame verändere, z.B. durch Neupositionierung der Controls, dann bleibt das veränderte Control an der Stelle stehen. Das passiert bei einer zur Laufzeit eingefüten Form natürlich nicht.

Stimmt wohl. Leider verbaut man sich aber damit auch die Option, Elemente des Frames absichtich zu verschieben und diese Änderung nur in der gerade aktuellen Frame-Instanz zu machen.

Abgesehen davon kann man Frames ja auch erst zur Laufzeit einfügen, wenn man das denn so möchte.

[stahli]

Das Video ist dem dem Zusammenhang ganz interessant:
http://www.youtube.com/watch?v=gEVb-iDHyhY&feature=plcp

Wenn man nun das gewünschte Databinding noch im Designer angeben könnte (im Beispiel 'number' und 'symbol') gleich mit im Designer angeben könnte (statt alles im DoApplyStyleLookup von Hand zu schreiben), dann wäre das noch deutlich einfacher... bzw. nahezu genial.

Die Arbeitsweise ist sehr ungewohnt für uns, sieht aber vielversprechend aus.