Android: MessageDlg Logik

[greenmile]

Da hatten die auch noch ganz andere Probleme. Naja, sei es wie es ist: MessageDlg's sind nicht mehr Modal, damit müssen wir leben. Hoffentlich bleibt diese Eigenschaft nur in FMX und kommt nicht in die Windows oder Mac Welt.

[Sir Rufo]

Die Dialoge sind immer noch modal aber nicht mehr blockierend!

[Jumpy]

Zitat:

Zitat von Sir Rufo (Beitrag 1289808)

Die Dialoge sind immer noch modal aber nicht mehr blockierend!

Aber was ist denn da der Unterschied? Ich dachte das blockieren wäre das modale?

Code:

Modale Dialoge sperren den Rest der Anwendung, solange der Dialog angezeigt wird.
Nichtmodale Dialoge erlauben auch Eingaben außerhalb des Dialogs.

aus Wikipedia

[Sir Rufo]

Zitat:

Zitat von Jumpy (Beitrag 1289810)

Zitat:

Zitat von Sir Rufo (Beitrag 1289808)

Die Dialoge sind immer noch modal aber nicht mehr blockierend!

Aber was ist denn da der Unterschied? Ich dachte das blockieren wäre das modale?

Code:

Modale Dialoge sperren den Rest der Anwendung, solange der Dialog angezeigt wird.
Nichtmodale Dialoge erlauben auch Eingaben außerhalb des Dialogs.

aus Wikipedia

Na dann versuche doch mal mit dem neuen nicht blockierendem Dialog in der Anwendung weiter zu arbeiten. Muss ja nach deinem Verständnis gehen.

Geht aber nicht, denn der Dialog ist modal und sperrt den Rest, aber er blockiert die Codeausführung nicht.

Vorher war der Dialog modal und blockierend, jetzt nur noch modal.

[Jumpy]

Zitat:

Zitat von Sir Rufo (Beitrag 1289812)

... der Dialog ist modal und sperrt den Rest, aber er blockiert die Codeausführung nicht.

Aha, so ist das gemeint. Die Codeausführung kann quasi schon mit was anderem weiter machen.


Nur aus Neugier (für nicht FMXler), wenn in der weiteren Codeausführung erneut ein modaler Dialog aufgerufen wird während der erste noch nicht geschlossen ist, wie ist das geregelt?

[Sir Rufo]

Ohne es explizit ausprobiert zu haben, würde ich bei dieser Konstellation:

Delphi-Quellcode:

procedure foo;
begin
  ConfirmAction( 'Willst du Drucken?', PrintFoo );
  ConfirmAction( 'Willst du Speichern?', SaveFoo );
end;

erwarten, dass der Druck-Dialog erscheint und darüber der Speicher-Dialog.

[Daniel]

Zitat:

Zitat von Sir Rufo (Beitrag 1289828)

Ohne es explizit ausprobiert zu haben, würde ich bei dieser Konstellation:

Delphi-Quellcode:

procedure foo;
begin
  ConfirmAction( 'Willst du Drucken?', PrintFoo );
  ConfirmAction( 'Willst du Speichern?', SaveFoo );
end;

erwarten, dass der Druck-Dialog erscheint und darüber der Speicher-Dialog.

Ich habe - ohne zu fragen - Dein Beispiel genutzt. Es ist genau anders herum. Erst kommt der zweite Dialog (hier das Speichern), danach dann der erste Dialog (hier das Drucken).

[Bernhard Geyer]

Zitat:

Zitat von Daniel (Beitrag 1289876)

Ich habe - ohne zu fragen - Dein Beispiel genutzt. Es ist genau anders herum. Erst kommt der zweite Dialog (hier das Speichern), danach dann der erste Dialog (hier das Drucken).

Es kommt aber aus gleiche raus. Erst muss der Speichern-Dialog bestätigt werden und dann der Druck-Dialog

[Daniel]

Ich denke, ich würde stets versuchen, solche Szenarien zu vermeiden. Denn eventuell möchte ich ja mit den Daten noch etwas furchtbar aufregendes tun, bevor der zweite Dialog kommt. Wenn die Reihenfolge zur Laufzeit dann umgedreht ist, wäre ich unter Umständen ordentlich gef ... ähm .. ge ... ge ... gekniffen.

[Sir Rufo]

Zitat:

Zitat von Daniel (Beitrag 1289876)

Zitat:

Zitat von Sir Rufo (Beitrag 1289828)

Ohne es explizit ausprobiert zu haben, würde ich bei dieser Konstellation:

Delphi-Quellcode:

procedure foo;
begin
  ConfirmAction( 'Willst du Drucken?', PrintFoo );
  ConfirmAction( 'Willst du Speichern?', SaveFoo );
end;

erwarten, dass der Druck-Dialog erscheint und darüber der Speicher-Dialog.

Ich habe - ohne zu fragen - Dein Beispiel genutzt. Es ist genau anders herum. Erst kommt der zweite Dialog (hier das Speichern), danach dann der erste Dialog (hier das Drucken).

Dann habe ich mich unglücklich ausgedrückt: Wenn der Speicher-Dialog über dem Drucken-Dialog liegt, dann muss erst der Speicher-Dialog und dann der Drucken-Dialog bearbeitet werden.

Das Handling ist also ein Stack (Last In First Out) und genau das ist auch zu erwarten gewesen.

Und ich wette dass zuerst der Drucken-Dialog erzeugt und angezeigt wird, dann der Speicher-Dialog erzeugt und angezeigt wird - da aber der Speicher-Dialog die gleiche Größe wie der Drucken-Dialog hat und der exakt an der gleichen Stelle liegt ist der Drucken-Dialog nicht sichtbar, denn der Speicher-Dialog liegt eben darüber. Er ist also da aber nicht sichtbar weil ja eben verdeckt.

Und da zwischen dem Anzeigen der beiden Dialoge eben keine Stunden vergehen, sondern eher Millisekunden ist das Auge einfach zu träge um dieses zu bemerken.