Execution d'une fonction trop longue

drikce06 Messages postés 2237 Date d'inscription lundi 29 mai 2006 Statut Membre Dernière intervention 29 mai 2008 - 19 sept. 2006 à 10:25
drikce06 Messages postés 2237 Date d'inscription lundi 29 mai 2006 Statut Membre Dernière intervention 29 mai 2008 - 20 sept. 2006 à 16:29
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

cs_rt15 Messages postés 3874 Date d'inscription mardi 8 mars 2005 Statut Modérateur Dernière intervention 7 novembre 2014 13
19 sept. 2006 à 12:16
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.
0
drikce06 Messages postés 2237 Date d'inscription lundi 29 mai 2006 Statut Membre Dernière intervention 29 mai 2008 11
19 sept. 2006 à 13:06
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
0
cs_casy Messages postés 7741 Date d'inscription mercredi 1 septembre 2004 Statut Membre Dernière intervention 24 septembre 2014 40
19 sept. 2006 à 13:16
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 #
0
drikce06 Messages postés 2237 Date d'inscription lundi 29 mai 2006 Statut Membre Dernière intervention 29 mai 2008 11
19 sept. 2006 à 13:21
Oui dans la deuxieme instruction que sa plante!!!!!

 Drikce 06
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
cs_rt15 Messages postés 3874 Date d'inscription mardi 8 mars 2005 Statut Modérateur Dernière intervention 7 novembre 2014 13
19 sept. 2006 à 13:31
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.
0
cs_casy Messages postés 7741 Date d'inscription mercredi 1 septembre 2004 Statut Membre Dernière intervention 24 septembre 2014 40
19 sept. 2006 à 13:48
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 #
0
cs_rt15 Messages postés 3874 Date d'inscription mardi 8 mars 2005 Statut Modérateur Dernière intervention 7 novembre 2014 13
19 sept. 2006 à 15:39
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.
0
drikce06 Messages postés 2237 Date d'inscription lundi 29 mai 2006 Statut Membre Dernière intervention 29 mai 2008 11
19 sept. 2006 à 15:42
Et ça marche comment les thread? Je sais même pas ce que c'est?

 Drikce 06
0
cs_rt15 Messages postés 3874 Date d'inscription mardi 8 mars 2005 Statut Modérateur Dernière intervention 7 novembre 2014 13
19 sept. 2006 à 17:16
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.
0
drikce06 Messages postés 2237 Date d'inscription lundi 29 mai 2006 Statut Membre Dernière intervention 29 mai 2008 11
20 sept. 2006 à 16:29
J'ai regardé les explications et je pense que cela va pouvoir résoudre mon problème. Merci beaucoup!

 Drikce 06
0
Rejoignez-nous