[R] Problème GUIGetMsg() dans _ArrayDisplay() qui ne s'affiche pas.

[Patrick22]

$iAnnuler_Id = 0 marche, c'est logique. L'ennui c'est que la logique qui amène à choisir cette ligne de code est liée à la connaissance du problème dans _ArrayDisplay().
Dé-enregistrer la fonction de gestion des messages me semble plus cohérente avec une "bonne pratique" du codage. Pourquoi laisser dans l'environnement une fonction de gestion de message active alors que l'écran qui l'utilisait n'existe plus. C'est la porte ouverte à toutes les fenêtres .

Dans le même esprit d'ailleurs, je souscris aussi au test de l'identifiant de la GUI dans la fonction.

Code : Tout sélectionner

Func WM_COMMAND($hWnd, $iMsg, $wParam, $lParam)
  Local $nID = BitAND($wParam, 0x0000FFFF)
   If $hWnd = $hGUI and $nID = $iAnnuler_Id Then   ;<<<<<<<<<<<<<
        $bAnnulation = True
        Return 0
   EndIf
   Return 'GUI_RUNDEFMSG'
EndFunc ; ==> BarreAttente_WM_COMMAND

On suppose toujours que le ControlId est celui de la GUI, parce qu'on a pris l'habitude que ce soit vrai. Mais lorsqu'un script est destiné à être utiliser par des d'autres scripts dont on ne connaît rien, ce n'est plus aussi évident, même, de nouveau, si c'est très souvent le cas.
C'est un peu comme tester la validité des paramètres d'une fonction avant de les utiliser. On peut ne pas le faire et tant pis pour l'utilisateur qui se trompe; à charge pour lui de comprendre pourquoi la fonction appelée se comporte bizarrement, voire se plante mystérieusement. Il est alors obligé de regarder le code de la fonction appelée pour comprendre son erreur de paramètre.

C'est exactement ce qui se passe avec _ArrayDisplay(). Ce n'est pas un bug. Juste une "bonne pratique" oubliée. Quand cette fonction récupère l'Id de l'événement activé, elle suppose qu'il provient de sa GUI.
D'ailleurs le problème est apparu pour le bouton "Exit", fonctionnalité sans impact sur l'environnement des données. Mais s'il se produit sur l'Id d'une fonction utilisateur ajoutée à _ArrayDisplay() ? Ça pourrait alors être beaucoup plus lourd de conséquences.

Il me semble que le problème est résolu :
1 - Return 0 dans le test de l'événement généré par le bouton "Annuler" dans la fonction enregistrée.
2 - Dé-enregistrer cette fonction quand elle n'est plus utile.
3 - Bonus "Bonne pratique" : Dans la fonction enregistrée, tester l'Id de la GUI associée à l'événement généré par le bouton "Annuler". Il doit bien être celui de la GUI attendue.