Discussion :

[Jipété]

Bonjour,

(j'espérais des réponses dans le sous-forum "Programmation système" mais les gens ont dû avoir peur du langage Pascal, du coup 0 réponse, d'où ce post, en espérant qu'ici...)

Ayant fait des recherches récemment, je suis tombé sur des bouts de code qui, pour moi, ont un fonctionnement opposé, je dirais, alors si une âme charitable pouvait éclaircir cette histoire, ça m'arrangerait.

Concernant la gestion des messages, j'ai trouvé ici

Code :

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

1
2
3
4
5
6
7
procedure TForm1.WndProc(var Msg: TMessage);
begin
  inherited;
  //
  // gestion de mes messages
  if Msg = WM_... then ...
end;

mais j'ai aussi trouvé là

Code :

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

1
2
3
4
5
6
7
procedure TForm1.WndProc(var Msg: TMessage);
begin
  // gestion de mes messages
  if Msg = WM_... then ...
  //
  inherited; // important to forward messages to default handlers
end;

Quelle est l'approche juste concernant la position de cet inherited ? En début ou fin de proc ?

Question subsidiaire : ces exemples sont basés sur l'utilisation de WndProc, mais on en trouve aussi beaucoup basés sur procedure TForm1.DefaultHandler(var Msg);.
Ce cours présente un joli croquis qui, pour moi, explique mal ou pas assez, toujours est-il que je ne sais pas exactement ce que je dois utiliser.

Dernière question : j'ai besoin de mettre en place une gestion perso de messages basés sur WM_USER+x.
Faut-il que j'aille interférer avec la gestion système et tri dedans comme avec les deux exemples précédents, ou puis-je mettre en place un truc perso genre

Code :

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

1
2
3
4
5
6
7
procedure TForm1.RecupMessagesPerso(var Msg);
begin
  // gestion de mes messages
  if Msg = WM_... then ...
  //
  // inherited; // plus besoin de ça ?
end;

Merci de vos lumières,

[foetus]

Quelle est l'approche juste concernant la position de cet inherited ? En début ou fin de proc ?

Cela dépend de ce que toi tu fais et de ce que WndProc fait

Il me semble que c'est en dernier comme cela toi tu peux configurer 2-3 trucs et la méthode héritée prend en compte tes changements.

Dernière question : j'ai besoin de mettre en place une gestion perso de messages basés sur WM_USER+x.

C'est un truc de viking de redéfinir WndProc

Fais une table de messages: BEGIN_MESSAGE_MAP and END_MESSAGE_MAP (<- désolé c'est du C++ , Andnotor a donné l'équivalent avec DefautHandler)

[anapurna]

salut

pour les message perso tu n'a pas besoin de tri car par défaut il tri lui même le message
pour ce qui est du inherited tout dépend de ta volonté
je m'explique si tu veut faire un traitement avant le traitement normal du message tu
ecrira le inherited a la fin
si tu vaut faire une opération après l'interception et l'utilisation du message tu mettra inherited au debut

imagine que tu veuille modifier ta fiche au moment du wm_paint tu le feras certainement apres le message de la fiche
sinon ton dessin risque d’être recouvert par le inherited

maintenant prenons l'exemple d'un scroll ou tu veut conserver l'ancienne valeur je suppose que tu feras donc ton inherited apres pour continuer l'action du scroll

il n'y as pas de règles figé tout dépend de ce que tu veut faire et a quelle moment tu veut le faire
pareil pour l'interception tout dépend du moment ou et quand tu veut intervenir

[foetus]

Fais une table de messages: BEGIN_MESSAGE_MAP and END_MESSAGE_MAP

Je m'auto-cite Il faut que tes messages commencent à WM_APP

[Andnotor]

Quelle est l'approche juste concernant la position de cet inherited ? En début ou fin de proc ?

Avant ou après en fonction des besoins.
On peut également ne pas l'appeler si on sait pertinemment que les ancêtres ne traiteront pas ce message. On aurait :

Code :

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

1
2
3
4
5
6
7
8
procedure TForm1.WndProc(var Message: Tmessage);
begin
  if Message.Msg = WM_XYZ then
  begin
    ...
  end
  else inherited;
end;

Mais mieux vaut l'appeler une fois de trop que pas assez

Question subsidiaire : ces exemples sont basés sur l'utilisation de WndProc, mais on en trouve aussi beaucoup basés sur procedure TForm1.DefaultHandler(var Msg);.

C'est en gros la même chose à différents niveaux de la chaîne de traitement.
WndProc est la boucle de messages, le point d'entrée de la fenêtre (donc un handle), le récepteur d'un SendMessage. WndProc appelle Dispatch (qui pourrait aussi être surchargé) qui va se charger de répartir le traitement en contrôlant en premier lieu s'il y a un gestionnaire pour ce message.

Un exemple de gestionnaire de message :

Code :

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

procedure WMXYZ(var Message:TMessage);message WM_XYZ;

S'il n'y en a pas, DefautHandler est systématiquement appelé. S'il y en a un, cela dépend des inherited du gestionnaire de la classe courante ou de ces ancêtres.

En l'absence de gestionnaire de message, DefaultHandler est équivalent à WndProc dans le cas d'un contrôle fenêtré.

Perso, je n'ai jamais surchargé DefautHandler.

Dernière question : j'ai besoin de mettre en place une gestion perso de messages basés sur WM_USER+x.
Faut-il que j'aille interférer avec la gestion système et tri dedans comme avec les deux exemples précédents...

Pour une constante (WM_USER+n), tu peux passer par un gestionnaire de message, le numéro du message étant connu à la compilation. Pour un message enregistré par RegisterWindowMessage, passer par WndProc (ou DefaultHandler) est requis puisque le test sera à base de if..then.

...ou puis-je mettre en place un truc perso genre

Code :

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

1
2
3
4
5
6
7
procedure TForm1.RecupMessagesPerso(var Msg);
begin
  // gestion de mes messages
  if Msg = WM_... then ...
  //
  // inherited; // plus besoin de ça ?
end;

Soit il faudrait de toute façon surcharger une des méthodes ci-dessus pour l'appeler, soit remplacer purement et simplement WndProc par SetWindowLong(GWL_WNDPROC).
Aucun intérêt ici

Pense aussi à optimiser WndProc : un case .. of sera mieux que des if..then..else if

[Jipété]

Bonsoir,

et merci de vos retours.

@Foetus : merci pour ce WM_APP que j'ignorais, tout comme Lazarus, d'ailleurs,
Bah, un vieux coup de const et le tour serait joué, mais je ne suis pas concerné : c'est pour les messages entre applications. À l'intérieur d'une seule appli,

For sending private messages within a window class, an application can use any integer in the range WM_USER through 0x7FFF.

source

@anapurna : non je ne veux pas intervenir au niveau de WM_PAINT, ma question était surtout pour optimiser la communication inter-frames de mon appli et éviter de mettre la pagaille dans les messages système.

@andnotor : merci pour toutes ces précisions. Je comprends bien que le plus sympa dans mon cas aurait été l'utilisation de Application.OnMessage mais ça aussi Lazarus ne connaît pas...
Bien noté pour le case of...


Bah, au final, la MainForm sera équipée d'une proc DefaultHandler (pour pouvoir recevoir les messages des frames) et chaque frame d'une proc dédiée à la réception, genre frame1 recevra LM_APP+1, frame2 LM_APP+2, etc.

Ça vous semble correct et propre ?

[foetus]

@Foetus : merci pour ce WM_APP que j'ignorais, tout comme Lazarus, d'ailleurs,
Bah, un vieux coup de const et le tour serait joué, mais je ne suis pas concerné : c'est pour les messages entre applications. À l'intérieur d'une seule appli, source

Si tu regardes les Internets , tu peux lire ceci: WM_USER vs WM_APP

You should use WM_USER when creating a set of messages for a custom control.

You should use WM_APP when you are ... subclassing controls, or need to send messages to your application window that have meaning to the app.

Ou bien encore ceci: Using WM_USER, WM_APP or RegisterWindowMessage

WM_USER messages are typically used to implement control specific messages when developing a control. If you had developed an image editing control, and needed to allow users of the control to set the image, you might go:

WM_APP messages are typically used to implement application level logic. If you want to send your application a specific message to perform an action...

Et moi, dans mon application C++, avec une table de messages, j'utilise une énumération qui commence à WM_APP + 1, et je n'ai jamais eu de problèmes

[Jipété]

Salut salut,

en résumé, chaque frame est équipée d'une méthode ReceptionDeMessages(var Msg: TLMessage); message LM_FROMOFFICE; (TLMessage spécifique à Lazarus) lui permettant de recevoir les messages en provenance de la MainForm, et la MainForm d'une méthode DefaultHandler(var Msg); override; lui permettant de recevoir les messages en provenance des frames.

J'ai défini mes constantes de messages ainsi :

Code :

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

1
2
3
4
5
6
7
8
9
const
  //https://msdn.microsoft.com/fr-fr/library/windows/desktop/ms644930%28v=vs.85%29.aspx
  LM_APP = $00008000; // 32768  -- maximum bfff (49151)
 
  LM_FROMFRAME1 = LM_APP+1;
  LM_FROMFRAME2 = LM_APP+2;
  LM_FROMFRAME3 = LM_APP+3;
  LM_FROMFRAME4 = LM_APP+4;
  LM_FROMOFFICE = LM_APP+9;

Quant aux frames, pour discuter avec la MainForm ou entre elles (auquel cas elles utilisent la redirection fournie par la proc de la MainForm), elles utilisent simplement objetcible.Perform(IDENTIFIANT_2_MESSAGE, WParam, LParam); avec W et LParam embarquant les informations utiles (destinataire, "démarrer le timer", "utiliser telle couleur", etc.)
J'ai écrit "objetcible" car la MainForm, faisant office de dispatcher et de routeur, utilise la même construction pour envoyer vers les frames.


That's all, folks!, et merci à tous.