ShowModal mit Programmablauf und selbst schließen?

[HJay]

Sicher, wenn Application.OnIdle auch anderweitig verwendet wird, muss man auf der Hut sein. Die Gefahr besteht derzeit bei mir nicht, glaube ich. Aber dennoch, danke für die Warnung.

Kann mal jemand einen kurzen Code-Vorschlag machen, wie man das statt Application.OnIdle mit einer eindeutigen Message an die eigene Form machen würde? Ich kenne mich mit Messages nicht so aus.

Wir wird die Reihenfolge der Messages sichergestellt, also dass die eigene Message als letztes erhalten wird?

Vielen Dank im voraus!

[alfold]

Ich kann immer noch nicht verstehen warum man es manchmal kompliziert macht wenn es auch simple gehen kann!
Ich gehe mal davon aus das DeineProgress Anzeige korrekt funktioniert in bezug Deiner Datenanforderung. So wie Du es oben beschrieben hast.

Leg Dir in Deiner TFormProgress ein timer mit rein, frage dort ab ob Progress.Position = 100 ist , wenn ja then Close. Schon ist Dein ganzes Problem Gelöst!
Diese einfach aber sichere Möglichkeit sollte nichts abwägiges haben.

Gruss alfold

[BUG]

Zitat von alfold:

Leg Dir in Deiner TFormProgress ein timer mit rein, frage dort ab ob Progress.Position = 100 ist , wenn ja then Close. Schon ist Dein ganzes Problem Gelöst!

Es gibt keine Delphianwendung in der man nicht noch mindestens einen Timer unterbringen kann
Er weiß doch selbst, wann die Aufgabe erledigt ist (schließlich muss ja irgendwer Progress.Position setzen), die Frage ist, wann er anfangen kann.

[alfold]

War das nicht schon geklärt!? Im OnActivate.
Nun fehlte ihm doch blos, wo er close reinschreiben soll wenn er mit allem fertig ist!
Habs mit einem timer ausprobiert und fertig!

Alles andere sehe ich als overhead an.
Etwa so: Wenn ich fertig bin schick mir ne message das ich mich beenden kann, weil close im onActivate nicht geht!
Und über die anderen Vorschläge wurde ja schon Diskutiert

PS: Allerdings habe ich schon weiter oben erwähnt, das dies ein typisches Beispiel ist, vermischen von VCL und Daten. Die Daten wird er bestimmt nicht in der TFormProgress benötigen sondern in seiner MainForm.

Gruss alfold

[himitsu]

Zitat von HJay:

Die Gefahr besteht derzeit bei mir nicht, glaube ich. Aber dennoch, danke für die Warnung.

Bitte.

Derzeit ... und wenn du daran in 2 Jahren was änderst, dann hast'e dieses hier bestimmt schonwieder vergessen.

PS: Ich würde zwar auch eher zu "einfach" tendieren,
aber das wäre jetzt nicht einfach, sondern billig fehleranfällig.

Delphi-Quellcode:

TForm5 = class(TForm)
  procedure FormShow(Sender: TObject);
  procedure WMMachWas(var Msg: TMessage); message WM_USER+1;
private
  { Private-Deklarationen }
public
  { Public-Deklarationen }
end;

procedure TForm5.FormShow(Sender: TObject);
begin
  ...
  PostMessage(Handle, WM_USER+1, 0, 0);
  ...
end;

PS: So wäre es sogar übersichtlicher, da der Bearbeitungsweg "eindeutig" ist.

[Chemiker]

Hallo HJay,

meiner Meinung nach, ist es auch ungeschickt jedes Mal den Datenbank-Zugriff zu unterbrechen um die Anzeige zu aktualisieren. Ein Mehrwert hat der Benutzer dadurch nicht, im Gegenteil das ganze dauert nur unnötig lange weil man erst feststellen muss wie viel Datensätze verarbeitet werden sollen. Eine einfache Massagebox mit den Hinweis, dass der PC arbeitet würde dann reichen.

Bis bald Chemiker

[hoika]

Hallo,

ich mache das so.

ins FormActivate kommt der Code, etwa so

Delphi-Quellcode:

Application.ProcessMessages
// der Code

Zitat:

Etwa so: Wenn ich fertig bin schick mir ne message das ich mich beenden kann, weil close im onActivate nicht geht!

Close nicht, aber

PostMessage(Handle, WM_CLOSE, 0, 0);
Heiko

[dataspider]

Hi,

Himitsu hat das Beispiel zwar schon im Ansatz geschrieben,
ich komplettiere mal:

Code:

Interface
Uses
   ...
Const
  FM_STARTED = WM_USER + 1; // Formular komplett erzeugt
...
  protected
    procedure FmStarted(var Message: TMessage); message FM_STARTED; // MethodenName frei, Konstante für MessageId wichtig
implementation
...
procedure TfrmModal.FmStarted(var Message: TMessage);
begin
  // Verarbeitung
  ModalResult := mrOK; // oder Close
end;
// und ntürlich der Aufruf von PostMessage wie bei Himitsu

Ich habe hier allerdings Bedenken.
Falls in der Verarbeitung z.B. wegen ScrollBar ain Application.ProcessMessages kommt, funktioniert es wieder nicht.

Aber, Probieren geht über ...

Frank

[alfold]

Und nun? Wenn er beim einlesen der Daten evtl noch ein Try except block drin hat(?) oder es generell zur Unterbrechung kommt steht seine TFormProgress da und er kann nur noch eins machen strg+alt+del um sein Prog abzuschiessen. Oder mann macht nun noch zusätzliches rein um auch noch dieses abzufangen damit er wieder an seine MainForm kommt!
Das mag bei Ihm ja alles gehen. Wenn es dann aber auf eine anderen Maschine kommt ......

Es ist und bleibt ne unsaubere Lösung!

Ich schreibe dies nicht weil ich mich wichtig tun will, sondern aus eigener Erfahrung!

Ich kann nur nicht verstehen warum man von einem falschen Ansatz her nach Lösungen sucht um diesen evtl noch zu verschlimmern

Gruss alfold

[dataspider]

Zitat von alfold:

Es ist und bleibt ne unsaubere Lösung!

Was ist die saubere Lösung? Der Timer?

Ich finde es sehr vermessen, alles, was nicht den eigenen Vorlieben entspricht, als unsauber zu deklarieren.

Auszug aus der Forms:

Code:

Show;
try
  SendMessage(Handle, CM_ACTIVATE, 0, 0);
  ModalResult := 0;
  repeat
    Application.HandleMessage;
    if Application.Terminated then ModalResult := mrCancel else
      if ModalResult <> 0 then CloseModal;
  until ModalResult <> 0;

Wie man sieht, wird nach allen Ereignissen (Show, Activate etc.) ModalResult auf 0 gesetzt.
Schliessen hier nicht möglich.
Das nächste ist HandleMessage - ProcessMessage und Idle.

Was ist nun unsauber daran, genau hier einzusteigen?

Sowohl Timer als auch PostMessage als auch Application.OnIdle kann man verwenden.

Ich persönlich bevorzuge weiterhin OnIdle, bezeichne die anderen Lösungen aber nicht gleich als unsauber.

Ich habe früher dafür auch einen Timer benutzt.
Aber man muss doch die Zeit gut wählen, damit er wirklich fertig ist (auch ProcessMessages braucht Zeit).

Den Fragesteller zu verunsichern, kann ja nicht das Ziel sein.

Frank