Discussion :

[stephyugh]

Voila je connais pas du tout le langage VB en lui-même et je reprends un programme en VB qui fait appel a des fonctions du logicel FineReader (logiciel d'océrisation).
Le problème est que de façon aléatoire le programme ne semble pas réagir de la même façon dans les traitements. Je vois que de temps en temps il est utilisé la fonction "DoEvents" et je me demande si ça ne provient pas de cela selon la charge du processeur.

Qu'en pensez vous? Quand cette instruction doit-elle être utilisé ?

Merci de vos réponses.

[DAUDET78]

DoEvents est une instruction VB qui redonne la main à windows. Cela permet, par exemple, d'éviter un blocage du PC dans une boucle infini en attente d'un évènement :

Code :

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

1
2
3
4
5
6
7
8
 
Do
'  test de quelque chose
     IF Machin%>0 then
     ' ********* action à faire *******
     End If
DoEvents
loop

[stephyugh]

La j'ai l'impression qu'on fait appel a des instructions "exterieures" liées au logiciel d'océrisation, l'utilisation du "DoEvents" est-elle utile ? N'y-a-til pas de risque de perdre 'l'ordre" des instructions? Si j'enleve ces instructions quelles sont les risques?

Merci

[LeForestier]

Bonsoir,
Surtout pas les enlevés, risque de bloquage du PC.
Les paramètres ne sont pas influencés ni perdu par ces DoEvents
A+

[stephyugh]

bon j'arrive pas a comprendre mon probleme alors, de façon aléatoire je n'ai pas toujours le même résultat selon le moment ou passe le programme, vu que toutes les variables sont bien initailisées, je ne voyais plus que le DoEvents! A moins que ça ne provienne des fonctions propre a mon logiciel d'océrisation (Fine Reader)...

[stephyugh]

Quand j'ai du code de ce genre dans mon fichier VB:

"frbatch.instruction liée au logiciel d'océrisation
DoEvents
Instructions VB"

Pouvez-vous me confirmer que les instructions VB qui suivent le DoEvents ne risquent pas de s'exécuter avant la fin de l'instruction frbatch?

Je pense la que je suis bien paumé!!!

Merci

[DAUDET78]

Il faut savoir que Windows n'est pas un OS temps réel (j'aime pas ce terme, mais il est consacré par une génération d'informaticien). Aussi, quand le PC a plusieurs tâches à exécuter, il exécute une seule tâche à la fois (c'est logique), mais c'est le programme qui est en train de s'exécuter qui décide de redonner la main pour que Windows puisse s'occuper des copains qui attendent. Si un programme décide de ne pas relâcher la main, il la garde et toutes les autres taches sont bloquées (le PC plante).

Dans un OS bien fait, on affecte à chaque programme une tranche de temps et chacun fonctionne gentiment l'un après l'autre. Personne ne peut accaparer la totalité des ressource.

Explication un peu simpliste et rapide ....mais pas trop fausse à mon gout.

Dans ton "programme 1", Je sais pas ce que fait ton instruction

Code :

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

frbatch.instruction 'liée au logiciel d'océrisation

Mais imagine qu'elle lance un "programme 2" en VB qui soit très long à s'exécuter. Si il est bien écrit, il va comporter des DoEvents réels ou implicites (après chaque retour de Sub ou de Function). Donc on ne peut pas affirmer que le "programme 2" sera fini avant le retour au "programme 1"

pour vérifier, tu peux mettre une temporisation après ton DoEvents de ce genre

Code :

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

1
2
3
4
5
6
7
8
9
10
 
frbatch.instruction 'liée au logiciel d'océrisation
DoEvents
 
Tempo%=10	'variable globale décrémentée toutes les mS par un timer si >0
Do
	DoEvents
Loop While Tempo% > 0
 
Instructions VB"

[LeForestier]

Bonsoir,
Désolé Daudet, mais il n'y a pas de DoEvents réels ou implicites , il n'y a que les DoEvents déclaré et si tu ne les met pas le PC se bloque quand il est dans une boucle infinie.
Pour bien comprendre le mécanisme il faut avoir une certaine connaissance de la mécanique des 'Piles'.
Le PC possède une pile des adresses à renvoyer et chaques appli possède sa propre pile d'évolution, quand tu met un DoEvents, celà signifie que tu bloque la pile "Exactement à l'endroit où elle est" et tu rend le controle à la pile du PC qui va passer à la commande suivante (et qui rendra la main à la pile de l'appli suivante) et ce n'est que quand elles aurra fait le tour qu'elle rendra la main à la pile de l'appli qui continuerra exactement comme si rien ne s'était passé.
J'espère avoir été suffisament clair, bien que m'ont explication soit assez imagée, et que en réalité 'implicite' pourrait êre acceptée.
Trop cour dans un poste pour tout expliquer.
A+

[DAUDET78]

Bonsoir,
Désolé Daudet, mais il n'y a pas de DoEvents réels ou implicites , il n'y a que les DoEvents déclaré et si tu ne les met pas le PC se bloque quand il est dans une boucle infinie.

A l'intérieure d'une procédure ou d'une fonction, il n'y a que des DoEvents réels. Par contre, il y a des DoEvents "implicites" dans un programme VB entre chaque appel de procédure ou de fonction par le fait que le programme redonne la main à Windows

[Vld44]

+1 pour daudet, enfin disons je pense que vous êtes d'accord en fait.

Par ailleurs pour l'explication de windows est monotâche je ne suis pas sûr d'être d'accord

Windows EST multi-process, puisque chaque process est dans un thread apparenté. Au sein d'un seul process on peut même faire plusieurs thread (mais bon, là c'est un peu de la bidouille on fait comme si)

Donc je comprends pas pourquoi vous dites cela.

Pour le problème initial je pense que tout a été dit, le doevent qui vient après n'a rien avoir dans l'exécution du reste, c'est seulement si ton batch décide de rendre la main (avec des dovents donc) ET n'est pas modal que le reste de ton programme s'exécutera. Le doevents que tu nous montres ne sert, grosso modo, qu'à fluidifier l'exécution générale (pour permettre par ex. le message WM_PAINT d'arriver à tes forms ...)

A+