Discussion :

[ZZZzzz2]

Bonjour,

Voici mon problème, je travaille sur une application qui peut-être amené à exécuter de longs traitements de façon aléatoires... le problème c'est que ces traitements s'éxécutent dans la thread principale et du coup plus aucun messages windows n'est traités durant ce temps et du coup Windows considère l'application comme plantée. Windows XP crée alors une fausse fenêtre permettant de minimiser/fermer l'application qui ne réponds plus. Le problème de cette fausse fenêtre c'est qu'elle peut passer devant des boites de dialogues modales qui apparaissent justement après ce long traitement. Du coup l'utilisateur a l'impression que l'application est planté alors qu'il s'agit juste d'un message passé derrière (il faut faire alt-tab pour que celui-ci repasse devant mais ça l'utilisateur l'ignore).

J'ai trouvé un moyen de contourner le problème avec l'appel de l'API DisableProcessWindowsGhosting dispo depuis Windows XP SP1, par contre pour WinXP sans SP1 ou Win2000 je n'ai pas trouvé d'équivalent, ce qui est plutôt très gênant, sous Windows 2000 le problème n'arrive que si on triture la fenêtre qui "ne répond pas" alors que sous XP cela est systématique...

Quelqu'un a une solution à proposer ?

[Laurent Dardenne]

Salut,
une recherche de 'DisableProcessWindowsGhosting' sur Yahoo renvoie vers QC de borland proposant une piste et vers un site ( http://www.reactos.com/en/content/view/full/4385 ) proposant des sources en C qui semble l'implémenter mais c'est une bonne partie de reverse

[ZZZzzz2]

Salut,
une recherche de 'DisableProcessWindowsGhosting' sur Yahoo renvoie vers QC de borland proposant une piste et vers un site ( http://www.reactos.com/en/content/view/full/4385 ) proposant des sources en C qui semble l'implémenter mais c'est une bonne partie de reverse

Merci pour ton aide, désolé je répond tardivement (j'avais oublié le post) et du coup ton lien ne fonctionne plus. A l'heure actuelle je suis toujours embêté ...

[Jipété]

le problème c'est que ces traitements s'éxécutent dans la thread principale et du coup plus aucun messages windows n'est traités durant ce temps et du coup Windows considère l'application comme plantée.

Ça ne manquerait pas bêtement de "Application.ProcessMessages" ?
(ou l'équivalent pour un thread - là ch'sais pas, j'connais quasiment pas ces bestiaux)

Mes 2 cts,
--
jp

[Laurent Dardenne]

Utilise la fonction recherche de la page d'accueil du site

[ZZZzzz2]

Ça ne manquerait pas bêtement de "Application.ProcessMessages" ?
(ou l'équivalent pour un thread - là ch'sais pas, j'connais quasiment pas ces bestiaux)

Mes 2 cts,
--
jp

Personnellement je veux éviter autant que possible d'utiliser "Application.ProcessMessages" (en fait j'ai passé quelques temps à tous les virer du code) car je trouve qu'une application correctement écrit n'en a pas besoin bien que dans certains cas et par flemme il m'arrive d'utiliser le genre de code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Enabled:= false;
try
   DoSomethingLong;
   Application.ProcessMessages;
   DoSomethingLong;
finally
Enable:= true;
end;

De plus il ne m'est pas toujours possible d'insérer un ProcessMessages ne serait-ce que lors de l'attente d'une connexion, et travailler avec les threads compliquerait bien trop le développement...

Laurent Dardenne> j'ai fait une recherche dans le forum et je n'ai rien trouve d'interessant (idem avec google/googlegroup), mais je ne suis pas sur d'avoir effectuer la recherche dont tu parles (quelle page d'accueil ?).

[Jipété]

Du post d'origine :

le problème c'est que ces traitements s'éxécutent dans la thread principale

De la dernière reply :

travailler avec les threads compliquerait bien trop le développement...

Faudrait voir à être cohérent !

Ch'suis pas un spécialiste des arcanes de Windows et de Delphi, ce que je sais, c'est que dans une boucle longue style copie de fichiers avec form pour indiquer l'avancement et bouton "Annuler", si pas "Application.ProcessMessages" dans la boucle, pas moyen de cliquer sur "Annuler".

Mes 2 cts,
--
jp

PS: dans l'exemple que tu donnes, moi, le "Application.ProcessMessages" je l'aurais mis dans "DoSomethingLong"...

[ZZZzzz2]

Du post d'origine :
De la dernière reply :
Faudrait voir à être cohérent !

Ch'suis pas un spécialiste des arcanes de Windows et de Delphi, ce que je sais, c'est que dans une boucle longue style copie de fichiers avec form pour indiquer l'avancement et bouton "Annuler", si pas "Application.ProcessMessages" dans la boucle, pas moyen de cliquer sur "Annuler".

Mes 2 cts,
--
jp

PS: dans l'exemple que tu donnes, moi, le "Application.ProcessMessages" je l'aurais mis dans "DoSomethingLong"...

Ben il n'y a rien d'incohérent dans ce que j'ai dis donc je répète : le traitement s'effectue dans la thread principale car travailler avec les threads (autre que la principale cela va de soi) est trop compliqué.

Moi quand je fait un traitement long je préfère le faire dans une autre thread afin que la thread principale (et donc l'interface) réponde toujours à l'utilisateur. Se contenter de faire un appel à "ProcessMessages" c'est un peu la solution de facilité qui peut entraîner des bugs terribles (genre un timer ou autre événement qui passe en plein milieu de ton traitement alors que cela n'était pas prévu), je parle en connaissance de causes... et mettre un "ProcessMessages" à l'intérieur de "DoSomethingLong" je trouve ça quand même 'achement "trash" (tu perds toutes indépendance lors de l'utilisation de "DoSomethngLong"), enfin moi j'aime pas.

Donc j'en suis toujours au même point moi ^^ ...