Eine Art Semi-ShowModal?

[Mavarik]

Zitat von mkinzler:

Es gab Zeiten, da gab es keine Türklingeln und man hat periodisch nachschauen müssen, ob jemand vor der Tür steht.
Türklingeln sind also überflüssig.

Ja das kenne ich auch noch...

Ich habe immer gewartet bis ich das Sync-Loch der Diskette gesehen habe und dann meine Daten geschrieben...

[idefix2]

Meines Erachtens ist ein grundlegender Unterschied zwischen der asynchronen Reaktion auf ein beliebiges Ereignis, und dem Warten auf die Beendigung eines Tasks, um dann mit dem normalen Programmablauf fortzufahren.

Und die Übergabe als Prozedur funktioniert überhaupt nicht, oder nur mit gröbsten Verrenkungen bzw. völlig unnötigen Rekursionen, wenn der Aufruf der Form in einer Schleife stattfindet.

Delphi-Quellcode:

repeat 
   Berechne;
   Form1.ShowSemiModal;
   berechneweiter;
   until BefriedigendesErgebnis;

Zitat:

Warum zum Geier wollt Ihr alle CPU-Zeit verschwenden mit Abfragen, Timer, Sleep und Application.Processmessages?

Erfreulicherweise ist die CPU-Zeit, die dadurch "veschwendet" wird, völlig vernachlässigbar. Bei einer modernen CPU wird da alle 200 Millisekunden nicht einmal eine Mikrosekunde verbraten.

[Mavarik]

Zitat von idefix2:

Delphi-Quellcode:

repeat 
   Berechne;
   Form1.ShowSemiModal;
   Form1.WaitForMe;
   berechneweiter;
until BefriedigendesErgebnis;

Ja, so programmiere ich auch... Ne Stopp das war noch zu DOS Zeiten...

Seit Borland Pascal für Windows programmiert man aber Event-Orientiert...

[Sir Rufo]

In so einem Fall sollte man sich auch von einer Schleife verabschieden und das mit etwas ersetzen, was zu dem Use-Case besser passt: Eine State-Machine.

Damit bekommt man dann auch die kompliziertesten Verschachtelungen sauber in den Griff.

http://melander.dk/delphi/statemachine/
https://github.com/malcolmgroves/TStateMachine (nicht so tolle Portierung von https://github.com/nblumhardt/stateless (C#))

[baumina]

Zitat von idefix2:

Meines Erachtens ist ein grundlegender Unterschied zwischen der asynchronen Reaktion auf ein beliebiges Ereignis, und dem Warten auf die Beendigung eines Tasks, um dann mit dem normalen Programmablauf fortzufahren.

Und die Übergabe als Prozedur funktioniert überhaupt nicht, oder nur mit gröbsten Verrenkungen bzw. völlig unnötigen Rekursionen, wenn der Aufruf der Form in einer Schleife stattfindet.

Delphi-Quellcode:

repeat 
   Berechne;
   Form1.ShowSemiModal;
   berechneweiter;
   until BefriedigendesErgebnis;

Du solltest vielleicht nochmal nachlesen was der TE eigentlich wollte. Er möchte in dem Formular, das dieses SemiModalDingens aufrufen wird, z.B. das Menü weiterhin bedienbar haben und eben nicht in einer Schleife landen, in der der Benutzer nur durch Schließen des SemiFensters irgendwie fortfahren kann.

[sh17]

Code:

function ShowModal: TModalResult; overload;
    procedure ShowModal(const ResultProc: TProc<TModalResult>); overload;

ich glaub ich versuch mich mal mit dieser Variante, ich geb dem Formular eine Funktion mit,
die nach dem Schließen aufgerufen werden muss. Da muss ich zwar etwas umbauen, sieht aber
besser aus.

Code:

Show;
WaitForMe;

wäre auch eine Option, nur gefallen mir die ganzen Konstrukte, wie gewartet wird, nicht.

Danke erst mal für die Diskussion

[idefix2]

@Baumina
Inwieweit widerspricht das eine dem anderen? Das Programm braucht zum Abarbeiten eines Tasks noch Eingaben von mir (und das vielleicht in einer Schleife - ich sage nicht, dass der TE das braucht, aber es geht um den allgemeinen Fall), und kann mit DIESEM Task ohne die Eingaben nicht weitermachen.

Mir erscheint es extrem unschön, alles, was nach dieser einen Abfrage passiert, in eine anonyme Routine zu pressen, die man der Abfrage übergibt.

Oder nimm einen anderes Beispiel:

Delphi-Quellcode:

berechne1;
if JetztBrauchIchNochDaten then 
   Form1.ShowSemiModal;
berechne2;
if JetztBraucheIchNochAndereDaten then
   Form2.ShowSemiModal;
berechne3;

Das wird mit so einer anonymen Methode ein völlig undurchsichtiger Wust.
Und es kann schon vorkommen, dass der User zum Beantworten der Frage, die ihm das Programm stellt, gerne in irgend einem anderen Menüpunkt des Programms etwas nachschauen würde - geht bei modalen Fenstern nicht.

@Sir Rufo
Danke für den Link, das ist eine sehr interessante Komponente, die ich bei einigen Gelegenheiten schon gerne gehabt hätte.
In der aktuellen Fragestellung geht es aber nicht um komplizierte Verschachtelungen, sondern um eine ganz einfache Schleife. Kompliziert wird es nur, wenn man sich darauf versteift, unter keinen Umständen mehr so programmieren zu dürfen, "wie zu DOS Zeiten".

[Sir Rufo]

Es geht hier eher um "nicht mehr wollen", denn das führte immer zu Spaghetti-Code.

Hier mal eine schnelle Implementierung, die alle anderen Show-Methoden (Show , ShowModal ) nicht aushebelt.

Delphi-Quellcode:

unit Unit1;

interface

uses
  Winapi.Windows, Winapi.Messages,
  System.SysUtils, System.Variants, System.Classes,
  Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, Vcl.AppEvnts;

type
  TForm1 = class( TForm )
  private
    FApplicationEvents: TApplicationEvents;
    FSavedFormStyle   : TFormStyle;
    FIsSemiModal      : Boolean;
    FResultProc       : TProc<TModalResult>;
    procedure ApplicationEventsIdle( Sender: TObject; var Done: Boolean );
  protected
    procedure DoClose( var Action: TCloseAction ); override;
  public
    procedure ShowSemiModal( const ResultProc: TProc<TModalResult> );
    procedure AfterConstruction; override;
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

uses
  Vcl.Consts;

{ TForm1 }

procedure TForm1.AfterConstruction;
begin
  inherited;
  FApplicationEvents        := TApplicationEvents.Create( Self );
  FApplicationEvents.OnIdle := ApplicationEventsIdle;
end;

procedure TForm1.ApplicationEventsIdle( Sender: TObject; var Done: Boolean );
begin
  if FIsSemiModal and ( ModalResult <> mrNone )
  then
    begin
      Exclude( FFormState, fsModal );
      FormStyle := FSavedFormStyle;
      Close;
    end;
end;

procedure TForm1.DoClose( var Action: TCloseAction );
begin
  inherited;
  if FIsSemiModal
  then
    begin
      FIsSemiModal := False;
      Hide( );
      FResultProc( ModalResult );
    end;
end;

procedure TForm1.ShowSemiModal( const ResultProc: TProc<TModalResult> );
begin
  if not Enabled or Visible or ( fsModal in FormState )
  then
    raise EInvalidOperation.Create( SCannotShowModal );

  if not Assigned( ResultProc )
  then
    raise EArgumentNilException.Create( 'ResultProc' );

  FResultProc     := ResultProc;
  FSavedFormStyle := FormStyle;
  FormStyle       := fsStayOnTop;
  FIsSemiModal    := True;
  Include( FFormState, fsModal );
  Show( );
end;

end.

[Mavarik]

Obwohl

Zitat von sh17:

Danke erst mal für die Diskussion

eigentlich den Thread schon beendet hat.

Da Du ja keine Ruhe gibst...

Zitat von idefix2:

Das wird mit so einer anonymen Methode ein völlig undurchsichtiger Wust.
Und es kann schon vorkommen, dass der User zum Beantworten der Frage, die ihm das Programm stellt, gerne in irgend einem anderen Menüpunkt des Programms etwas nachschauen würde - geht bei modalen Fenstern nicht.

Na eben... Daher ist Modal sowieso schlecht...

Allgemein: anonymen Methode bringen den Code lesbar da hin wo er gebraucht wird... Daher auch viel übersichtlicher als immer hin und her zu springen wo die eigentliche Procedure ist. Aber darum geht es nicht...

Bleiben wir mal bei Deinem Beispiel...

Zitat von idefix2:

Delphi-Quellcode:

repeat 
   Berechne;
   Form1.ShowSemiModal;
   berechneweiter;
until BefriedigendesErgebnis;

Ich fange den User doch nicht in so einer Schleife... Abgesehen von der UI-Task.

Daher die 5 einfachen Regeln für ein reaktives Userinterface:

Rule #1 / Führe nie Code in einem ONXYEvent aus der länger als wenige Millisekunden dauert. (Außer #2)
Rule #2 / Ich will das Userinterface Updaten? Mach es im OnIdle
Rule #3 / Du brauchst Application.Processmessages - Überprüfe Dein Design
Rule #4 / Eine Aktion dauert 2xlänger als die Zeit einen Thread zu erzeugen? Erzeuge einen Thread!
Rule #5 / Die Zeit eine Thread zu erzeugen ist zu lang. - Erzeuge den Thread vorher und starte ihn nur noch in wenigen (ns)

{Auszug aus meinem Vortrag - Firemonkey im realen Crossplattform-Einsatz}

Designe den Programm-Ablauf so wie der User es auch bedienen würde.

Mavarik

PS.: Rule #6 - Schau wie es der SIR macht...

[Sir Rufo]

Zitat von Mavarik:

PS.: Rule #6 - Schau wie es der SIR macht...

Das impliziert aber noch die Rule #7