Android: MessageDlg Logik

[Hwfa]

Dieses modal soll ja eigentlich nur weitere Eingaben in den anderen Formularen verhindern und nur in diesem einzigen zulassen. Darum wird bei den Mobil-Plattformen quasi ein Vorhang (Rectangle, Opacity 50%, HitTest True) davorgelegt und dann kommt der Dialog. Am Ende wird der wieder entfernt.

[eddie11]

Zitat von Hwfa:

Dieses modal soll ja eigentlich nur weitere Eingaben in den anderen Formularen verhindern und nur in diesem einzigen zulassen. Darum wird bei den Mobil-Plattformen quasi ein Vorhang (Rectangle, Opacity 50%, HitTest True) davorgelegt und dann kommt der Dialog. Am Ende wird der wieder entfernt.

Das stimmt, weitere Eingaben werden geblockt - aber die Programmausführung wartet nicht. Wenn nach dem Dialog noch weiterer Code folgt, dann wird dieser ausgeführt ohne auf die Antwort des Dialogs zu warten - jedenfalls ist das bei Android so.

[Sir Rufo]

Dann programmiere deine Anwendung doch einfach besser lesbar

Delphi-Quellcode:

procedure ConfirmAction( const AText : string; const AProc : TProc );
begin
  MsgDialog(AText,TMsgDlgType.mtConfirmation,[TMsgDlgBtn.mbYes,TMsgDlgBtn.mbNo],TMsgDlgBtn.mbYes,
     procedure(const AResult: TModalResult)
     begin
       if (AResult=mrYes) then
         AProc();
     end);
end;

procedure TForm1.Button6Click( Sender : TObject );
begin
  ConfirmAction( 'Willst du Drucken?', PrintFoo );
end;

procedure TForm1.PrintFoo;
begin
  // Hier der Code zum drucken
end;

Wow, schon wird aus einem ominösen und unleserlichem Button6Click eine dokumentierte Methode. Auf einem Blick sieht man nun, dass hier nach Rückfrage ein Druck ausgelöst wird.

Ja, dass mit diesem komischen Dialog-Gedöns ist richtig ekelig: Man muss sich ja richtig Gedanken machen

[eddie11]

Zitat von Sir Rufo:

Dann programmiere deine Anwendung doch einfach besser lesbar

Wow, schon wird aus einem ominösen und unleserlichem Button6Click eine dokumentierte Methode. Auf einem Blick sieht man nun, dass hier nach Rückfrage ein Druck ausgelöst wird.
:

Wow, wer abstrahieren kann ist besser dran!

Üblichweise heißt ein Button bei mir nicht Button16 (manchmal auch Button17 oder ..18 ,), das macht die IDE halt so, wenn man mal schell was ausprobieren will....
Und "willst Du" scheint mir auch nicht unbedingt aussage(frage)kräftig, steht üblicherweise nicht in meinen Dialogboxen. Könnt es vielleicht sein, dass das mal Q&D hingeklickt ist um die Funktionalität auszuprobieren / zu zeigen......?

Aber im Ernst. Wer für Desktop programmiert, der ist gewöhnt, dass "modal" bedeutet, dass die Anwendung erst weiterläuft, wenn das modale Fenster geschlossen wurde,
Darum geht's hier. Nicht um Namenskonventionen oder Programmlesbarkeit.

[Sir Rufo]

Es gibt zwei Aussagen, wo ich reflexartig einen Würgereiz bekomme:

• Das haben wir schon immer so gemacht
• Das haben wir noch nie gemacht

Was möchte man mir damit mitteilen?

Dass man eine Lobotomie hinter sich hat und darum nicht mehr denken kann?

Und etwas an das man sich gewöhnt hat, muss nicht zwangsläufig richtig sein. Wenn man sich den Code anschaut, der dieses blockierende ShowModal verbricht (anders kann man es nicht beschreiben) und dieses mit dem Konzept einer GUI-Anwendung abgleicht, der versteht dann auch, dass dieses neue Verhalten nun endlich dem entspricht, was das GUI-Konzept vorgegeben hat.

Manchmal schmerzt die Erkenntnis, dass man sich jahrelang auf dem Holzweg befunden hat. Mir egal, ich schlage mir einmal beherzt vor die Stirn, schreie einmal laut "Mann, logisch!" und ab dann übernehme ich das.

[Daniel]

Zitat von eddie11:

Wer für Desktop programmiert, der ist gewöhnt, dass "modal" bedeutet, dass die Anwendung erst weiterläuft, wenn das modale Fenster geschlossen wurde

Das ist richtig. Und auf den mobilen Geräten gibt es andere Spielregeln, mit denen man konfrontiert wird. Das ist am Anfang erstmal ein Kulturschock, ohne Zweifel.
Und manchmal muss man dann komplett umdenken - diese Dialoge und der komplett geänderte Ablauf sind ein schönes Beispiel dafür. Die Ausgangsfrage war, die andere diese Thematik behandeln und Ruf hat - wenn auch ein wenig ruppig - einen schönen Weg dafür aufgezeigt, der insbesondere auch ohne Exit auskommt.

[Sir Rufo]

@Daniel

Ist es nicht eher so, dass dieses Konzept schon vom ersten Tag der Programmierung an so hätte laufen müssen? Nein auch ich habe diese "blockierenden" Dialoge eingesetzt, aber war es deswegen "richtig"?

[mkinzler]

Ich würde modale Dialoge nuicht per se als falsch ansehen aber für mobilen Anwendungen sind sie sicherlich weniger geeignet.