évènement et file d'attente

[DavidFrance44]

Bonjour à toutes et à tous,

Je souhaiterais gérer correctement mes évènement dans la file d'attente.

Voici mon problème : 

           Je ne sais pas comment gérer le fait qu'un utilisateur puisse appuyer plusieurs fois sur un même bouton et déclencher ainsi une succession d'évènement identique, bien qu'il ne souhaitait exécuter qu'une seule fois la tâche lié à l'évènement déclencheur.

          Est ce qu'il y quelqu'un ici qui pourrait m'orienter sur la façon de faire pour éviter ce genre de problème.

[ben64]

Lorsque le bouton est appuyé tu le désactive dans la structure événement et tu le réactive dans ton autre boucle lorsque le code lié à cet événement à terminé son exécution.

Ben64

[Mathieu_R.]

Bonjour,

Pour compléter la réponse de Ben64, et voyant un nœud de propriété Désactivé dans la boucle du bas (sur un autre contrôle), faites attention au séquencement des opérations. Le fil d'erreur vous permettra par exemple de ne réactiver le bouton qu'après avoir réalisé les opérations associées à l'appui sur le bouton btn_delete_date_HRs.

Typiquement, une fois dans le deuxième case, qui contient le nœud Désactivé et la lecture de la variable locale @MW_tr_retour, rien ne permet de prédire ce qui s'exécutera en premier (le nœud Désactivé ou la lecture de la variable et ce qui s'en suite vers la structure case suivante), car il n'y a aucun "lien" entre les deux. Ce peut être souhaitable, si l'on cherche à paralléliser les choses. Ce peut être un piège, si la réactivation du bouton ne doit intervenir qu'une fois le traitement du case effectué.

Cordialement,

[Walker34]

Dans ce genre de situation, je mets l'état actuel de la machine d'état dans une variable locale. L'événement ne charge la file que si la machine d'état est dans un état "en attente". De cette manière c'est propre et robuste. C'est pour cela aussi qu'on préconise les machines d'état : autoriser les actions que dans des états bien déterminés.

Dans ton exemple, cela voudrait dire que l'événement du bouton ne fait rien si tu n'es pas dans l'état "scrutation".

[Mathieu_R.]

@Walker34 : Si un bouton ne doit pas avoir d'effet dans un état donné, autant le désactiver, ce sera plus clair pour l'utilisateur. Un sous VI qui traite l'état des différents contrôles en fonction de l'état fait tout aussi bien l'affaire dans ce cas. Etat Idle, tous mes boutons sont actifs. Etat truc, je grise les boutons qui ne doivent pas être utilisé le temps du process truc, etc.

Cela évite d'empiler un message qui n'aurait pas lieu de l'être. Et l'usage d'un variable locale, très accessoirement 😋

On peut même aller un peu plus loin en dédiant un case de la structure principale à la mise à jour de l'UI (Update Display par exemple). Répondant à un message que l'on peut empiler depuis un autre case, à la demande (pour le pas faire systématiquement la mise à jour de l'état des contrôles).

[Walker34]

@Mathieu : Je suis d'accord, mais il faut reconnaître aussi que, selon la taille de l'application, la désactivation d'un contrôle peut avoir plusieurs causes différentes (gestion des utilisateurs, alarmes, mode de fonctionnement, .. etc).

---

@Mathieu_R.  a écrit :

 Et l'usage d'un variable locale, très accessoirement 

---

 Au détriment de l'usage d'une référence vers un contrôle 😉 c'est encore pire! Les variables locales ce n'est pas le démon non plus.

---

@Mathieu_R.  a écrit :

On peut même aller un peu plus loin en dédiant un case de la structure principale à la mise à jour de l'UI (Update Display par exemple). Répondant à un message que l'on peut empiler depuis un autre case, à la demande (pour le pas faire systématiquement la mise à jour de l'état des contrôles).

---

Personellement je trouve que l'UI doit être actualisée en parallèle de l'application. Idéalement elle devrait même être déconnectable je trouve. Je réfléchis à une liaison TCP entre l'UI et l'app, avec sérialisation de messages, pour pouvoir remplacer l'UI par une app C#-WPF bien plus aboutie graphiquement et une page web.