Position der FMX-Formulare zur Laufzeit verändern (Delphi XE 10.1)

[Delphi-Laie]

Hallo Delphifreunde!

Weiß jemand, ob es möglich ist, die Position der FMX-Formulare zur Laufzeit zu ändern?

Die im Objektinspektor eingegebene Position wird korrekt erkannt und umgesetzt, sodaß das Formular an bzw. mit dieser Position startet.

Gebe ich jedoch in eine Ereignisbehandlungsroutine, z.B. die eines Buttons,

Delphi-Quellcode:

{TForm1.}Position:=TFormPosition.ScreenCenter

ein und klicke ich diesen Button zur Laufzeit an, passiert rein gar nichts mit dem (derezeit nichtzentrierten) Formular.

Hat das auch schon jemand bemerkt, gibt es evtl. Abhilfe?

Danke und Gruß

Delphi-Laie

[himitsu]

Top und Left?


Position wird "nur" beim Anzeigen (Show, bzw. kurz nach dem Create) ausgewertet und dementsprechend werden Top und Left gesetzt.

[Delphi-Laie]

Zitat:

Zitat von himitsu (Beitrag 1352451)

Position wird "nur" beim Anzeigen (Show, bzw. kurz nach dem Create) ausgewertet und dementsprechend werden Top und Left gesetzt.

Die Position soll nicht ausgewertet, sondern nach Änderung sofort gesetzt werden, d.h., wenn die Positionsvariable des betreffenden Formulares einen neuen Wert zugewiesen bekommet, soll die Position des Formulares auf dem Bildschirm entsprechend gesetzt, angepaßt, verschoben werden! Dieses Verhalten kenne ich jedenfalls seit Delphis Urzeiten von den VCL-Formularen so. Welchen Sinn hat denn sonst das Verändern der Positionsvariablen zur Laufzeit?!

Um mal mein Anliegen etwas zu verdeutlichen, erstellte ich ein Beispielprojekt inkl. Compilat (Anhang). Ich bemühte mich, es so klein wie möglich zu machen (32 Bit, release, 7zip-Komprimierung, die auch von Winrar gelesen werden kann).

Man kann auf jeden beliebigen Button klicken, es tut sich überhaupt nichts mit einer anderen Positionierung des FMX-Formulares. Soll das so sein?

Mit kleinen Änderungen compiliert das Projekt auch mit XE2 und funktioniert dort genausowenig.

Wenn ich Dich recht verstehe, müßte demnach der ButtonClick ein OnShow-Ereignis auslösen, damit das Formular die Positionierung sofort übernimmt, nicht wahr?

[himitsu]

Ja, soll so sein.
Hab ich doch gesagt.
Position wird nur beim "Anzeigen" ausgewertet.

Es gibt "nur" die Position an, wo die Form erstellt wird.
"Default" entspricht dabei dem Verhalten von CreateWindow mit CW_USEDEFAULT, nur dass Borland damals halt noch bissl mehr Positionierungen implementiert hat.

Zitat:

Delphi-Quellcode:

procedure TCommonCustomForm.SetPosition(const Value: TFormPosition);
begin
  if FPosition <> Value then
  begin
    FPosition := Value;
  end;
end;

Und, wird hier irgendwas passieren, wenn man da was zuweist? :stupid:


Fazit: Wenn man Position was zuweisen will, dann am Besten im Create/OnCreate oder halt im FormDesigner.


PS: Wer hat was von Auslesen gesagt?
Du sollst Top und Left was zuweisen.

Und was man da zuweisen kann, erfährt man mit etwas Mathematik und den Werten aus der Variable Screen.

[Harry Stahl]

So ist es. FMX merkt sich in der Formstate-Variable, ob die Form schon mal angezeigt wurde und wenn ja, haben alle nachfolgenden Änderungen für TFormPosition keine Auswirkungen.

Sollte ja aber kein Problem sein, das kurzerhand selbst zu berechnen:

Delphi-Quellcode:

  self.Bounds := Screen.GetDesktopCenterRect(TSize.Create (width, height)); // Für Screencenter

Allerdings ein Hinweis: Das funktioniert unter Delphi 10.1 auf High-DPI-Geräten nicht, wenn unter Projekt, Anwendung, Hochauflösung aktiviert ist (dann funktionieren auch sämtliche ScreenCenter, DesktopCenter usw. zum Start nicht), was man ja wohl als Bug bezeichnen müsste.

Wenn Du also Hochauflösung nutzt, musst Du anschließend noch eine Korrektur für Left und Top, anhand des Skalierungsaktors der Form berechnen.

[Delphi-Laie]

Ich danke Euch beiden!

Wenn das so sein soll, verwundert mich das, denn z.B. kann man den Borderstyle des FMX-Formulares auch zur Laufzeit zuweisen / ändern, und das wird dann auch übernommen und angezeigt.

Nachdem ich schon wieder einmal aufgeben wollte, kamen mir himitsus "Top" und "Left" noch einmal in den Sinn. Diese werden tatsächlich zur Echtzeit verändert, wie ein kleines Experiment egab. Also das Formularzentrieren über diese beiden Befehle

Delphi-Quellcode:

left:=(screen.Width-width) div 2;
top:=(screen.Height-height) div 2

versucht und - voilà, so wollte ich es haben.

Ich finde es zwar ein wenig jämmerlich, daß man einer neuen, modernen Bibliothek mit solchen Bastellösungen auf die Sprünge helfen muß, um Essentialien herauszulocken, aber viellicht ist dieses Defizit zwingend in der inneren Struktur des VGScene / Firemonkeys begründet und nicht änderbar, dann gilt diese Kritik nicht.

Nochmals besten Dank!

[Daniel]

Auch das dürfte der Perspektive von FireMonkey auf die mobilen Plattformen geschuldet sein. Dort gibt es schlicht keinen Bedarf, ein Formular zu verschieben.

... wobei ich jetzt das Setzen von .Left und .Top mehr als übliche Lösung denn als "Bastel-Lösung" betrachte.

[himitsu]

Den BorderStyle kann man im Windows auch zur Laufzeit ändern. (nue die VCL baut dabei alles intern neu auf :stupid:)
Die Default-Werte für die Erstelungspositon lassen sich dennoch nur zur Erstellungszeit verwenden. :stupid:

[Delphi-Laie]

Zitat:

Zitat von Daniel (Beitrag 1352502)

Auch das dürfte der Perspektive von FireMonkey auf die mobilen Plattformen geschuldet sein. Dort gibt es schlicht keinen Bedarf, ein Formular zu verschieben.

Weil das Gros der Compilate in die "Apps" mündet, die im Vollbildmodus laufen, nicht wahr?

Zitat:

Zitat von Daniel (Beitrag 1352502)

... wobei ich jetzt das Setzen von .Left und .Top mehr als übliche Lösung denn als "Bastel-Lösung" betrachte.

Das Setzen nicht, ich meinte das (triviale) Berechnen der beiden Koordinaten.

[Uwe Raabe]

Grundsätzlich würde das Reagieren auf Änderungen von

Delphi-Quellcode:

Position

auch zur Laufzeit funktionieren (zumindest unter Windows). Mit folgendem, zugegeben ziemlich dirty Hack lässt sich die Funktionalität auch transparent nachbilden. In einem echten Projekt würde ich von dieser Lösung allerdings Abstand nehmen.

Delphi-Quellcode:

type
  TFormHelper = class helper for TForm
  private type
    TFormStateHack = class(TFmxObject)
    private
      FDesigner: Pointer;
      FCaption: Pointer;
      FLeft: Integer;
      FTop: Integer;
      FTransparency: Boolean;
      FHandle: Pointer;
      FContextHandle: THandle;
      FBorderStyle: TFmxFormBorderStyle;
      FBorderIcons: TBorderIcons;
      FVisible: Boolean;
      FExplicitVisible: Boolean;
      FModalResult: TModalResult;
      FFormState: TFmxFormStates;
    public
      procedure ResetFormState;
    end;
  public
    function GetPosition: TFormPosition;
    procedure SetPosition(const Value: TFormPosition);
    property Position: TFormPosition read GetPosition write SetPosition;
  end;

procedure TFormHelper.TFormStateHack.ResetFormState;
begin
  Include(FFormState, TFMXFormState.WasNotShown);
end;

function TFormHelper.GetPosition: TFormPosition;
begin
  Result := inherited Position;
end;

procedure TFormHelper.SetPosition(const Value: TFormPosition);
begin
  Hide;
  inherited Position := TFormPosition.ScreenCenter;
  TFormStateHack(Self).ResetFormState;
  Show;
end;

[Delphi-Laie]

Danke, danke!

Zitat:

Zitat von Uwe Raabe (Beitrag 1352506)

Grundsätzlich würde das Reagieren auf Änderungen von

Delphi-Quellcode:

Position

auch zur Laufzeit funktionieren (zumindest unter Windows).

Was heißt "würde"? Tut es doch eben nicht, siehe mein obiges Beispielprojekt.

Zitat:

Zitat von Uwe Raabe (Beitrag 1352506)

Mit folgendem, zugegeben ziemlich dirty Hack lässt sich die Funktionalität auch transparent nachbilden. In einem echten Projekt würde ich von dieser Lösung allerdings Abstand nehmen.

Warum Abstand nehmen? Entweder es funktioniert zuverlässig (d.h. zu 100%) oder nicht. Andere Kategorien spielen für mich jedenfalls keine Rolle. Wenn etwas zuverlässig funktioniert, dann hat es auch die Chance, in ein Projekt aufgenommen zu werden.

[Uwe Raabe]

Zitat:

Zitat von Delphi-Laie (Beitrag 1352529)

Was heißt "würde"? Tut es doch eben nicht, siehe mein obiges Beispielprojekt.

"Würde" funktionieren, wenn es denn implementiert wäre. Es ist aber durchaus möglich, daß dieses Vorgehen unter einem anderen OS als Windows vielleicht nicht realisierbar ist. Der Code zeigt lediglich, daß dieses Verhalten unter Windows implementierbar ist - nicht mehr. Wahrscheinlich ist es aber einfach nur versäumt worden, das VCL-Verhalten zur Runtime in FMX nachzubilden. Wäre vielleicht einen QP-Eintrag wert.

Zitat:

Zitat von Delphi-Laie (Beitrag 1352529)

Warum Abstand nehmen? Entweder es funktioniert zuverlässig (d.h. zu 100%) oder nicht. Andere Kategorien spielen für mich jedenfalls keine Rolle. Wenn etwas zuverlässig funktioniert, dann hat es auch die Chance, in ein Projekt aufgenommen zu werden.

Der Hack ist stark von der aktuellen Implementierung (insbesondere der Typen und Reihenfolge der privaten Felder) von

Delphi-Quellcode:

TCommonCustomForm

abhängig. Sollte sich daran in einem Delphi-Update oder einer neuen Version etwas ändern, funktioniert der Code eventuell nicht mehr. Das ist ein absoluter Maintenance Nightmare.

[Delphi-Laie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1352532)

Zitat:

Zitat von Delphi-Laie (Beitrag 1352529)

Was heißt "würde"? Tut es doch eben nicht, siehe mein obiges Beispielprojekt.

"Würde" funktionieren, wenn es denn implementiert wäre. Es ist aber durchaus möglich, daß dieses Vorgehen unter einem anderen OS als Windows vielleicht nicht realisierbar ist. Der Code zeigt lediglich, daß dieses Verhalten unter Windows implementierbar ist - nicht mehr.

Gut, (ein)verstanden, danke!

Zitat:

Zitat von Uwe Raabe (Beitrag 1352532)

Wahrscheinlich ist es aber einfach nur versäumt worden, das VCL-Verhalten zur Runtime in FMX nachzubilden. Wäre vielleicht einen QP-Eintrag wert.

Eben! Das habe ich nämlich auch stark im Verdacht. Ich begreife nicht, daß sich daran anscheinend bisher, also seit Jahren, noch niemand stieß.

Wenn dem so ist: Warum wird ein solch unfertiges Produkt ausgeliefert? Das fiel mir doch schon an den Ereignislisten auf.

Man muß doch "nur" Schritt für Schritt alle Funktionalitäten der VCL-Formulare und andere visuelle Komponenten erfassen, schon ist die Erledigungsliste erstmal vollständig, die dann vor dem Unternehmen liegende Heidenarbeit allerdings natürlich immens.

Es ist doch alles andere als abwegig, daß man zur Portierung von VCL nach FMX die gewohnten Funktionalitäten vorzufinden erwartet, ansonsten scheitern doch viele Migrationen (nicht alles läßt sich "nachbasteln", schon gar nicht von Nichtprofis). Auf jeden Fall kosten solche Kinkerlitzchen enorm viel Zeit und manchmal auch Nerven.

Rechnet man XE 10.1 als eigenständige Version (hat ja auch immerhin einen neuen Projektnamen verpaßt bekommen), dann ist, ab XE 2 gezählt, "Berlin" die neunte (!) Version mit FMX.

[Daniel]

Es war nie der Anspruch an FMX, das gesamte Verhalten der VCL nachzubilden. Es ist ein komplett anderes Framework mit komplett anderer Zielsetzung. Es steht der VCL in einigen Bereichen sehr nahe, funktioniert in anderen Bereichen aber einfach anders. Du kannst Formulare ja pixelgenau positionieren. Diese Stellen haben mit "unfertig" nichts zu tun - Deine Kritik geht am Ziel vorbei.