Firemonkey Berlin 10.1 GUI Chaos

[stalkingwolf]

Evtl ist Chaos übertrieben.

Aber ich versuche gerade ein Programm zu schreiben was auf Android und auf Windows laufen soll.
Primär nutze ich daher bei ControlType = Platform. Aber das gibt es nicht bei jedem Element.

Daher sieht die GUI ohne das man massiv nachhilft wie hingekotzt aus.
Viele Buttons passen nicht. Mal weiß mal grau als Hintergrund.
Unter Windows werden Comboboxen nicht angezeigt. Sieht aus als wären sie unsichtbar.

nun ist mir einfach ein TDateEdit Feld unter Windows verschwunden. Auf dem Androidgerät wird es angezeigt.
Fährt man mit der Maus drüber dann wird der Cursor zum Eingabecursor geändert. Trifft man zufällig das Element, geht sogar der Kalender auf.

Ich setze unzählige TLayouts, damit überhaupt Struktur in die UI kommt und mir Elemente nicht andere Elemente verdecken.
z.b habe ich ein Panel. Die untere Kante soll ein Trenner zum nächsten Element sein.
Packe ich ein detailstoolbuttonbordered rein und setze ihn auf Align z.b right, dann ist der größer als andere Buttons und sogar größer als das Panel darunter.

War das schon immer so grauenhaft unter Firemonkey?

[Sherlock]

Also ich hatte auch zu kämpfen...aber unter Seattle. Und ganz so furchtbar ist es nicht gewesen, wie Du es schilderst. Ich habe einiges an Controls in Verwendung. Gruppieren/Strukturieren sollte man die IMHO in TListBox und nicht irgendwelche Panels oder Layouts, das hat in der Tat auch bei mir Anfangs nur zu Chaos geführt. Sehr hilfreich sind aber TTabControl zum gruppieren von Funktionsgruppen. Es hat mich runde zwei Monate gekostet eine GUI zu basteln, die jetzt sowohl Windows also auch die diversen Apple-OS beherrscht. In VCL wäre das maximal eine Woche gewesen. Übrigens nutze ich nur Bordmittel, und keine Geräte oder OS-spezifischen Layouts (oder wie das jetzt heisst)

Sherlock

[stalkingwolf]

das hier treibt mich gerade in den Wahnsinn.
Es war vorher ok und nu auf einmal ist der unsichtbar.
Auch löschen und neu hinzufügen bringt nichts.

Im Master sieht und der Ansicht wenn ich Windows hinzufüge ist auch alles ok.
Mit einer Combobox habe ich das gleiche Problem.

[Der schöne Günther]

Du hast aber nicht zufällig ein Mini-Projekt zum Nachstellen, oder?

[bra]

Das Mixen von nativen und normalen FMX-Elementen ist keine so gute Idee, weil die nativen je nach Plattform immer im Vordergrund sind und die normalen selbstgezeichneten FMX-Komponenten überlagern.

Siehe http://docwiki.embarcadero.com/RADSt...teuerelementen

Ein ähnliches Verhalten gibt es unter iOS/Android mit den DPF-Komponenten.

[stalkingwolf]

Wollte gerade ein kleines Programm schreiben und habe das Problem gefunden.

Wenn das TDateEdit auf einem TPanel sitzt und man setzt ControlType bei dem TPanel auf Platform, dann tritt das Problem auf.
Vermutlich weil TDateEdit kein ControlType hat.

Setzt man noch ein TEdit dazu und setzt ControlType auf Platform wird das TEdit angezeigt. Setzt man es auf Styled ist auch das weg.

Zitat von bra:

Das Mixen von nativen und normalen FMX-Elementen ist keine so gute Idee, weil die nativen je nach Plattform immer im Vordergrund sind und die normalen selbstgezeichneten FMX-Komponenten überlagern.

So einfach ist das aber nicht, da TDateEdit gar keine Eigenschaft dafür hat und sich selber darum kümmert. TDateEdit sieht auf dem Android Gerät ganz anders als unter Windows aus. Gleiches bei den TComboboxen.

[mensch72]

Da wie es sich anhört bei den "Effekten" ja wohl eh noch kein Funktionscode im Projekt ist, einfach mal das Projekt hier gepackt hochladen.

Wichtig wäre noch zu wissen, was die Zielstellung ist... soll die GUI plattformunabhängig "einheitlich" sein ODER soll die GUI plattformabhängig möglichst "native" aussehen?

[bra]

Zitat von stalkingwolf:

So einfach ist das aber nicht, da TDateEdit gar keine Eigenschaft dafür hat und sich selber darum kümmert. TDateEdit sieht auf dem Android Gerät ganz anders als unter Windows aus. Gleiches bei den TComboboxen.

Die FMX-Komponenten sehen auf den verschiedenen Plattformen auch unterschiedlich aus, nur wird das Verhalten hier sozusagen kopiert. Die Option "ControlType = Platform" bedeutet doch nur, dass die echte native Komponente der jeweiligen Plattform verwendet wird (mit all den beschriebenen Nebeneffekten).

Und was du beschreibst ist genau das beschrieben Verhalten: TPanel = Nativ, hängt vor dem Nicht-Nativen TDateEdit.

[mensch72]

eigentlich muss/sollte man sich entscheiden: entweder nur native ControlTypes für ALLES verwenden, ODER alles per FMX-Controls lösen

Wenn man GUI und Daten/Funktion sauber trennt, ist es auch garnicht so viel (Zusatz)Aufwand wenn es denn sein soll pro Plattform eine eigene native GUI zu designen, wo nur das verwendet wird was es dort auch gibt. DPF odet TMS bieten da ja auch Zugriff auf quasi alles was es native für Android/IOS/OSx gibt.

Das MultiView Konzept FMX halte ich plattformübergreifend ala Desktop&Mobile da (noch) für ungeeignet. MultiView ist brauchbar wenn man für verschiedene Formate jeweils eine GUI DesignVariante auf/mit einem Quelltext verwenden will(aber wir hatten da bevor es MultiView gab schon einen eigene IFDEF basierte Lösung mit vom SharedSource getrennter GUI).
Wir verwenden MultiView/SharedSourceGUI nur innerhalb einer Plattform für Hochformat/Querformat(/Quaratisch/SmartWatch), wo wir selbst ohne "responsive Design" lieber manuell alles passend anordnen. Selbst wenn wir nur pure StandardFMX Sachen verwenden, designe ich die definitiv die Desktop & Mobile Variante getrennt (also 1x Windows&OSX plus 1x Android&IOS)

[Harry Stahl]

In der Hauptsache ist mixen vor allem dann keine gute Idee, wenn der Container für ControlType den Wert "Platform" hat.

Du müsstest hier nur das Panel auf Styled setzen, dann werden alle Controls im Panel richtig angezeigt (dann egal, ob styled oder platform).