Discussion :

[Mercusyo]

Bonjour à toutes et à tous,

Dans une de nos applications, nous devons lire des volumes de données d'environ 5Go. Sur les ordinateur équipées de Windows XP, la barre de progression évolue correctement. Par contre, avec les ordinateurs équipés de Windows 7, la même application avec le même volume de données, dans les mêmes conditions, le fameux message "ne répond pas" arrive très vite dans la barre de progression.

J'ai trouvé cela sur le net http://stackoverflow.com/questions/6...ws-7-wm-update

Quelqu'un a déjà eu ce genre de petit souci ?

Merci par avance,

[cedni]

et en compatibilité xp ?

[Mercusyo]

Bonjour,

Je n'ai pas testé en mode compatibilité XP ... mais bon, je ne préfère pas exécuter l'application comme cela, je préfère trouver une solution.
Dois-je créer un thread particulier; qui appelle ma fenêtre avec la barre de progression?

Merci pour vos conseils si vous avez déjà eu ce cas,

[Mercusyo]

Bonjour,

Effectivement, je viens de faire un test, et si j'exécute l'application en mode de compatibilité Windows XP SP3, je n'ai pas ce souci ...

A suivre ... car j'aimerais que cela fasse la même chose sans activer le mode de compatibilité.

[ShaiLeTroll]

La ProgressBar est l'un des rarement composant a s'actualiser même sans traitement des messages
Contrairement au Label ou Memo

Ajoute dans ta boucle, toute les 1000 itérations, un appel à Application->ProcessMessages() si tu ton traitement tourne dans le Main Thread
1000 est un nombre arbitraire, j'utilisais pour ma part, un QueryPerformanceCounter (TChronometer) pour appeler cela toutes les demi-secondes

C'est un délai tout à fait satisfaisait

Si c'est un thread secondaire, tu as peut-être mal goupillé tes signaux entre tes threads provoquant un blocage sur une machine plus puissante sou Seven par rapport à la vieille en XP

[Mercusyo]

Merci ShaiLeTroll pour les infos.

J'ai implémenté l'appel à

Code :

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

Application->ProcessMessages()

via un contrôle TTimer; malheuseusement, cela ne résoud pas le souci.
Je me demande si je ne vais pas devoir implémenter un objet thread ...

A suivre ...

[Argol_Medusa]

Merci ShaiLeTroll pour les infos.
Je me demande si je ne vais pas devoir implémenter un objet thread ...

Perso l'objet thread c'est ce que je fais systématiquement quand j'ai un GUI (Interface Homme Machine) d'avancement à modifier avec un traitement lourd à effectuer en tache de fond ( style installeur logiciel ).
Une petite variable appartenant à ton objet thread que le GUI vient lire sur interruption TTimer pour mettre à jour la barre d'avancement, c'est nickel et ça marche tout OS confondu.

N'oublie pas d'ajouter tout de même un peu de Sleep pour redonner la main à ton appli principale ou de modifier la priorité de ta tache de traitement en fonction de ce que tu veux faire.

En procédant comme ça on a installé sur plus de 80 machines différentes, on a eu aucun problème ( du XP du 7 du 8 et même du vista ).

Par contre pour la ProgressBar j'ai laissé tombé, son comportement est différent suivant les ordinateurs ( barre en vert devient orange ?? ), objet passe en avant plan par rapport à un TImage ou non suivant l'OS etc.

Bref utilise plutot deux TImages, une barre vide une barre complete positionnées l'une sur l'autre et modifie Image2->Width en fonction de l'avancement, tu pourras en plus comme ça donner un super effet graphique

[ShaiLeTroll]

J'ai implémenté l'appel à

Code :

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

Application->ProcessMessages()

via un contrôle TTimer;

Euh c'est logique !
Puisque sans ProcessMessages pas de WM_TIMER

tu n'as pas compris mes propos
Tu dois le mettre dans ta boucle pas ailleurs

[Mercusyo]

Merci Argol_Medusa et ShaiLeTroll pour votre retour d'expérience.

Euh oui ShaiLeTroll, effectivement, je n'avais pas compris ton précédent post, désolé

Je vais tester les 2 solutions proposées,

Encore merci !