Discussion :

[Pol63]

le temps d'exécution de la plupart des instructions est très cours (en nanosecondes)
quand vous êtes dans le sub main et que vous appelez une sub, cette sub est executée puis le sub main contenu, il n'y a donc bien qu'une exécution à la fois

un évènement n'interrompt rien, quand vous cliquez sur un bouton l'event click est mis sur la pile, et quand votre programme n'exécute plus rien les évènements sont dépilés
c'est pareil pour timer.tick, ca n'interrompt rien
ca serait très dangeureux si un evenement interrompait l'exécution du code
un évènement sert juste à lier du code à quelque chose qui se passe, que ca soit graphique ou non (arrivée de données sur le réseau par exemple)

après avec le sub main ca embrouille, normalement sur une appli windows forms il y a un application.run(unform) quelque part, ce .run fait que la fenetre ne se ferme pas quand rien ne s'exécute

l'event paint est un évènement qui vient de windows pour rafraichir l'interface (dessin), il fonctionne comme les autres

aussi si vous avez un traitement long, l'interface ne se rafraichit pas et ca mène au "ne répond pas"

doevents mets en pause la sub sur la ligne du doevents, traite tous les évènements à traiter puis reprend sur la ligne d'après

s'il y a un long processus il n'y a pas lieu de l'interrompre, mais il faut le déplacer sur un autre thread
le code qu'on met sur le thread principal ne doit donc pas être long (moins de 200ms par exemple), tout ce qui peut etre long devrait être déporté (lecture d'une base de données etc...)

si on démarre un nouveau thread c'est comme on avait 2 lignes de pas à pas qui avancent en même temps
par contre l'interface ne peut pas être manipulée depuis les autres threads
il est possible d'avoir des évènements sur d'autres threads, depuis des choses qui fonctionnent sur d'autres threads


en résumé il ne faut pas partir avec des à priori mais avec des connaissances, vous n'avez pas pu lire qu'un évènement interrompait l'exécution pour être traité, donc vous l'avez imaginé
il ne faut rien imaginer, microsoft a fait une documentation claire (une fois qu'on a compris comment elle est organisée ^^) qui explique le fonctionnement de tout ...

[DonQuiche]

Reprenons la problématique du DoEvents.
Un évèment tel que un Timer_Tick doit interrompre l’exécution du code en cours.

Non. Une application Windows maintient une file d'attente des messages. Ces messages peuvent être un clic sur la fenêtre, un événement de timer, etcétéra. A la racine de l'application on trouve donc une boucle while (dans Application.Run) qui attend les nouveaux messages et les traite les uns après les autres en levant les événements Timer.Tick ou Button.Click appropriés. Tout le code UI est exécuté depuis cette boucle while.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
boucle
{
   S'il y a des messages
   {
      Message message = plus ancien message.
      si message est un click sur un bouton alors 
      {
          Button bouton = bouton cliqué.
          Pour chaque délégué abonné à bouton.Click
          {
              appeler ce délégué.
          }
      }  
      sinon si message est un événement de timer alors
      {
             ....
      }
   }
   Sinon attendre le prochain message.
}

Autrement dit, si le traitement que tu as présenté est fait en réaction à un Button.Click, alors tant que ce traitement ne sera pas terminé les nouveaux messages ne seront pas traités, y compris ceux du timer. Appeler DoEvents sert justement à traiter les messages en attente avant de continuer. DoEvents est lui-même une boucle while, une "pompe à messages" (message pump) comme celle illustrée ci-dessus.

S’il y a un long processus de traitement dans la sub, comment fait-on alors pour l’interrompre ? Qu’en est-il pour une suite de sub imbriquées ? Quand les évènements peuvent-ils s’exécuter ?

Soit on appelle DoEvents à certains moments, soit on exécute le traitement depuis un thread séparé.

Je pensais que le principe d’un évènement est d’interrompre le processus en cours, quel qu’il soit, pour exécuter le code associé à l’évènement. Je m'y perds

Un événement n'est qu'une liste de délégués. Appeler un événement, c'est comme faire un foreach(var action in Button.Click) action(). Les délégués sont appelés séquentiellement les uns après les autres.

[horemheb]

Pol63 vous affirmez

en résumé il ne faut pas partir avec des à priori mais avec des connaissances, vous n'avez pas pu lire qu'un évènement interrompait l'exécution pour être traité, donc vous l'avez imaginé
il ne faut rien imaginer, Microsoft a fait une documentation claire (une fois qu'on a compris comment elle est organisée ^^) qui explique le fonctionnement de tout ...

Pour commenter votre propos je vous transmets quelques extraits de ce que l’on trouve comme commentaires sur les évènements, Microsoft inclus.

« Supposons, par exemple, que votre application exécute une tâche de tri séparément de l'application principale. Si un utilisateur annule le tri, votre application peut envoyer un événement d'annulation demandant au processus de tri de s'interrompre. »
« Un gestionnaire d'événements est une méthode liée à un événement. Lorsque l'événement est déclenché, le code qu'il contient est exécuté. »
Source Mdsn
« Quand le programme fonctionne, quand l'utilisateur du logiciel clique sur le bouton1, le code situé entre Private Sub Button1Click et End Sub est effectué. »
« Ainsi quand l'utilisateur clique sur le bouton, la procédure Maroutine est exécutée. »
« Cette procédure contient le code qui doit être exécuté lorsque l'utilisateur clique sur le bouton. »
Source Cours VB.Net - P Lasserre
« Si l’évènement se produit, Visual Basic exécutera la procédure correspondante »
Source Visual Basic 6.0 Etape par étape - Mickael Halvorson
« Ici, le but est de créer des événements qui vont être propres à votre application. C'est-à-dire déclencher une action dans votre application lorsque quelque chose se produit et informer les objets abonnés à cet événement. »
Source A la découverte des évènements en .Net - F Cantenot, O Delmotte
« l'application se met à l'écoute des évènements qui se produisent sur le formulaire (clics, déplacements de souris, ...) et fait exécuter ceux que le formulaire gère. »
« On peut associer autant de gestionnaires que l'on veut à un évènement. Ils seront tous exécutés lorsque l'évènement auquel ils sont associes sera déclenché. »
Source Apprentissage du langage VB.Net – S Tahé

Nulle part il n’est clairement signalé, comme vous le dites, que

un évènement n'interrompt rien, quand vous cliquez sur un bouton l'event click est mis sur la pile, et quand votre programme n'exécute plus rien les évènements sont dépilés, c'est pareil pour timer.tick, ça n'interrompt rien

De plus de nombreux exemples dans le fonctionnement d’un ordinateur font croire qu’il est possible d’interrompre un processus. On peut quand on le souhaite interrompre un téléchargement, une copie de dossier, mettre en pause une musique, etc.
Vous comprendrez mieux les difficultés que je rencontre pour réaliser correctement mon projet.
Merci à DonQuiche pour avoir complété le propos de Pol63
Bonne journée à tous ceux qui me lisent

[Pol63]

Nulle part il n’est clairement signalé, comme vous le dites

Nulle part il n'est écrit l'inverse, à savoir que le code de l'event est exécuté automatiquement
il ne faut se fier qu'aux phrases et au vocabulaire, chaque mot a une signification claire
processus = .exe qui tourne
un processus peut contenir plusieurs threads
etc...

« Supposons, par exemple, que votre application exécute une tâche de tri séparément de l'application principale. Si un utilisateur annule le tri, votre application peut envoyer un événement d'annulation demandant au processus de tri de s'interrompre. »

"séparément de l'application principale" veut dire un autre exe
déjà on sort du contexte

Cette procédure contient le code qui doit être exécuté lorsque l'utilisateur clique sur le bouton

il n'est pas précisé quand non plus ^^
d'ailleurs le code d'une sub liée à un event est souvent exécutée juste après la levée de l'évènement .net
quand tu fais un while loop et que tu clics sur un bouton, c'est windows qui détecte le clic sur un bouton, .net n'est pas encore au courant
quand le while s'arrête l'application se met à lire les messages de windows, il voit un clic à telle coordonnées et c'est la qu'il transforme ca en évènement (OnClick qui RaiseEvent Click(me, new mouseeventargs(...)))
mais ca c'est parce que l'écoute des messages windows est faite sur le thread principal, là ou ton while s'exécute
si ton while s'exécute sur un autre thread les évènements des autres threads ne sont pas délayés

On peut associer autant de gestionnaires que l'on veut à un évènement. Ils seront tous exécutés lorsque l'évènement auquel ils sont associes sera déclenché

je précise, tous chacun leur tour

De plus de nombreux exemples dans le fonctionnement d’un ordinateur font croire qu’il est possible d’interrompre un processus.

une action, dans certain cas oui, interrompre un processus c'est en faisant "fin de tâche" dans le gestionnaire des tâches
l'interruption de certaines choses se font grace au multithreading
pour interrompre un téléchargement on ferme la connexion tcp/ip depuis un autre thread ...
la lecture d'une musique c'est un thread qui toutes les x millisecondes envoie un bout de musique à windows, là aussi c'est le thread qui est mis en pause

[horemheb]

Merci pour ces précisions, je vais réorganiser mon projet dans ce sens.