# Environnements de dveloppement > Delphi > Codes sources  tlcharger >  ActivityIndicator dans un thread secondaire

## Andnotor

Bonjour  tous !

En gnral, il est prfrable de dporter les tches longues dans des _threads_ secondaires. Ce n'est cependant pas toujours possible.

Il arrive galement que certaines oprations d'affichage requirent un travail consquent ou tout simplement que vous installiez votre application sur une machine relativement lente en comparaison de celle de dveloppement et que ce qui prenait une fraction de seconde en prenne plusieurs par la suite (c'tait mon cas avec des tablettes d'entre de gamme).

Comment informer l'utilisateur "impatient" qu'une tche est en cours ?

Pas de problme si elle est ralise dans un _thread_ secondaire. Un _TActivityIndicator_ (introduit dans _Delphi 10 Seattle_) fera parfaitement l'affaire.
Mais si elle est excute dans la tches principale, l'application semble fige, y compris videmment le _TActivityIndicator_.

C'est ici qu'entre en jeu la petite unit que je vous propose aujourd'hui : un comportement comparable au _TActivityIndicator_ mais excut dans son propre _thread_, un _TActivityIndicatorThread_.

La fentre est cre et gre par API (la VCL n'tant pas _thread-safe_) et initialise en mode _layered_, un mode permettant la gestion du canal alpha ; de la transparence.
les animations sont rcupres directement des ressources associes au _TActivityIndicator_, vous ne serez pas dpays !

A noter:
Il est possible de passer le _handle_ d'une fentre/d'un contrle au constructeur. Dans ce cas, l'animation sera centre sur ce contrle et aura le mme _ZOrder_ (ordre d'empilement des fiches).
Mais si la tche dure plus que 5 secondes, l'OS considre que l'application est fige, fait une copie de la fiche et l'affiche par dessus dans un rendu plus clair avec le message "ne rpond pas". L'indicateur sera donc aussi masqu.
Si aucune fentre "parent" n'est renseigne, l'indicateur flottera au dessus de toutes les fiches du bureau et sera toujours visible.

En rsum, ne dfinissez pas de parent si la tche dure plus de 5 secondes  :;): 

Vous trouverez dans le zip l'unit *WinXIndicator.pas* ainsi qu'une petite application de dmo.

Voil, si vous avez des commentaires ou des remarques, n'hsitez pas  ::mrgreen::

----------


## Paul TOTH

je n'ai pas bien compris l'ide, vue que l'application reste fige en fait...ce n'est que l'animation qui est dans le thread...il serait plus logique de mettre le code dans un thread secondaire.

a me fait penser  mes deux contributions

1) l'animation dans le Thread principal

2) le code qui permet de placer le code dans un Thread secondaire

----------


## Andnotor

L'ide est assez simple : avoir un retour visuel que quelque chose se passe dans le _thread_ principal. Une requte SELECT (pour affichage), le chargement d'une page dans un _WebBrowser_, etc. Des choses qui ne peuvent pas se faire dans un _thread_ de travail. En gros, tous les composants poss sur une fiche peuvent tre concerns.

Mais bien sr, si on a la possibilit de dporter une tche dans un _thread_ secondaire, il faut le faire sans hsiter  :;): 

Si l'application est manipule  la souris, on pourrait faire ce retour en changeant le curseur mais sur une tablette pilote au doigt le curseur est masqu.

Sinon effectivement l'application est fige mais c'est galement le cas de ton exemple.

Pour pallier  cet effet "Not responding" :
Soit la procdure bloquante inclut une boucle (ou le composant un vnement _OnWorking_ ou similaire) et il sera possible d'appeler PeekMessage(PM_NOREMOVE) au moins toutes les 5 secondes, soit on interdit purement et simplement cet effet "fantme" par DisableProcessWindowsGhosting.

----------


## Paul TOTH

> L'ide est assez simple : avoir un retour visuel que quelque chose se passe dans le _thread_ principal. Une requte SELECT (pour affichage), le chargement d'une page dans un _WebBrowser_, etc. Des choses qui ne peuvent pas se faire dans un _thread_ de travail. En gros, tous les composants poss sur une fiche peuvent tre concerns.
> 
> Mais bien sr, si on a la possibilit de dporter une tche dans un _thread_ secondaire, il faut le faire sans hsiter 
> 
> Si l'application est manipule  la souris, on pourrait faire ce retour en changeant le curseur mais sur une tablette pilote au doigt le curseur est masqu.
> 
> Sinon effectivement l'application est fige mais c'est galement le cas de ton exemple.
> 
> Pour pallier  cet effet "Not responding" :
> Soit la procdure bloquante inclut une boucle (ou le composant un vnement _OnWorking_ ou similaire) et il sera possible d'appeler PeekMessage(PM_NOREMOVE) au moins toutes les 5 secondes, soit on interdit purement et simplement cet effet "fantme" par DisableProcessWindowsGhosting.


ben, non dans mon exemple, l'application n'est pas fige, elle affiche une boite en ShowModal pour patienter...si le thread peut tourner en tche de fond, videmment a ne sert  rien  ::):   mais mon exemple rpond  tous les messages. Je sais plus si je l'ai mis dans cet exemple, mais tu peux grer un bouton Annuler qui forcera l'arrte du Thread...donc l'UI rpond bien aux sollicitations...tandis que dans ton cas, tu permets simplement  l'animation de s'actualiser en la faisant tourner dans un thread secondaire, mais l'UI est fige.

----------


## Andnotor

Si tu veux ! _Application.Run_ est bloqu mais la fentre modale continue de pomper les messages.

Rassure-moi cependant, tu n'accdes pas aux composants de la fiche depuis cette mthode appele depuis un _thread_ secondaire n'est-ce pas ?

----------

