[FMX] Wann ist TMessageDlg tatsächlich geschlossen?

[DeddyH]

Ab Delphi XE7 gibt es ja die Möglichkeit, einen non-blocking TMessageDlg mit einer anonymen Methode zu verwenden. Funktioniert ja im Prinzip auch, nur habe ich zumindest unter iOS das Problem, dass bei der Abarbeitung dieser Methode der Dialog immer noch sichtbar (und mir in diesem Fall im Weg) ist. Gibt es eine elegante Möglichkeit, den Rückgabewert auszuwerten und mit der weiteren Verarbeitung zu warten, bis sich der Dialog wirklich verabschiedet hat?

Danke fürs Lesen.

[Mavarik]

Erst mal 42! (Weil kein Source gepostet)

Ob der Dialog nun blocking oder nonblocking ist...
Im Normalfall musst Du die Verarbeitung ja anhalten um auf die Antwort von User zu warten...

Unter Android muss es nonBlocking sein, unter iOS nicht, daher mache ich das so:

Delphi-Quellcode:

function MyMessageDlg(const Msg: string; DlgType: TMsgDlgType; Buttons: TMsgDlgButtons; HelpCtx: Longint): Integer;
{$IFDEF ANDROID}
var
  MsgDlgResult : Integer;
{$ENDIF}
begin
  {$IFDEF ANDROID}
  MsgDlgResult := -1;
  FMX.Dialogs.MessageDlg(Msg, DlgType, Buttons, HelpCtx,
    procedure(const AResult: TModalResult)
      begin
        MsgDlgResult:= AResult;
      end);

  while MsgDlgResult<0 do
    begin
      Application.Processmessages;
      Sleep(10);
    end;

    Result := MsgDlgResult;
  {$ELSE}
  Result := FMX.Dialogs.MessageDlg(Msg, DlgType, Buttons, HelpCtx);
  {$ENDIF}
end;

Mavarik

[DeddyH]

Application.ProcessMessages und Eleganz beißt sich zwar IMO (zumindest unter VCL), aber es geht wohl nicht anders. Mit einem Sack voll IFDEFs habe ich das nun mittlerweile auch in den Griff bekommen, trotzdem Danke.

[Olli73]

Zitat:

Zitat von Mavarik (Beitrag 1307070)

Delphi-Quellcode:

function MyMessageDlg(const Msg: string; DlgType: TMsgDlgType; Buttons: TMsgDlgButtons; HelpCtx: Longint): Integer;
{$IFDEF ANDROID}
var
  MsgDlgResult : Integer;
{$ENDIF}
begin
  {$IFDEF ANDROID}
  MsgDlgResult := -1;
  FMX.Dialogs.MessageDlg(Msg, DlgType, Buttons, HelpCtx,
    procedure(const AResult: TModalResult)
      begin
        MsgDlgResult:= AResult;
      end);

  while MsgDlgResult<0 do
    begin
      Application.Processmessages;
      Sleep(10);
    end;

    Result := MsgDlgResult;
  {$ELSE}
  Result := FMX.Dialogs.MessageDlg(Msg, DlgType, Buttons, HelpCtx);
  {$ENDIF}
end;

"Überlebt" das die App unter Android, wenn du bei angezeigtem Dialog zum Homescreen oder einer anderen App wechselst und danach zurück zu deiner App?

[Mavarik]

Zitat:

Zitat von DeddyH (Beitrag 1307078)

Application.ProcessMessages und Eleganz beißt sich zwar IMO (zumindest unter VCL), aber es geht wohl nicht anders. Mit einem Sack voll IFDEFs habe ich das nun mittlerweile auch in den Griff bekommen, trotzdem Danke.

Der VCL Teil hat ja auch kein Application.ProcessMessages

Zitat:

Zitat von Olli73 (Beitrag 1307080)

"Überlebt" das die App unter Android, wenn du bei angezeigtem Dialog zum Homescreen oder einer anderen App wechselst und danach zurück zu deiner App?

Klar warum auch nicht?

[Olli73]

Zitat:

Zitat von Mavarik (Beitrag 1307099)

Zitat:

Zitat von Olli73 (Beitrag 1307080)

"Überlebt" das die App unter Android, wenn du bei angezeigtem Dialog zum Homescreen oder einer anderen App wechselst und danach zurück zu deiner App?

Klar warum auch nicht?

Weil man AFAIR bei XE5 noch ganz normal ShowMessage blockierend aufrufen konnte und damals genau das oben beschriebene ein Problem (wenn nicht sogar "das" Problem?!) war.

Und: Wenn deine Lösung so einfach und gut funktioniert, warum hat Emba das dann nicht als Standard eingebaut?