Obtenez la fenêtre pour actualiser (etc) sans appeler Application.ProcessMessages?

Question

J'ai une application héritée ici qui a quelques boucles «chronophages» qui se déclenchent à la suite de diverses interactions de l'utilisateur. Le code qui prend du temps met régulièrement à jour quelque chose sur l'écran avec des informations de progression (généralement une étiquette), puis, apparemment pour persuader l'actualisation visuelle de se produire là-bas, le code appelle Application.ProcessMessages (argh!). Nous savons tous maintenant quel genre de problème cela peut introduire dans une application GUI (caritative, c'était un moment plus innocent à l'époque) et nous constatons que, comme les œufs, de temps en temps nous obtenons des utilisateurs l'impossible avec le programme parce qu'ils cliquent sur des contrôles pendant que le programme est 'occupé'.

Quelle est la meilleure façon d'actualiser périodiquement les visuels du formulaire sans prendre en charge d'autres événements/messages, etc.?

Mes pensées étaient soit;
- désactiver tous les contrôles avant de faire quoi que ce soit du temps, et en laissant les appels » ... ProcessMessages de mises en place pour la « force » l'actualisation ou
- trouver un autre moyen de rafraîchir un contrôle périodique

Je peux faire le premier mais il m'a laissé me demander - y at-il une meilleure solution?

exemple de code de l'héritage;

 
i:=0; 
while FJobToBeDone do 
begin 
    DoStepOfLoop; 
    inc(i); 
    if i mod 100 = 0 then 
    begin 
    UpdateLabelsEtc; 
    Application.ProcessMessages; 
    end; 
end; 

Je peux déjà vous entendre tous s'évanouir, à l'arrière. :-)

Answer 1

Si vous appelez Update() sur les contrôles après avoir modifié les propriétés, vous les forcerez à redessiner. Une autre façon est d'appeler Repaint() au lieu de Refresh(), ce qui implique un appel à Update().

Vous devrez peut-être appeler Update() sur le contrôle des parents ou des cadres aussi bien, mais cela pourrait vous permettre d'éliminer les ProcessMessages() completely.

Answer 2

La solution que j'utilise pour les mises à jour longues consiste à effectuer les calculs dans un thread séparé. De cette façon, le fil principal reste très réactif. Une fois le thread terminé, il envoie un message Windows au thread principal, indiquant que le thread principal peut traiter les résultats.

Cela a cependant d'autres inconvénients sérieux. Tout d'abord, alors que l'autre thread est actif, vous devrez désactiver quelques contrôles car ils pourraient redémarrer le thread à nouveau. Un deuxième inconvénient est que votre code doit devenir thread-safe. Cela peut être un vrai défi parfois. Si vous travaillez avec du code existant, il est très probable que votre code ne soit pas compatible avec les threads. Enfin, le code multi-thread est plus difficile à déboguer et devrait être fait par des développeurs expérimentés.

Mais le grand avantage du multi-threading est que votre application reste réactive et que l'utilisateur peut continuer à faire d'autres choses jusqu'à ce que le thread soit terminé. Fondamentalement, vous traduisez une méthode synchrone dans une fonction asynchrone. Et le thread peut déclencher plusieurs messages indiquant certains contrôles pour actualiser leurs propres données, qui seraient mises à jour immédiatement, à la volée. (Et au moment où vous voulez qu'ils soient mis à jour.

J'ai déjà utilisé cette technique plusieurs fois, parce que je pense que c'est beaucoup mieux. (Mais aussi plus complexe.)

Answer 3

La technique que vous cherchez est de filetage. C'est une technique diffucile en programmation. Le code doit être manipulé avec soin, car il est plus difficile à déboguer. Que vous alliez avec threading ou pas, vous devez certainement désactiver les contrôles que les utilisateurs devraient pasmess avec (Je veux dire les contrôles qui peuvent affecter le processus en cours). Vous devriez envisager d'utiliser actions pour activer/désactiver les boutons, etc ...

Answer 4

Plutôt que de désactiver les contrôles, nous avons une var booléen sous la forme FBusy, vérifiez simplement quand l'utilisateur appuie sur un bouton, nous l'a introduit pour les raisons exactes que vous mentionnez, les utilisateurs cliquent sur des boutons en attendant l'exécution d'un code à exécution longue (il est effrayant de savoir à quel point votre code est familier).

Alors vous vous retrouvez avec quelque chose comme

procedure OnClick(Sender:TObejct); 
begin 
    if (FBusy) then 
    begin 
     ShowMessage('Wait for it!!'); 
     Exit; 
    end 
    else FBusy := True; 
    try 
     //long running code 
    finally 
     FBusy := False; 
    end; 
end; 

Son impuissance de se rappeler de rap code long cours d'exécution dans un essai-finally en cas de sorties ou d'une exception, comme vous finiriez avec une forme ça ne marchera pas. Comme suggéré nous utilisons des threads si c'est pour le code qui n'affectera pas les données, par exemple exécuter un rapport ou une analyse de données, mais certaines choses ne sont pas des options, disons si nous mettons à jour 20.000 enregistrements de produits, alors nous Je ne veux pas que quelqu'un essaye de vendre ou de changer de façon sage les dossiers au milieu du vol, donc nous devons bloquer l'application jusqu'à ce que ce soit fait. Ne pas appeler Application.Processmessages, Ceci est lent et peut générer une récursivité illimitée.

Answer 5

Par exemple, pour mettre à jour tout en Panel1 sans film, nous pouvons utiliser cette méthode:

procedure TForm1.ForceRepaint; 
var 
    Cache: TBitmap; 
    DC: HDC; 
begin 
    Cache := TBitmap.Create; 
    Cache.SetSize(Panel1.Width, Panel1.Height); 
    Cache.Canvas.Lock; 
    DC := GetDC(Panel1.Handle); 
    try 
    Panel1.PaintTo(Cache.Canvas.Handle, 0, 0); 
    BitBlt(DC, 0, 0, Panel1.Width, Panel1.Height, Cache.Canvas.Handle, 0, 0, SRCCOPY); 
    finally 
    ReleaseDC(Panel1.Handle, DC); 
    Cache.Canvas.Unlock; 
    Cache.Free; 
    end; 
end; 

Pour de meilleures performances, le bitmap cache doit être créé d'abord et libre lorsque le processus est terminé