Keine Frames unter Firemonkey

[neo4a]

Zitat von Union:

Ich glaube dass wirlich 90% hier Frames mit Panels verwechseln.

Wenn man es schafft, das GUI von der Anwendungslogik zu trennen, ist das kein Fehler. BTW, wieviel genau meinst Du mit 90% von bisher 7 Postern in diesem Thread?

[Uwe Raabe]

Zitat von neo4a:

Zitat von Union:

Ich glaube dass wirlich 90% hier Frames mit Panels verwechseln.

Wenn man es schafft, das GUI von der Anwendungslogik zu trennen, ist das kein Fehler. BTW, wieviel genau meinst Du mit 90% von bisher 7 Postern in diesem Thread?

Na, eben alle bis auf einen und der halt zu 30%

[neo4a]

Zitat von Uwe Raabe:

Zitat von neo4a:

Zitat von Union:

Ich glaube dass wirlich 90% hier Frames mit Panels verwechseln.

Wenn man es schafft, das GUI von der Anwendungslogik zu trennen, ist das kein Fehler. BTW, wieviel genau meinst Du mit 90% von bisher 7 Postern in diesem Thread?

Na, eben alle bis auf einen und der halt zu 30%

Das willst Du aber noch einmal nach rechnen, oder?!

[bernerbaer]

Ich hoffe, dass ich nicht zu den 90% gezählt werde, die Frames mit Panels verwechseln.

Trotzdem stellt sich mir hier die Frage, welche Vorteile bieten Frames gegenüber Forms?

So wie ich das beurteile:

Vorteile Frames:
- Einbettung zur Designzeit
- Einfachere Kommunikation zwischen Form und Frame

Nachteile Frames:
- funktioniert nicht in Firemonkey
- Keine Events wie OnCreate, OnDestroy, OnShow, OnHide, OnActivate, OnDeactivate oder OnKey...

Vorteile Form:
- Alle Events der Form vorhanden
- Jederzeit einsetzbar

Nachteile Form:
- Kommunikation zwischen ParentForm und eingebetteter Form muss evtl über Interfaces gelöst werden
- Einbettung erfolgt per Code

Fazit für mich: ich verwende Forms in Forms

[Phoenix]

Zitat von bernerbaer:

NachVorteile Form:
- Kommunikation zwischen ParentForm und eingebetteter Form muss evtl kann vernünftig über Interfaces gelöst werden

So siehts besser aus.

[bernau]

Zitat von bernerbaer:

Nachteile Frames:
- funktioniert nicht in Firemonkey
- Keine Events wie OnCreate, OnDestroy, OnShow, OnHide, OnActivate, OnDeactivate oder OnKey...

Die zugehörigen Methoden (constructor create...) kannst du aber sehr wohl überschreiben. Musst halt statt einem Doppelklick auf dem Objektinspektor die eine zeile Code hinzufügen.



Fazit für mich: Die Vorteile von Frames überwiegen.

[Uwe Raabe]

Zitat von neo4a:

Zitat von Uwe Raabe:

Zitat von neo4a:

Zitat von Union:

Ich glaube dass wirlich 90% hier Frames mit Panels verwechseln.

Wenn man es schafft, das GUI von der Anwendungslogik zu trennen, ist das kein Fehler. BTW, wieviel genau meinst Du mit 90% von bisher 7 Postern in diesem Thread?

Na, eben alle bis auf einen und der halt zu 30%

Das willst Du aber noch einmal nach rechnen, oder?!

Gerne!

90% von 7 = 6,3
Alle bis auf einen = 6
30% von einem = 0,3
6 + 0,3 = 6,3

An dem Wahrheitsgehalt dieser Größe wage ich allerdings zu zweifeln.

[neo4a]

Zitat von Uwe Raabe:

Alle bis auf einen = 6
30% von einem = 0,3
6 + 0,3 = 6,3

Merkel: "Aber das ist doch wohl nicht Ihr Ernst, Herr Jauch".

[Uwe Raabe]

Zitat von neo4a:

Zitat von Uwe Raabe:

Alle bis auf einen = 6
30% von einem = 0,3
6 + 0,3 = 6,3

Merkel: "Aber das ist doch wohl nicht Ihr Ernst, Herr Jauch".

[implementation]

Also ich denke, statt jetzt in FMX Frames einzuführen, sollte Emba lieber Custom Controls vereinfachen

So einige Posts in diesem Thread sagen mir, dass es dafür immer noch keinen vernünftigen Support vom Formdesigner gibt.
Aus dem Visual Studio kenne ich es, dass dort
a) Man beim Erstellen des Controls selbst bereits den Designer nutzen kann (wie in D bei Frames)
b) Erstellte Controls gleich in der Liste verfügbar sind (wie in D bei Frames)
und deshalb braucht man dort keine Frames. Eben weil sich alles mit Custom Controls realisieren lässt.

Ich habe Delphi nach der Turbo verlassen und weiß nicht, wie es mit dem Designer dort aussieht, aber ich bin einfach davon ausgegangen, dass der auch verbessert wurde

Und nein, ich verwechsle Frames nicht mit Panels.
Eine Designerverbesserung würde Frames gänzlich überflüssig machen.