Discussion :

[=JBO=]

Bonjour,

J'ai une déception sur la fonctionnalité d'interception d'événement Windows de WinDev.

En fait, comme «On ne nous dit pas tout» , j'ai eu l'occasion de clarifier le comportement de l'interception d'événements Windows.
Et donc, je vous rapporte le bilan de mes constatations.
Si vous aussi, vous pensez avoir des informations utiles à une meilleure compréhension, je vous encourage à compléter mon message.

Voilà mon contexte... c'est en WD12:

Le souhait est de "diffuser" un message applicatif vers de multiples fenêtres destinataires en se basant sur le mécanisme des messages Windows.
_ cf. les fonctions SendMessage() et PostMessage()

Concrêtement, dans une application MDI, le mécanisme des messages Windows est utilisé pour envoyer un message applicatif spécifique vers la fenêtre mère MDI.
Ce message applicatif est "MonMessage".

Les fenêtres filles MDI interceptent toutes le message applicatif "MonMessage" envoyé vers la fenêtre mère MDI.

Traitement Déclarations globales FenêtreFilleMDI:

Code :

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

1
2
nEvt est un entier = Evénement(MaProcédureEvénementielleLocale,"FenMèreMDI","MonMessage")
//

Traitement Fermeture FenêtreFilleMDI:

Code :

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

FinEvénement(nEvt)

Que croyez-vous qu'il se passe quand le message applicatif "MonMessage" est envoyé à la fenêtre mère MDI ???

Moi je pensais que les procédures événementielles locales de toutes les fenêtres filles ouvertes seraient exécutées successivement...
Eh bien non !

En fait j'ai constaté que:
_ (1) il y a "empilage/dépilage" des commandes d'interception;
_ (2) seule la commande d'interception la plus récemment empilée est "active" (prise en compte).

Supposons 3 fenêtres filles A, B et C, ouvertes dans cet ordre, qui toutes interceptent le même message sur la même fenêtre Mère.
Quand le message applicatif est envoyé à la fenêtre Mère, seule la fenêtre C intercepte l'événement.
Mais si la fenêtre C est refermée, alors c'est la fenêtre B qui peut "à nouveau" récupérer l'événement.

Aviez-vous compris que ça fonctionne ainsi ???

Et voilà une autre information à propos de la fonction FinEvénement().
Dans la doc, il est dit:

Remarque : L'interception des événements est automatiquement arrêtée lorsque la fenêtre associée est fermée.

En fait, dans un tel contexte d'empilage des commandes d'interception, il n'y a rien d'automatique.
Si on omet d'exécuter FinEvénement() à la fermeture d'une fenêtre, alors l'application plante au prochain message applicatif envoyé à la fenêtre cible.
A bon entendeur, salut !

En espérant que ces éclaircissements seront utiles à d'autres, pour préciser les fonctionnalités, et pour éviter de perdre du temps dans une impasse (comme ce fut mon cas ).
_

[OnePoint]

Salut =JBO= !

Merci de partager.

J'ai une déception sur la fonctionnalité d'interception d'événement Windows de WinDev.

En fait, comme «On ne nous dit pas tout» , j'ai eu l'occasion de clarifier le comportement de l'interception d'événements Windows.
Et donc, je vous rapporte le bilan de mes constatations.

Le souhait est de "diffuser" un message applicatif vers de multiples fenêtres destinataires en se basant sur le mécanisme des messages Windows.
_ cf. les fonctions SendMessage() et PostMessage()

Toutefois, en regardant l'aide en ligne, j'ai bien trouvé l'explication correcte du comportement de la fonction Evénement.
Et cette fonction ne permet pas de "diffuser" un message vers n procédures d'interception de l'événement.

source: http://doc.pcsoft.fr/fr-FR/?3015011&...ement-fonction

Appeler plusieurs fois le même événement sur le même objet

La fonction Evénement peut être utilisée pour gérer plusieurs fois le même événement sur le même élément (champ, fenêtre, ...).

Dans ce cas, les événements sont "empilés" :

• le premier événement est géré jusqu'à l'appel de l'événement suivant.
• lorsque un événement n'est plus géré (fonction FinEvénement), l'événement immédiatement précédent (s'il existe) est pris en compte.

Je l'ai bien lu 10 fois avant de comprendre.

A comparer avec ton explication...

En fait j'ai constaté que:
_ (1) il y a "empilage/dépilage" des commandes d'interception;
_ (2) seule la commande d'interception la plus récemment empilée est "active" (prise en compte).

Supposons 3 fenêtres filles A, B et C, ouvertes dans cet ordre, qui toutes interceptent le même message sur la même fenêtre Mère.
Quand le message applicatif est envoyé à la fenêtre Mère, seule la fenêtre C intercepte l'événement.
Mais si la fenêtre C est refermée, alors c'est la fenêtre B qui peut "à nouveau" récupérer l'événement.

Aviez-vous compris que ça fonctionne ainsi ???

Je te concède que ce n'était pas très clair, pour moi non plus.

Alors que proposes-tu pour "diffuser" des messages, vu que le W-Langage ne permet pas d'implémenter une programmation événementielle ?

[OnePoint]

Bonjour à tous !

Donc Windev fournit un mécanisme d'interception des événements Windows, mais ne propose pas de fonction pour diffuser un message vers plusieurs fenêtres d'une application.

Voici une solution possible pour diffuser un message Windows vers toutes les fenêtres filles d'une application MDI.

Ici on peut utiliser un message Windows utilisateur, codé sur un nombre entier. Dans ce cas, il faut respecter les règles en vigueur avec Windev.
cf. http://doc.pcsoft.fr/fr-FR/?3015011&...9v%C3%A9nement, paragraphe "Evénements utilisés par WinDev"

On peut aussi utiliser un message texte. Mais il faut savoir qu'au final Windev enregistre le message texte dans Windows pour lui associer un nombre entier (via la fonction RegisterWindowMessage de l'API Windows).


Code à exécuter par une Fenêtre qui veut envoyer le message texte "ACTUALISER"

Code WLangage :

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

1
2
3
4
5
6
7
 
// Code à exécuter pour une Fenêtre qui veut envoyer le message texte "ACTUALISER"
// aux autres fenêtres filles MDI.
// Si besoin on peut utiliser les paramètres wParam et lParam, ou les laisser à 0
//
sAliasEmetteur est une chaîne = MaFenêtre..Alias
DiffuserMessageVersFillesMDI(sAliasEmetteur,"ACTUALISER",0,0)

La procédure de diffusion du message, à placer dans une collection de procédures.

Code WLangage :

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
21
22
23
24
25
26
 
// Procédure de diffusion d'un message windows vers les fenêtres MDI filles
//
// Paramètres:
// • sAliasEmetteur [chaîne de caractères] alias de la fenêtre émetteur, utilisée pour la reconnaître afin de ne pas lui envoyer le message
//   utiliser une chaîne vide pour ne pas prendre en compte un émetteur
// • vMessage [entier ou chaîne de caractères] le message Windows
// • wParam [entier] le 1er paramètre
// • lParam [entier] le 2ème paramètre
//
PROCEDURE DiffuserMessageVersFillesMDI(sAliasEmetteur est une chaîne,vMessage,wParam est un entier,lParam est un entier)
 
sAlias est une chaîne
i est un entier
 
BOUCLE
	i++
	sAlias=MDIEnumèreFille(i)
 
	SELON sAlias
	CAS "" : SORTIR
	CAS sAliasEmetteur : CONTINUER
	FIN
 
	PostMessage(Handle(sAlias),vMessage,wParam,lParam)
FIN

Traitements et procédure pour une fenêtre fille MDI qui doit intercepter le message Windows "ACTUALISER".

Code WLangage :

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

1
2
3
4
5
6
7
8
 
// Dans fenêtre fille MDI - Traitement initialisation
//	
 
// Exemple d'interception de l'événement Windows "ACTUALISER"
// par la procédure ActualiserFenêtre
//
nIdEvt est un entier=Evénement(ActualiserFenêtre,MoiMême..Alias,"ACTUALISER")

Code WLangage :

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

1
2
3
4
5
6
 
 
// Dans fenêtre fille MDI - Traitement Fermeture
//	
 
FinEvénement(nIdEvt)

Procédure d'interception de l'événement.
La procédure peut être locale à la fenêtre, ou générique et globale au projet.
Dans le cas de la procédure globale, pour connaître le nom de la fenêtre destinataire de l'événement, on utilise la variable prédéfinie _EVE.Nom.

Code WLangage :

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
 
 
// Dans fenêtre fille MDI - Exemple de procédure d'interception d'un événement windows
//
// Paramètres:
// • nMessage [entier] le message Windows sous forme numérique (le message texte est transformé en entier)
// • wParam [entier] le 1er paramètre
// • lParam [entier] le 2ème paramètre
//
// Note:
// Dans cet exemple, l'interception cible directement l'événement "ACTUALISER".
// Par conséquent il n'est pas nécessaire de contrôler le paramètre nMessage.
//
PROCEDURE ActualiserFenêtre(nMessage, wParam, lParam)
 
// ici on code la prise en charge de l'événement, par exemple pour rafraîchir un champ de la fenêtre

L'utilisation des paramètres wParam et lParam permet de compléter le message Windows.
Je m'en sers, par exemple, pour préciser l'identifiant d'un enregistrement qui a été modifié. Ainsi, la fenêtre destinataire n'est rafraîchie que si elle est vraiment concernée par cet enregistrement modifié.