Execution d'une fonction trop longue

Messages postés
2237
Date d'inscription
lundi 29 mai 2006
Statut
Membre
Dernière intervention
29 mai 2008
-
Messages postés
2237
Date d'inscription
lundi 29 mai 2006
Statut
Membre
Dernière intervention
29 mai 2008
-
Bonjour, j'ai mis un post hier pour compter le nombre de fichier et de répertoire dans un dossier racine. J'ai encore trouvé plus simple. La solution d'hier permet en tout cas de traiter chaque fichier de l'arborescence.
 Le probleme c'est lorsque VB execute la deuxieme fonction pour comter les fichiers.

Vb me donne l'exception suivante:

The CLR has been unable to transition from COM context 0x1a1330 to COM context 0x1a14a0 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

Je cherche quelque chose dans l'aide, mais je galère un peu! Alors si quelqu'un à la solution! Merci d'avance!

NbRepTraite =




My
.Computer.FileSystem.GetDirectories _(SelectedRep, FileIO.SearchOption.SearchAllSubDirectories).Count

NbFileTraite =


My
.Computer.FileSystem.FindInFiles(SelectedRep,

""
_,


True
, FileIO.SearchOption.SearchAllSubDirectories).Count





 Drikce 06

10 réponses

Messages postés
3874
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
7 novembre 2014
14
Oh pov...

Apparement, c'est un souci côté COM. Faudrat d'ailleurs qu'on m'explique ce que COM vient faire là : y z'ont quand même pas fait ça en COM lol.

D'après le message d'erreur, y a un truc COM qui ne vérifie pas les messages que windows lui envoie (Autrement dit, le thread est  à l'ouest : il boucle sur une annerie ou qqch comme ça). M'enfin c'est un peu beaucoup bizarre...

Tu peux peut être utiliser la méthode GetFiles de FileSystem
a la place de FindInFiles. Ca devrait mieux marcher : FindInFiles regarde l'intérieur du fichier, donc pas top du tout

@+
<hr size="2" width="100%" />Je suis en deuxième année en école d'ingénieur etpassionné de développement logiciel sous D7 et VB6. Je cherche un stage en entreprise sur Paris de début avril à fin juillet 2007.
Messages postés
2237
Date d'inscription
lundi 29 mai 2006
Statut
Membre
Dernière intervention
29 mai 2008
11
Même avec GetFiles sa plante. En fait ça plante au bout de 60 sec, apparement il faudrai que je mette quelque chose car la routine est trop longue, mais je ne trouve pas!

 Drikce 06
Messages postés
7741
Date d'inscription
mercredi 1 septembre 2004
Statut
Membre
Dernière intervention
24 septembre 2014
41
Essaye peut-etre d'insérer un DoEvents entre les 2 instructions. Si c'est dans une des 2 instructions que ça plante ça va etre dur de faire quelque chose, je pense.

>RT15, bien sur que COM a sa place ici. Il ne faut pas croire que le noyau de Windows a été réécrit en .NET, le framework ferait bien plus que 20Mo dans ce cas. Beaucoup des fonctions, methodes .NET sont simplement des décorations plus ou moins complexe d'api du système. Hors pour accèder aux api depuis le framework, il faut passer par une interface COM. Elle est explicite quand tu fais volontairement appel à une api, elle est implicite lorsque c'est une methode .NET qui y fait appel.

Pour se passer completement de COM, il faudrait que le noyau système soit écrit sur la plateforme .NET, mais à ce moment là aucune application non .NET ne marcherait. A moins de ....... mettre en place une interface COM (mais dans l'autre sens) pour ces applis.

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #
Messages postés
2237
Date d'inscription
lundi 29 mai 2006
Statut
Membre
Dernière intervention
29 mai 2008
11
Oui dans la deuxieme instruction que sa plante!!!!!

 Drikce 06
Messages postés
3874
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
7 novembre 2014
14
casy>La majeur partie du noyau n'est pas du COM, mais heu... du classique.

FindNext et FindFirst de kernel32 par exemple.

C'est très probablement comme ça au final :

DOTNET
COM
API Win32

Jsute pour aller lentement...

<hr size="2" width="100%" />Je suis en deuxième année en école d'ingénieur etpassionné de développement logiciel sous D7 et VB6. Je cherche un stage en entreprise sur Paris de début avril à fin juillet 2007.
Messages postés
7741
Date d'inscription
mercredi 1 septembre 2004
Statut
Membre
Dernière intervention
24 septembre 2014
41
RT15, on est d'accord. Le noyau c'est du "classique". Et le passage de .NET (framework) vers le classique (noyau) se fait via une interface COM.

"Juste pour aller lentement" : Et certainement aussi parce qu'il ne devait pas y avoir beaucoup d'autres choix, à partir de moment ou cela devait tourner sur la plateforme Win32 déjà existante.
On a juste rajouter une belle carrosserie sur la carosserie déjà existante, plutot que de changer la voiture 

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #
Messages postés
3874
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
7 novembre 2014
14
Donc le pb est pas fondamentalement un bug... C'est juste que la CLR n'attend pas assez l'objet COM qui a beaucoup de travail, et qui ne peut donc pas réagir avant un certains temps (< 1 minute).

Je vois pas trops de solutions théorique...
1 Soit tu t'arrange pour dire à la CLR : Attend plus longtemps. C'est pas évident que ce soit possible...
2 Soit tu découpe manuellement ta demande, en parcourant les répertoires par exemple. Mais ça rajouterait du code.
3 Tu doit peut être pouvoir éviter ça en démarrant un thread juste pour lister tes fichiers. Ce thread permettrait à l'utilisateur de garder le contrôle de l'appli ( via le thread principal ), et par exemple de la fermer.Ce serait à mon avis la solution la plus propre.

<hr size="2" width="100%" />Je suis en deuxième année en école d'ingénieur etpassionné de développement logiciel sous D7 et VB6. Je cherche un stage en entreprise sur Paris de début avril à fin juillet 2007.
Messages postés
2237
Date d'inscription
lundi 29 mai 2006
Statut
Membre
Dernière intervention
29 mai 2008
11
Et ça marche comment les thread? Je sais même pas ce que c'est?

 Drikce 06
Messages postés
3874
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
7 novembre 2014
14
Comment dire... Dans une appli avec un seul trhead, le processeur suit un certains "chemin" d'instructions. Dans ton exemple ci-dessus, il vat executer la ligne 1 puis la ligne 2.
Mais il n'executera pas la partie traitement des messages de windows pendant qu'il execute ces deux lignes.

Si tu crée un second trhead dans ton appli pour executer la deuxième ligne, ton processeur vat alors suivre deux "chemins" en même temps. Un executera la ligne. L'autre sortira de la procedure et traitera les messages.
Des explications.
Un exemple.

<hr size="2" width="100%" />Je suis en deuxième année en école d'ingénieur etpassionné de développement logiciel sous D7 et VB6. Je cherche un stage en entreprise sur Paris de début avril à fin juillet 2007.
Messages postés
2237
Date d'inscription
lundi 29 mai 2006
Statut
Membre
Dernière intervention
29 mai 2008
11
J'ai regardé les explications et je pense que cela va pouvoir résoudre mon problème. Merci beaucoup!

 Drikce 06