Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi Befehlsverarbeitung unter Delphi (https://www.delphipraxis.net/130305-befehlsverarbeitung-unter-delphi.html)

ChrisE 6. Mär 2009 08:39

Re: Befehlsverarbeitung unter Delphi
 
Zitat:

Zitat von taaktaak
Zitat:

Anstelle Application.ProcessMessages würde ich SBar.Update empfehlen
Weil damit gezielt die Anzeige der Statusbar gezeichnet wird und nicht etwaige andere wartenden Operationen ebenfalls?!

:thumb: Genau.
Hat aber auch genau diesen Nachteil. Wenn man nicht daran denkt, was noch so "abgearbeitet" werden muss, wird das eben auch nicht abgearbeitet z.B. Abbrechen-Button der geklickt wird oder so was ;-)

Gruß, Chris

Luckie 6. Mär 2009 08:53

Re: Befehlsverarbeitung unter Delphi
 
Ich denke, das das Problem wo anders liegt. Die Befehle/Funktionen werden natürlich nacheinander abgerabeitet. Das heißt, so lange der Request ausgeführt wird, passiert gar nichts. Da könnt ihr noch so oft Application.ProcessMessages aufrufen, wie ihr wollt. Dann wird der Text der Statusbar zwei mal hintereinander geändert und das geht so schnell, dass man die erste Änderung nicht sieht.

ChrisE 6. Mär 2009 08:59

Re: Befehlsverarbeitung unter Delphi
 
Zitat:

Zitat von Luckie
Ich denke, das das Problem wo anders liegt. Die Befehle/Funktionen werden natürlich nacheinander abgerabeitet. Das heißt, so lange der Request ausgeführt wird, passiert gar nichts. Da könnt ihr noch so oft Application.ProcessMessages aufrufen, wie ihr wollt. Dann wird der Text der Statusbar zwei mal hintereinander geändert und das geht so schnell, dass man die erste Änderung nicht sieht.

Also meinst du, dass der Request so schnell vorbei ist, dass man die Änderung gar nicht sieht, oder habe ich die jetzt falsch verstanden?
Denn ein Application.ProcessMessages direkt vor dem Aufruf des Request würde ja eben zunächst den Statusbar anpassen. Wenn der Request aber zu schnell vorbei ist und die zweite Änderung kommt - gepaart mit dem Application.ProcessMessages - sehe ich es nicht.

Hab ich das jetzt richtig verstanden?

Gruß, Chris

stev-e87 6. Mär 2009 09:02

Re: Befehlsverarbeitung unter Delphi
 
Danke für die vielen Antworten, nun hab ich auch einen gewissen Einblick in DelphiArchitektur ;)

PS.: Applaication.ProcessMessages funktioniert, werd das auch verwenden, falls noch andere Dinge anfallen werden. Die Änderungen der einzelnen Schritte sehe ich auf jeden Fall -> Verbindung aufbauen etc. dauert lange genug.

THX

Luckie 6. Mär 2009 09:11

Re: Befehlsverarbeitung unter Delphi
 
Zitat:

Zitat von ChrisE
Also meinst du, dass der Request so schnell vorbei ist, dass man die Änderung gar nicht sieht,

Nein, nicht der Request ist so schenll, sondern die Änderunge des Statusbartextes erfolgt so schnell. Obwohl, ich sehe gerade, da wird zwischen druch ja noch was ausgeführt. Jedenfalls kommt Windows nicht zum Ändern des Textes, weil die zeichennachrichten eine sehr geringe Priorität im System haben.

Will man so etwas sauber lösen, sollte man mit Threads arbeiten.

hazard999 6. Mär 2009 09:45

Re: Befehlsverarbeitung unter Delphi
 
Und wieder mal wird Application.ProcessMessages vorgeschlagen.

Ihr wisst aber schon das damit die MessageLoop abgearbeitet wird, oder?

Demnach wird auch jeder Timer und jedes User-Event verarbeitet (alles was halt in der MessageLoop ist).


Wozu gibt es Repaint, Refresh oder Invalidate?

Denkt mal drüber nach...

Luckie 6. Mär 2009 09:51

Re: Befehlsverarbeitung unter Delphi
 
Vielleicht will man da sja gerade, damit das Fenster noch reagiert?

hazard999 6. Mär 2009 10:07

Re: Befehlsverarbeitung unter Delphi
 
Gut.

Dann schlage ich folgendes Code-Schnipsel vor:

Delphi-Quellcode:
procedure ProcessSomeMessages;
var sMessage: string;
   mess: TMSG;
   Handled: boolean;
begin
   sMessage := '';

   while PeekMessage(mess, 0, 0, 0, Pm_Remove) do
   begin
      TranslateMessage(mess);
      case mess.message of
         WM_KEYDOWN: sMessage := sMessage + 'killed WM_KEYDOWN ';
         WM_KEYUP: sMessage := sMessage + 'killed WM_KEYUP ';
         WM_MOUSEMOVE: sMessage := sMessage + 'killed WM_MOUSEMOVE ';
         WM_LBUTTONDOWN: sMessage := sMessage + 'killed WM_LBUTTONDOWN ';
         WM_LBUTTONUP: sMessage := sMessage + 'killed WM_LBUTTONUP ';
         WM_RBUTTONDOWN: sMessage := sMessage + 'killed WM_RBUTTONDOWN ';
         WM_RBUTTONUP: sMessage := sMessage + 'killed WM_RBUTTONUP ';
         WM_MBUTTONDBLCLK: sMessage := sMessage + 'killed WM_MBUTTONDBLCLK ';
         WM_RBUTTONDBLCLK: sMessage := sMessage + 'killed WM_RBUTTONDBLCLK ';
         WM_LBUTTONDBLCLK: sMessage := sMessage + 'killed WM_LBUTTONDBLCLK ';
         WM_NCLBUTTONDOWN: sMessage := sMessage + 'killed WM_NCLBUTTONDOWN ';
         WM_TIMER: sMessage := sMessage + 'killed WM_TIMER ';
      else
         Handled := false;

         if Assigned(Application.OnMessage) then
            Application.OnMessage(mess, Handled);

         if not Handled then
            DispatchMessage(mess);
      end;
   end;
end;

weil tb_Load_ElementsClick mehrfach auszuführen weil irgendwer wie wild auf den Button drückt ist denke ich auch nicht das was er will...


Alle Zeitangaben in WEZ +1. Es ist jetzt 10:42 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz