Utiliser les "user messages" (W/LM_USER+xyz)

Version imprimable

08/10/2016, 16h42
Jipété

Utiliser les "user messages" (W/LM_USER+xyz)

Bonjour,

J'ai besoin de faire communiquer des TFrames entre elles et aussi vers/depuis la fiche principale. Après m'être pris une quantité hallucinante d'Access Violations (normal, la complétion de code à partir d'une frame me propose les objets publiés par une autre frame, mais la moindre tentative de lecture --> AV !), j'ai trouvé une discussion pour Delphi ultra légère pour mettre en œuvre une solution simple à base de ces user messages, tout ce que j'aime :ccool:

Vite vite un coup de copier/coller vers mon Linux Laz1.4, mise en place du projet comme le monsieur explique, F9, exécution, clic sur le bouton et... rien :aie:
Transport du projet sous XP (Laz 1.6), F9, le bouton et... encore rien :koi:

Après des recherches et la lecture d'une page au nom évocateur (Lazarus For Delphi Users, ça m'a rappelé un vieux tuto qui expliquait comment passer de VB [3, à l'époque] à Delphi), tout en bas peut-être la solution...

Pas beaucoup de lignes à lire, pour un sujet aussi important ça n'inspire pas confiance, mais il y a un lien, alors cliquons en croisant les doigts (oui, parce que le nombre de fois où à partir de l'aide je gagne des http404, là aussi je pourrais faire une belle collec'), découvrons la page qui s'affiche et là, stupeur en ce qui concerne mon problème :

Citation:

FAQ
Processing user messages in your window
write me

C'est tout.
Depuis janvier 2015 au moins.
Merci les gars... :pleure: :pleure: :pleure:

Et ici, quelqu'un sait comment faire fonctionner les user messages ?
Parce que sinon, c'est tout mon projet qui part à la poubelle...

Merci de vos retours,
08/10/2016, 18h28
anapurna

Salut,

Peut-être que ce tuto t'aidera.
S'il y a quelque chose que tu ne comprends pas, repose ta question après la lecture.

Salut anapurna,

Merci pour le lien,

Citation:

Envoyé par anapurna

peut-être que ce tuto t'aidera
si tu as quelque chose que tu comprends pas, repose ta question après la lecture

mais manque de bol, les messages sous Lazarus ça ne doit pas juste être du copier/coller depuis du code Delphi (et un peu d'adaptation), c'est surement beaucoup plus compliqué que ça.

Dans ton tuto, comme je l'avais déjà un peu pratiqué à l'époque de Delphi, je suis allé directement à l'exemple de la fin, j'ai généré les 2 exe's (après un peu de bricolage) mais s'ils se lancent bien, ils ne se causent pas... :aie:

Quant à mon problème, par exemple je crée une frame, je la pose sur une form avec un TEdit et dans sa procédure OnChange je mets unitFrame.Frame1.SendDataMsg;Ensuite, de l'autre côté, dans la frame, j'ai ça :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 procedure TFrame1.SendDataMsg; var aForm: TCustomForm; hwnd: THandle; begin aForm := GetFirstParentForm(Self); if aForm <> nil then aForm.Perform(LM_MONJOLIMESSAGE, 0, 0); // non exécuté, d'où les tentatives suivantes : hwnd := 0; //hwnd := Frame1.GetParentHandle; // AV ! // ou if Frame1.Parent.Handle <> 0 then hwnd := Frame1.Parent.Handle; // AV ! // suite enlevée pour ne pas alourdir le post end;
Je clique dans l'edit, je tape sur une touche et voilà ! AV ! Une frame n'est pas foutue de récupérer le handle de son parent :roll:
L'idée vient de là.

Salut,

OK tu veux créer ton propre message.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
const
  WM_MONJOLIMESSAGE = WM_USER + 1;
 
TMyForm = Class(TForm)
....
 procedure OnMONJOLIMESSAGE(var Msg: TMessage); message WM_MONJOLIMESSAGE;
....
End;
...
 
procedure TMyForm.OnMONJOLIMESSAGE(var Msg: TMessage);
begin
  ... ici je fais ce que je veux quand je reçois mon message
end;

Pour exécuter le message :

Code:

PostMessage(self.Handle,WM_MONJOLIMESSAGE,0,0);

Citation:

Envoyé par anapurna

ok tu veut créer ton propre message

Non !
Ça, je sais faire. J'ai déjà fait, il y a longtemps, en D7.

Citation:

Envoyé par anapurna

pour exécuter le message

Code:

PostMessage(self.Handle,WM_MONJOLIMESSAGE,0,0);

Là je ne comprends pas : self c'est soi, ça revient à s'envoyer un message à soi-même¹, comme si je rédigeais un courrier sur du papier, que je le mettais dans une enveloppe avec mon adresse écrite dessus, que je mette un timbre et que je l'apporte à la Poste pour que ça me revienne 2 jours plus tard, ou plus, ou même jamais, des fois...
J'ai plus vite et mieux fait de le mettre directement dans ma boîte aux lettres, :ptdr: :ptdr: :ptdr:

Ce que je veux c'est envoyer un message d'une frame à une autre et là, c'est mort de chez mort, pour le moment, sauf si on aime les AV... :aie: :calim2: :roll: :weird:

---
¹ : j'ai d'ailleurs fait le test suivant :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 procedure TMain.FormShow(Sender: TObject); begin Caption := IntToStr(self.Handle); end; procedure TMain.Button2Click(Sender: TObject); begin PostMessage(self.Handle, WM_MONJOLIMESSAGE, self.Handle, 0); end; procedure TMain.OnMONJOLIMESSAGE(var Msg: TMessage); begin ShowMessage('message reçu ' + IntToStr(Msg.WParam)); end;
Et que crois-tu qu'il arrivât ? Ben c'est le même handle qui s'affiche dans la barre de titre de la fiche et dans le MessageBox, confirmant ce que je disais + haut. Aucun intérêt, donc, sauf didactique.

Bon, j'y retourne...

09/10/2016, 01h07
anapurna
Salut,

Ton exemple est simpliste mais c'est normal, tu passes le handle de la forme principale et tout ceci se passe dans cette forme.

Les frames sont posées sur la même forme principale, non ? Dans la même application ?

Donc si je comprends bien, tu veux passer ton message dans ta frame. Pour moi, la forme principale sert de hub pour tes messages.
Disons que je cherche la logique que tu veux mettre en place.
As-tu essayé ceci ?
Code:

1 2 3 4 5 6 7 TMFrame1 = Class(TFrame) ... procedure OnMONJOLIMESSAGE(var Msg: TMessage); message WM_MONJOLIMESSAGE; ... End; ...
Code:

1 2 3 4 5 procedure TMFrame1.OnMONJOLIMESSAGE(var Msg: TMessage); begin ShowMessage('message reçu ' + IntToStr(Msg.WParam)); end;
09/10/2016, 01h34
Jipété

1 pièce(s) jointe(s)
Citation:

Envoyé par anapurna

Ton exemple est simpliste mais c'est normal tu passes le handle de la forme principale et tout ceci se passe dans cette forme

Euh, c'est ton exemple, c'est toi qui me l'a proposé...

Citation:

Envoyé par anapurna

les frames sont posées sur la meme form principale non ? dans la meme application ?

Ben oui, sinon aucun intérêt.

Citation:

Envoyé par anapurna

pour moi la forme principale sert de hub pour tes message
disons que je cherche la logique que tu veut mettre en place

C'est ça, c'est juste tout simplement ça : je veux que les frames puissent communiquer entre elles et avec la form qui les contient.
Citation:
Envoyé par anapurna

As tu essayé ceci ?

Code:

1 2 3 4 5 6 7 TMFrame1 = Class(TFrame) ... procedure OnMONJOLIMESSAGE(var Msg: TMessage); message WM_MONJOLIMESSAGE; ... End; ...

Code:

1 2 3 4 5 procedure TMFrame1.OnMONJOLIMESSAGE(var Msg: TMessage); begin ShowMessage('message reçu ' + IntToStr(Msg.WParam)); end;
Ben oui, c'est moi qui l'ai posté...

Par contre, maintenant j'ai un problème avec l'IDE (j'en ai marre, si tu savais, j'en peux plus, là...) : sans rien faire dans la procédure OnClick d'un bouton (je faisais des recherches dans d'autres procédures), quand je veux la reprendre elle ne fonctionne plus !
Je veux savoir pourquoi, je mets donc un point d'arrêt mais le programme n'y passe pas, j'ai le rond rouge avec la coche verte (je ne sais pas ce que ça veut dire, et je ne sais pas où est l'explication de ces icônes...) :
Pièce jointe 222214

C'est vraiment infernal, des fois, Lazarus...

Salut

Ne serait-ce pas plus simple de passer par des événements plutôt que par des messages ?
Genre

Code:

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
27
28
29
30
Type 
  TOnMyEvent = procedure(StrMess : String) of Object ;
 
TMYFram = Class(TFrame)
  fMyEvent : TOnMyEvent 
  Procedure UsesMyEvent(StrMess : String)
  ...
  Property MyEvent : TOnMyEvent read fMyEvent write fMyEvent
end; 
 
TMyForm = Class(TForm)
  Procedure FormCreate(Sender : TObject);
  Procedure OnMyEvent(Sender : TObject;StrMess : String);
end;
...
Procedure TMYFram.UsesMyEvent(StrMess : String);
begin
  if assigned(fMyEvent) Then
   fMyEvent(StrMess); 
end;
 
Procedure TMyForm.FormCreate(Sender : TObject);
begin
  MyFram1.MyEvent = OnMyEvent;
end;
...
Procedure TMyForm.OnMyEvent(Sender : TObject;StrMess : String);
Begin
  Showmessage(Strmess)
end

09/10/2016, 09h46
Jipété

1 pièce(s) jointe(s)
Bonjour,

Citation:

Envoyé par anapurna

ce serait pas plus simple de passer par des événements plutôt que par des messages ?

Oh non, surement pas, non...
Démonstration, après avoir scrupuleusement vérifié tes bouts de code, rajouté les points-virgules oubliés, ce genre de choses...

Ça bloque à la compil dès la première ligne :aie:
Pièce jointe 222227

Et si je déplace tes trois lignes (
Code:

1 2 3 fMyEvent: TOnMyEvent; Property MyEvent: TOnMyEvent read fMyEvent write fMyEvent; Procedure UsesMyEvent(StrMess: String);
) dans la section "public" de la frame, j'ai d'autres erreurs. Tu l'as testé ton code avant de poster ? Sous Delphi peut-être ?

En attendant, je suis bloqué là :calim2:...

En gros, faire de l'informatique ça revient, pour prendre une image, à, lorsqu'on veut utiliser sa voiture pour aller faire les courses, d'abord commencer par fabriquer le moteur, le régler, l'ajuster, toussa toussa, et pendant ce temps les aiguilles de la montre tournent et le frigo ne se remplit pas.

Et le problème de debug dont je parlais cette nuit n'est pas réglé : je pensais qu'après l'extinction des machines les choses seraient rentrées dans l'ordre mais que nenni...
Au final, pour fabriquer le moteur dont je parle au paragraphe précédent, j'ai des outils en carton et des matériaux en papier-alu.
Vous voyez le truc ?
09/10/2016, 11h55
anapurna

1 pièce(s) jointe(s)

Salut,

Voici un test rapide que je viens de faire.
Il y a une petite astuce entre Delphi et Lazarus : pour l'affectation, il faut mettre @ devant la méthode.
Regarde le source fourni et dis-moi si cela te convient : Pièce jointe 222248 Pièce jointe 222248
09/10/2016, 12h22
Jipété

Citation:

Envoyé par anapurna

il y a une petite astuce entre delphi et lazarus
pour affectation il faut mettre @ devant la methode

Je la connais depuis longtemps, c'est la première chose que j'ai tentée quand j'ai eu l'erreur à ce niveau, mais ça m'a donné une autre erreur de compil, je ne sais plus laquelle, peu importe, c'est à partir de là que j'ai posté.

Citation:

Envoyé par anapurna

voici un test rapide que je viens de faire
regarde le source fourni et dis-moi si cela te convient

Oui et non...
Oui car cela fonctionne, mais non car en ce qui me concerne, j'ai 4 frames alors que ton projet n'en a qu'une. Mais ce n'est pas grave, je vais voir ce que je peux en tirer, mais pas aujourd'hui, j'ai d'autres trucs à gérer.

Merci pour le coup de main, bon dimanche, je te tiens au courant.

EDIT : j'ai rajouté une Frame2 sur la TabSheet2, à la place de dupliquer la Frame1 comme tu faisais, ça fonctionne, bien sûr, mais comme fonctionnerait un simple ShowMessage dans une fiche : chaque bouton vit sa vie dans sa frame, indépendamment de ce qui se passe à côté, alors que moi j'ai besoin d'une interaction !

Quand je clique sur le bouton de la frame1, j'ai besoin que ça soit la frame2 qui réagisse, sinon ça ne sert à rien.

Salut,

Sur mon test j'en ai profité pour essayer les messages.

Voici les petites modifs que j'ai faites dans le tframe :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
implementation 
  uses Windows;
 
procedure TFrame1.Button1Click(Sender: TObject);
var
  aForm: TCustomForm;
  // St : String;
begin
  // St := 'Frame1';
  // ExecOnEvent(st);
  aForm := GetFirstParentForm(Self);
  windows.PostMessage(aForm.Handle, WM_MONJOLIMESSAGE, self.Handle, 0);
end;

Dans le TForm :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
uses ... ,Udata,UFrame1,messages;
 
TForm1 = class(TForm) 
...
 Protected
      Procedure OnMyMainEvent(Sender : TObject;const StrMess : String);
      procedure OnMONJOLIMESSAGE(var Msg: TMessage); message WM_MONJOLIMESSAGE;
 ...
end;
 
implementation
// uses ....
 
...
procedure TForm1.OnMONJOLIMESSAGE(var Msg: TMessage);
begin
  ShowMessage('message reçu ' + IntToStr(Msg.WParam));
end;

dans le udata

Code:

1
2
3
4
5
6
 
uses
  ...,messages;
 
const
  WM_MONJOLIMESSAGE = WM_USER + 1;

Tout ceci marche très bien sous Windows et sous Lazarus. ;)
Bon dimanche à toi.

09/10/2016, 19h16
Jipété
Bonsoir,

Citation:

Envoyé par anapurna

Tout ceci marche très bien sous Windows et sous Lazarus. ;)
Bon dimanche à toi.

Chez moi aussi tout va bien de ce côté-là.

Ce qui me pose problème, c'est ça :
Citation:
Envoyé par anapurna

Code:

1 2 3 4 procedure TForm1.OnMONJOLIMESSAGE(var Msg: TMessage); begin ShowMessage('message reçu ' + IntToStr(Msg.WParam)); end;
Parce que j'ai besoin de voir ce 'message reçu' dans un TEdit de la Frame2 et pas dans un ShowMessage de la Form...

Au plaisir de te lire,

PS : il semblerait que cette histoire de points d'arrêt non fonctionnels soit liée à la présence dans l'inspecteur d'objets de restes de frames : j'avais décidé de créer mes frames dynamiquement après un premier test statique, or elles étaient restées dans l'arbre des compos de la Form dans l'inspecteur : il a suffi que je les enlève de là pour retrouver un fonctionnement normal, ouf !
Enfin, dans 1 projet. J'en ai encore 1 autre qui fait de la résistance...

hello,

Citation:

Envoyé par Jipété

Parce que j'ai besoin de voir ce 'message reçu' dans un TEdit de la Frame2 et pas dans un ShowMessage de la Form...

pourquoi ne pas traiter les messages dans les frames et envoyer les messages dans le handle de la Frame désirée ? Voici un exemple où j'envoie un message dans la Frame2 et le message s'écrit dans le TEdit de la frame de reception. Pour réaliser celà il a fallu que je rende les Frames publiques dans le umain. Il y a encore du boulot par exemple pour faire un traitement différent sur le clic du bouton selon la Frame concernée.
Code:

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 27 28 29 30 31 32 33 34 35 36 37 38 unit uframe1; {$mode objfpc}{$H+} interface uses Classes, SysUtils, FileUtil, Forms, Controls, StdCtrls,Udata,messages; type { TFrame1 } TFrame1 = class(TFrame) Button1: TButton; Edit1: TEdit; procedure Button1Click(Sender: TObject); private protected procedure OnMONJOLIMESSAGE(var Msg: TMessage); message WM_MONJOLIMESSAGE; public end; implementation uses Windows,umain; {$R *.lfm} procedure TFrame1.Button1Click(Sender: TObject); begin windows.PostMessage(Form1.FFrame2.Handle, WM_MONJOLIMESSAGE, self.Handle, 0) end; procedure TFrame1.OnMONJOLIMESSAGE(var Msg: TMessage); begin Edit1.Text := IntToStr(Msg.WParam); end; end.
Au fait comme c'était le handle de la Frame de départ qui était envoyé comme paramètre dans le code du message de Anapurna tu pouvais faire aussi dans le traitement du message de la Form1 :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 procedure TForm1.OnMONJOLIMESSAGE(var Msg: TMessage); begin // ShowMessage('message reçu ' + IntToStr(Msg.WParam)); If Msg.WParam = FFrame1.Handle Then begin FFrame2.Edit1.Text := 'message envoyé par Frame1'; end; If Msg.WParam = FFrame2.Handle Then begin FFrame1.Edit1.Text := 'message envoyé par Frame2'; end; end;
Ami calmant, J.P (pas té)

Bonjour,

Ça avance, ça avance.. Doucement mais ça avance : je crée des frames dynamiques, c'est contraignant au niveau du design mais c'est sympathique à l'utilisation, et je commence à réussir à envoyer un message d'une frame à l'autre en passant par un bureau de poste centralisé qui sert de dispatch sur la mainform.

Mon problème c'est que je ne sais pas ce que je fais, dans le sens où, au final, les noms des objets et des procédures ne sont pas parlants du tout

Par ailleurs, J.P, cette idée d'adresser directement le TEdit sur la frame ne me plaît pas du tout : je préférerais quelque chose de plus générique, un message à destination de la frame, à charge pour elle de le gérer, quelque chose du genre ExecOnEvent(sMess, iSrc, iDst);
Ça commence à fonctionner, mais je m'y perds avec ces histoires d'identification d'objets pour savoir qui fait quoi.

Prenons un exemple :
je ne sais plus s'il vient d'anapurna, trouvé sur le web, etc., et donc :
Code:

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 27 28 29 30 TFrame1 = class(TFrame) Button1: TButton; Edit1: TEdit; Panel1: TPanel; procedure Button1Click(Sender: TObject); private fOnEvent : TOnMyEvent; public Property OnEvent: TOnMyEvent read fOnEvent write fOnEvent; Procedure ExecOnEvent(const StrMess: String; const src,dst: integer); end; implementation {$R *.lfm} procedure TFrame1.Button1Click(Sender: TObject); var aForm: TCustomForm; begin ExecOnEvent('Message de', 1, 3);// 1 parce qu'on est sur la fr1, 3 pour envoyer vers la fr3 aForm := GetFirstParentForm(Self); if aForm <> nil then PostMessage(aForm.Handle, WM_TEST, self.Handle, 0); end; Procedure TFrame1.ExecOnEvent(const StrMess: String; const src,dst: integer); begin if assigned(fOnEvent) Then fOnEvent(Self,StrMess,src,dst); end;
C'est quoi ce ExecOnEvent dans le sens ça fait quoi ? Ça reçoit ? Ça envoie ? Je n'en sais rien. On dirait que ça envoie, mais comment ?
Pareil pour la Property OnEvent: TOnMyEvent read fOnEvent write fOnEvent; si read et write pointent sur le même machin (qui lui, pointe sur le type dans uData :
Code:

1 2 Type TOnMyEvent = Procedure(Sender: TObject; const StrMess: String; const src,dst: integer) of object;
), je ne sais pas comment distinguer le read du write, et je pense que mes gros soucis viennent de ces lacunes.

Merci à vous de les combler, à moins que je ne trouve un tuto qui va bien, mais par exemple, celui fourni par anapurna dans sa première réponse ne fonctionne pas (j'ai réussi hier soir à pas d'heure à avoir un label qui changeait de caption mais c'est tout...)

Pour en revenir à ces noms "parlants", j'ai changé dans une des frames ce ExecOnEvent par un OnReceiveMessage, ça fonctionne mais c'est peut-être pas bon et j'ai peut-être complètement tort : je n'en sais rien, j'y vais à tâtons, je change un truc et je vois ce qui se passe (AV, rien, ça fonctionne, etc.)
Par exemple, j'ai viré tous ces JOLIMESSAGE et autres MESSAGE_x pour ne conserver qu'un seul WM_TEST et ça fonctionne. Alors à quoi servent plusieurs messages ?

Ah lala, que de questions que de questions...

10/10/2016, 11h45
anapurna

Salut,

tu confonds un peu tout. :D
Les messages et les événements ne sont pas du tout la même chose.

Les message sont asynchrones, c'est-à-dire qu'il sont placés dans une file d'attente et ne seront exécutés qu’après les autres messages déjà présents.
Il existe des moyens pour forcer et donner des priorités mais le principe est là .

Les événements c'est l'histoire des properties (propriété) (OnClick... onEvent...). Pour pouvoir utiliser les propriétés avec des événements, il faut créer un type de fonction et/ou procedure of object. Le read et le write autorisent l'affectation ou non de cette méthode ; dans notre cas il faut pouvoir affecter (write).
Si tu lis mon code, je crée une variable Global en private à l'object du type de la fonction fon... Et ensuite, dans la property, je fais référence à cette variable.
Pour l'affectation sous Lazarus, on s'aperçoit que l'on affecte l'adresse de la méthode, d'où le @.

Rien ne t’empêche de passer en paramètre une variable à la méthode.
Autre chose, la source c'est souvent le sender donc tu peux te servir de lui pour définir qui a envoyé l’événement.

Plus j'y pense et plus je me dis que ton problème ressemble au design pattern Observer.

Ola !

Citation:

Envoyé par anapurna

salut

tu confonds un peu tout :D
[...]

Oh, tu sais, c'est fort probable que je me fasse des nœuds dans la tête, faut dire aussi qu'avec ce que je vis, rien n'est simple.

Regarde : tu m'as indiqué un tuto dans ton premier post, ce matin je le reprends à tête reposée, le premier exemple fonctionne, je m'amuse à changer le nom de la proc juste pour jouer et vérifier que ça peut le faire (genre changer WMCHAR en Recup_Clavier, c'est + parlant -- et aussi parce que je doute de tout, maintenant), juste que le monsieur a oublié de préciser qu'il ne fallait surtout pas d'autres composants sur la fiche, sinon il y en a un qui va prendre le focus (un bouton par ex.) et la récup des touches ne fonctionnera plus.
Tu passes du temps là-dessus avant de capter...

Ensuite, chapitre V, la communication inter-applis, bon c'est simple ça ne fonctionne pas. D'après l'auteur ça fonctionne et chez moi, il ne se passe rien sous Windows et ça part en AV sous Linux. Alors, pb Lazarus vs Delphi ou pb Jipété ?
Pourtant il n'y a quasiment rien :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 procedure TMainFrame.DefaultHandler(var Msg); // reçoit tous les messages begin inherited DefaultHandler(Msg); if (TMessage(Msg).Msg = UnIdentifiantDeMessage) then begin if (TMessage(Msg).WParam) = 1 then begin // check du param envoyé par l'émetteur ShowMessage(IntToStr(TMessage(Msg).Msg)); // action en fonction du message end else Label1.Caption := 'Message reçu'; end; end; procedure TMainFrame.btnEnvoyerMessClick(Sender: TObject); begin // si on est l'émetteur // déjà dans FCreate (mix émet/récep) // UnIdentifiantDeMessage := WM_USER+1;//RegisterWindowMessage('MessageUB45'); SendMessage(HWND_BROADCAST, UnIdentifiantDeMessage, 1, 0); end; procedure TMainFrame.FormCreate(Sender: TObject); begin // si on est le récepteur UnIdentifiantDeMessage := WM_USER+1;//RegisterWindowMessage('MessageUB45'); end;
et je gagne l'AV en cliquant sur le bouton. J'ai beau commenter toute la proc de DefaultHandler (tant pis pour la réception dans un premier temps), c'est pareil.
Et le pire c'est que si je remplace le SendMessage d'origine par un PostMessage, ça ne fonctionne pas mieux alors que dans d'autres progs je peux le faire fonctionner, ce PostMessage (pas testé avec le Send dans les autres progs).

Et qu'est-ce que je peux bien faire face à ça, moi, à part passer un temps dément à comparer mot à mot les progs qui fonctionnent avec celui qui coince ?

Citation:

Envoyé par anapurna

plus j'y pense et plus je me dis que ton problème ressemble aux design pattern Observer

Mais de quoi tu parles, là ?
Tu ne trouves pas que c'est suffisamment compliqué et prise de tête comme ça ? Tu veux en rajouter une couche ?
Je vais finir à l'asile avec tout ça, moi...

Salut JP.

J'avoue que je ne saisis pas très bien où se situe le problème...

Si l'on suppose que ta fiche gérant les frames s'appelle Form1, celle-ci n'a pas besoin d'envoyer de messages aux frames, elle peut directement appeler une procédure publique (spécifique à chaque frame).
Code:

1 2 3 4 procedure TForm1.Button1Click(Sender: TObject); begin Frame1.Execute('hello'); end;
Par contre, à la fin du traitement, la Frame va devoir envoyer un message à son parent (Form1) pour lui signaler que l'exécution a été faite (ceci permet à l'unité de la Frame de ne pas utiliser l'unité de Form1, ce qui me parait préférable). Par exemple, le message LM_MESSAGEFROMFRAME (défini dans une unité spécifique reférencée dans les unités de Form1 et de chaque Frame).

Dans l'unité spécifique :
Code:

1 2 const LM_MESSAGEFROMFRAME = LM_USER + 1;
Dans l'unité de Frame1 :
Code:

1 2 3 4 5 6 procedure TFrame1.Execute(S: string); begin // traitement... //puis envoi du message (Parent as TWinControl).Perform(LM_MESSAGEFROMFRAME,Self.Handle,0); end;
Dans l'unité de Form1 :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 private procedure MessageFromFrame(var Msg: TMessage); message LM_MESSAGEFROMFRAME; //... procedure TForm1.MessageFromFrame(var Msg: TMessage); begin // réception du message If Msg.WParam = Frame1.Handle then Frame2.Execute(Frame1.Edit1.Text, clRed) // mise à jour de Frame2 else // ... end;
A noter que tu peux, par exemple, envoyer le message à partir d'un événement OnChange d'un Edit placé sur Frame1.
Donc Form1 sert de boite postale : elle reçoit un message de frame1, lance l'Execute de frame2 qui va renvoyer un message pour mise à jour de frame3...

Cordialement.
Thierry

salut

solution avec les evenement

pour la frame

Code:

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
 
  TFrame1 = class(TFrame)
    Button1: TButton;
    Edit1: TEdit;
    procedure Button1Click(Sender: TObject);
  private
    { private declarations }
    fOnReceiveEvent : TOnReceiveEvent;
    fOnEmitEvent : TOnEmitEvent;
    Procedure EmetMessage(StrMess : String);
 
  public
    { public declarations }
    Procedure OnReceiveEvent(Sender : TObject;var StrMess : String);
    Property OnEmitEvent : TOnEmitEvent read  fOnEmitEvent write fOnEmitEvent;
  end;
 
implementation
uses windows;
 
{$R *.dfm}
 
 
Procedure TFrame1.EmetMessage(StrMess : String);
begin
  If assigned(OnEmitEvent) Then
    fOnEmitEvent(self,StrMess);
end;
 
Procedure TFrame1.OnReceiveEvent(Sender : TObject;var StrMess : String);
var
  St : String;
begin
  If Sender <> Self Then
  begin
     Edit1.Text := StrMess;
  end;
end;
 
procedure TFrame1.Button1Click(Sender: TObject);
var
  St : String;
begin
  St := (Sender as TControl).Name; // Ici le message
  EmetMessage(St);
end;

dans la forme Principale

Code:

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
 
TForm1 = class(TForm)
    ImageList1: TImageList;
    PageControl1: TPageControl;
    TabFrame1: TTabSheet;
    TabFrame2: TTabSheet;
    procedure FormCreate(Sender: TObject);
  private
    fOnEmitEvent    :  TOnEmitEvent;
    fOnReceiveEvent : array of TOnReceiveEvent;
 
    { private declarations }
    FFrame1 : TFrame2;
    FFrame2 : TFrame2;
  Protected
//      Procedure OnReceiveMainEvent(Sender : TObject;Var StrMess : String);
      Procedure ExecEmitMainEvent(Sender : TObject;Const StrMess : String);
      Function GetOnReceiveEvent(Index : integer) : TOnReceiveEvent;
      Procedure SetOnReceiveEvent(Index : integer;value : TOnReceiveEvent);
  public
    { public declarations }
    Property OnEmitEvent : TOnEmitEvent read  fOnEmitEvent write fOnEmitEvent;
    Property OnReceiveEvent[Index : integer] : TOnReceiveEvent read  GetOnReceiveEvent write SetOnReceiveEvent;
 
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.dfm}
 
{ TForm1 }
 
procedure TForm1.FormCreate(Sender: TObject);
begin
  FFrame1 := TFrame1.create(Self);
  FFrame1.Name := 'Test1';
  FFrame1.Parent := TabFrame1;
  FFrame1.OnEmitEvent := ExecEmitMainEvent;
  SetOnReceiveEvent(1,FFrame1.OnReceiveEvent);
 
  FFrame2 := TFrame1.create(Self);
  FFrame2.Name := 'Test2';
  FFrame2.Parent := TabFrame2;
  FFrame2.OnEmitEvent := ExecEmitMainEvent;
  SetOnReceiveEvent(2,FFrame2.OnReceiveEvent);
//  OnReceiveEvent := FFrame2.OnReceiveEvent;
end;
 
Procedure TForm1.ExecEmitMainEvent(Sender : TObject;Const StrMess : String);
var
  Str : String;
  i : Integer;
begin
  if assigned(fOnReceiveEvent) Then
   for i := Low(fOnReceiveEvent) to high(fOnReceiveEvent) do
   begin
     Str := StrMess;
     if assigned(fOnReceiveEvent[i]) Then
        fOnReceiveEvent[i](Sender,Str);
  end;
end;
 
Function TForm1.GetOnReceiveEvent(Index : integer) : TOnReceiveEvent;
begin
  Result :=nil;
  if Index < Length(fOnReceiveEvent) Then
     Result := fOnReceiveEvent[Index];
 
end;
 
Procedure TForm1.SetOnReceiveEvent(Index : integer;value : TOnReceiveEvent);
begin
 
  if Index >= Length(fOnReceiveEvent) Then
    SetLength(fOnReceiveEvent,Index+1);
  fOnReceiveEvent[Index] := value
  //fOnReceiveEvent[Index] := @value A voir pour lazaruz
end;

la définition des événements

Code:

1
2
3
4
Type
 
  TOnEmitEvent = Procedure(Sender : TObject ;const StrMess : String) of object;
  TOnReceiveEvent = Procedure(Sender : TObject ;var StrMess : String) of object;

testé sous delphi j'ai pas lazarus sur place ... je testerai ce soir apres mes autres activité
je pense qu'il faut ajouter le @

10/10/2016, 19h35
Jipété

2 pièce(s) jointe(s)
Salut les copains,

les grands esprits se rencontrent, il se trouve que je viens de finir moi aussi une petite maquette qui fonctionne d'une manière qui me satisfait, m'inspirant de vos trucs et machins, ;)

Citation:

Envoyé par ThWilliam

J'avoue que je ne saisis pas très bien où se situe le problème...

Si l'on suppose que ta fiche gérant les frames s'appelle Form1 celle-ci n'a pas besoin d'envoyer de messages aux frames, elle peut directement appeler une procédure publique (spécifique à chaque frame).

Appeler une procédure publique ou envoyer un message aux frames, pour moi ça revient au même (avec une préférence pour le message, je n'aime pas trop ces uses machin dans tous les sens, plus le fait qu'il me semble plus facile de faire évoluer un système de messages.)

Citation:

Envoyé par ThWilliam

Donc Form1 sert de boite postale : elle reçoit un message de frame1, lance l'Execute de frame2 qui va renvoyer un message pour mise à jour de frame3...

Ben voilà, j'en étais là aussi : Form1 sert de dispatcher du courrier, c'est le tri postal :mrgreen:
Juste qu'au lieu de lancer l'Execute de Frame2, elle demande (gentiment et poliment) à Frame2 de bien vouloir se lancer elle-même son Execute :P

Citation:

Envoyé par anapurna

solution avec les événements

Merci de ta participation.
Je t'avoue humblement que cette avalanche de procédures, méthodes fonctions objets etc. se terminant tous par "Event" m'a tué les yeux et l'envie de comprendre.
C'est assez illisible pour moi, du coup je n'accroche pas.

Par contre j'ai quand même une question pour toi, puisque tu as du Delphi : le tuto que tu m'as proposé, as-tu réussi à la faire fonctionner ? Pour moi c'est niet, sous XP comme sous Lazarus.
J'aimerais bien qu'on en reparle (puisqu'on reste dans le sujet).

Ah, ma maquette :
Pièce jointe 222371

Alors question Frames, les gars de Lazarus ont encore du boulot : la partie jaune en bas c'est ma frame, et le mémo qu'elle embarque est censé afficher une ScrollBar verticale. Vous la voyez, vous ? Je ne l'avais déjà pas en mode design, pourtant son emplacement existe, regardez les carrés noirs :
Pièce jointe 222374

Ce qui est rigolo, c'est que le code est d'une légèreté époustouflante, en 15 lignes et 2 procs c'est bouclé, et surtout, surtout, si j'avais une dizaine de frames au lieu d'une seule, il me suffirait de faire un copier/coller sur premier fichier et de juste changer le nom de la frame et roulez jeunesse ! Et le code de la form c'est pareil, c'est le même, à deux ou trois microscopiques détails près !

Bon je le présenterai un peu plus tard, quand j'aurai éclairci un point, avec vos lumières :
C'est quoi la différence entre
Code:

1 2 3 procedure TMain.DefaultHandler(var Msg); // Méthode qui intercepte les messages begin inherited DefaultHandler(Msg);
et

Code:

procedure TMain.MaProcDeReceptionDeMessages(var Msg: TMessage); // pour recevoir et traiter les messages

Si ces procédures font le même boulot, pourquoi choisir l'une plutôt que l'autre ? Une idée là-dessus ?
10/10/2016, 23h49
Jipété

1 pièce(s) jointe(s)

Le boulot de la soirée, tranquille tranquille :

Pièce jointe 222385

Ça cause dans tous les sens, je suis juste limité par mon... imagination, un classique en info :ptdr:
11/10/2016, 15h48
anapurna

Salut

j'ai fait un rapide test sur le tuto, effectivement cela ne semble pas marcher.
Il faut que je prenne plus de temps pour voir ce qui ne marche effectivement pas.

Pour les événements, c'est dommage que tu aies abandonné. :D
Tu peux faire de grande chose avec ... je m'en sers pour faire avancer un progressbar ou discuter d'une fenêtre à l'autre à l'aide d'un objet centralisateur. Je suis même sûr que tu t'en sers sans le savoir. Il te suffit de comprendre que tu as un événement des Frames -> la form et que la form redistribue à toutes les frames sans distinction... C'est elle qui détermine si elle doit afficher ou non.
Mais bon si tu as réussi à faire ce que tu voulais, bonne continuation.
11/10/2016, 19h17
Jipété

3 pièce(s) jointe(s)

Salut,

plusieurs choses à dire :
- la première, c'est que si je suis parti sur les messages c'est suite à ton tuto, :mrgreen:
- la deuxième, c'est qu'au final et en y réfléchissant bien, les événements ne sont que des messages (un peu bordéliques à gérer, pour moi).
- la troisième, c'est que je viens de voir le bout du tunnel avec ce tuto, à condition de prendre en compte les points suivants :

-- Linux on peut oublier, SendMessage n'y fonctionne pas comme sous Windows (à tel point que c'est AV systématique) ;
EDIT : j'ai retrouvé l'image que j'ai prise lorsque j'ai essayé de comprendre en avançant en pas-à-pas. Des fois que ça intéresserait quelqu'un :
Pièce jointe 222456
C'est sur la ligne lisible juste au dessus de la fenêtre d'erreur que ça plante, et ça se trouve dans gtk2proc.inc.

-- sous Windows (XP SP2 en ce qui me concerne), SendMessage ne fonctionne pas en mode BroadCast (:koi:), l'émetteur doit utiliser le handle de l'appli destinatrice du message ; je n'ai pas creusé plus avant (oui, je sais, il faudrait, mais j'ai d'autres chats à fouetter...)

Voilà une jolie image pour illustrer tout ça :
Pièce jointe 222437

Quelques mots sur comment ça se passe, en mode "télégraphique" :
Emetteur envoie Message1 depuis btnDemarrer "à condition d'utiliser le handle du destinataire" !
Recepteur le reçoit dans DefaultHandler et acquiesce avec Message2 qui contient son propre handle.

Emetteur reçoit ce Message2 dans DefaultHandler et le confirme en renvoyant un Message3 contenant son handle et celui du TEdit avec lequel on veut travailler.

À réception de ce Message3 par récepteur, celui-ci envoie au TEdit de l'émetteur l'ordre de mettre dans la chaîne "MonTexte" le texte se trouvant dans sa zone de texte, qui va être recopié dans le label2.Caption du récepteur.

Pour faire fonctionner et observer toute cette mécanique :
1- on lance un "project1.exe" qu'on passe en récepteur ;
2- on lance un autre "project1.exe" et on va remplir sa zone "HWND Appli Ext" avec le handle du récepteur, affiché dans sa barre de titre, puis on clique sur "btnDémarrer".

Voilà.
Dans le zip (testé), tout ce qu'il faut pour jouer, j'ai même laissé des vieux commentaires : Pièce jointe 222438

Allez, ça ira bien comme ça, je suis vanné, du coup !
Mais je vais cliquer sur :resolu: :ccool:
Merci à tous, et on peut continuer à discuter.

PS : désolé pour la faute d'orthographe, "Status" ça s'écrit avec un "t", mais je ne vais pas refaire l'image, j'en ai un peu marre, là, ce soir... 8-)
12/10/2016, 20h47
tourlourou

Je n'ai pê pas tout lu suffisamment attentivement...
La question qui me taraude est la suivante : comment Frame1 sait-il qu'il doit envoyer un message (ou lancer une méthode) de Frame2 ?
Qui doit avoir la réponse à la question ? La fiche principale = l'IHM. Elle seule doit organiser ça, à mon avis.
Donc, à elle d'écouter les messages de ses Frames ou de leur fournir les méthodes à déclencher.
Ceci simplifie sûrement le schéma... Mais je suis pê à côté de la plaque !
13/10/2016, 09h03
Jipété

Bonjour Yves

(désolé de ne pas avoir répondu + tôt mais quelque chose ~~est~~ [EDIT] était cassé dans la page principale du forum, qui ne remontait plus les dernières entrées -- tout au moins chez moi)

Citation:

Envoyé par tourlourou

La question qui me taraude est la suivante : comment Frame1 sait-il qu'il doit envoyer un message (ou lancer une méthode) de Frame2 ?

Ah, je crois que tu as une vision trop "machine" et que tu as perdu l'aspect "humain", :mouarf:
C'est moi qui le sais car c'est moi qui code tout ce bouzin !

Un exemple tiré du gros projet (pour lequel j'ai étudié tout ça) :
sur l'onglet 3 il y a un ColorPicker et l'idée était d'envoyer la couleur "pickée", sur <ENTER> (ben vi, tu ne peux plus utiliser la souris sauf à survoler l'écran, dans ce mode), vers l'onglet 1 où se trouve tout un tas de curseurs de réglages (teinte, saturation, etc.)
Et donc ~~la mainform, à la détection d'ENTER', envoie un message~~ sur <ENTER> dans le FormKeyDown de la mainform je lui fais envoyer un message vers la frame3 où tourne le timer du picker pour
- arrêter le timer
- récupérer la couleur sous la souris
- renvoyer cette couleur au "bureau central de dispatch des messages" (DefaultHandler de la mainform).
Tout ça est fait gentiment par la frame3 à réception du dit message car toutes les frames sont équipées d'un DefaultHandler.
Et lorsque la mainform reçoit le message en retour avec la couleur "pickée", elle se contente de basculer l'ihm sur l'onglet 1 du PageControl et d'assigner la couleur au composant prévu pour.
That's all, folks ! :ccool:

J'étais dessus hier soir et je peux te dire que ça fonctionne tip-top, juste pas se faire des nœuds avec le sens des messages et leurs identifiants (système basé sur le contenu de WParam et LParam, système écrit pas mes soins et c'est moi qui ai décidé que dans la frame3 le WParam à 1 voulait dire "objet Timer" avec LParam à 0 ou 1 pour arrêt-marche, genre pas la peine de faire tourner le timer du picker si l'appli est réduite en barre de tâches et ça, c'est détecté par la mainform qui envoie donc un arrêt au timer).

Simplissime, enfantin, si si, et avec 4 frames le code devient d'une lisibilité reposante : au lieu de scroller dans les 2000 lignes environ d'un seul onglet en v1, tout ça en v2 est réparti sur 4 onglets dans l'EDI (vi, pas confondre les onglets de l'EDI et les onglets de l'application en chantier [lol, on se croirait à Saint-Nazaire quand on y construit un paquebot, :ptdr:])

Bonne journée, j'y retourne c'est trop bien !

PS : en fait c'est ce que tu disais, et ce que je disais aussi ces derniers jours en parlant de bureau de poste centralisé :

Citation:

Envoyé par tourlourou

Qui doit avoir la réponse à la question ? La fiche principale = l'IHM. Elle seule doit organiser ça, à mon avis.
Donc, à elle d'écouter les messages de ses Frames ou de leur fournir les méthodes à déclencher.
Ceci simplifie sûrement le schéma... Mais je suis pê à côté de la plaque !

Donc non, tu n'étais pas du tout à côté de la plaque.
Mais je me suis rendu compte d'un truc : en écrivant pour poster une question ou une réponse, ça me permet d'organiser mes pensées pour bien aller au fond des choses (voir les quelques mots barrés plus haut, gardés exprès pour montrer ce que je veux dire).

2 pièce(s) jointe(s)

EDIT : laisse tomber j'ai trouvé !
Pièce jointe 222572

Merci les Suisses :ccool:
Code:

1 2 3 4 5 procedure TFrame1.MessageReceiver(var msg: TLMessage); begin // http://www.swissdelphicenter.ch/de/showcode.php?id=163 with Msg do Edit1.Text := IntToStr(Msg) + ' '+ IntToStr(WParam) + ' '+ IntToStr(LParam); end;
et ça fonctionne (dans ce sens, de la form vers la frame) juste avec ça :
Code:

1 2 3 4 5 6 7 8 9 10 const MY_MESSAGE = LM_USER + 2; type TFrame1 = class(TFrame) Button1: TButton; Edit1: TEdit; Panel1: TPanel; procedure Button1Click(Sender: TObject); procedure MessageReceiver(var msg: TLMessage); message MY_MESSAGE; private
Le code dans la form étant réduit à sa plus simple expression (mes préférés :)) :
Code:

1 2 3 4 5 6 7 8 9 procedure TForm1.FormCreate(Sender: TObject); begin Frame1 := TFrame1.create(Self); with Frame1 do begin Name := 'FrameTest'; Parent := Form1; Align := alBottom; end; end;
/EDIT

Salut,

Citation:

Envoyé par anapurna

solution avec les événements

testé sous delphi j'ai pas lazarus sur place... je testerai ce soir après mes autres activités
je pense qu'il faut ajouter le @

je reviens deux minutes là-dessus (moi j'ai passé deux heures à essayer de faire fonctionner un simple bouton, je dois être très mauvais mais je jette l'éponge) car j'aimerais bien comprendre...

Soit une simple Form verte avec un bête bouton, et une simple Frame bleue avec un bête TEdit (sur l'image il y a un bouton en plus, on s'en fiche, il sert dans le sens frame->form) :
Pièce jointe 222569

Ce que j'aurais aimé, c'est faire transiter un TLMessage au lieu d'une string et voir des choses s'inscrire dans le TEdit, genre
Code:

1 2 3 4 5 6 Procedure TFrame1.OnReceiveEvent(Sender: TObject; var Msg: TLMessage); begin If Sender <> Self Then with Msg do Edit1.Text:=IntToStr(Msg) +' '+ IntToStr(WParam) +' '+ IntToStr(LParam); end;
J'ai trituré ton exemple dans tous les sens sans arriver à rien : 9 fois sur 10 ça ne compile pas (je dois être très mauvais) et la fois où ça compile, j'ai beau cliquer sur mon bouton rien ne s'affiche dans le TEdit :
Code:

1 2 3 4 procedure TForm1.Button1Click(Sender: TObject); begin Frame1.Perform(LM_USER+2, 3, 4); // 2 nombres au pif end;
Je précise que dans l'autre sens (de la frame vers la form) en utilisant les messages en 10 minutes c'était torché et fonctionnel...
Création du message et envoi depuis la frame :
Code:

1 2 3 4 5 6 7 8 9 10 11 procedure TFrame1.Button1Click(Sender: TObject); var aMess: TLMessage; begin with TLMessage(aMess) do begin Msg := LM_USER+1; WParam := length(aText); LParam := Integer(PChar(aText)); end; Parent.Perform(aMess.Msg, aMess.WParam, aMess.LParam); end;
et réception dans la form :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 procedure WndProc(var Message: TLMessage); override; private { private declarations } Frame1: TFrame1; ... procedure TForm1.WndProc(var Message: TLMessage); begin // http://forum.lazarus.freepascal.org/index.php?topic=14939.0 if not (csDesigning in ComponentState) then begin case Message.Msg of LM_USER+1: with Message do ShowMessage(intToStr(WParam) +' '+ PChar(LParam));// "17 This is a message" YAISSE ! LM_USER+2: with Message do ShowMessage(intToStr(WParam) +' '+ intToStr(LParam)); end; end; inherited; // important to forward messages do default handlers end;
Ah, sous Lazarus il faut l'arrobase sinon pas de compil ;)

13/10/2016, 19h05
anapurna

Salut

Fais un zip de ton exemple, je regarde cela ce soir et je te dirai où il y a une erreur. ;)
13/10/2016, 19h20
Jipété

1 pièce(s) jointe(s)

Citation:

Envoyé par anapurna

salut

fait un zip de ton exemple je regarde cela ce soir
et je te dirais ou il y a une erreur ;)

Hé bien c'est très gentil à toi, mais tu n'es pas obligé de te prendre la tête avec ça, hein.

'fin bon, tu vas voir c'est tout en pagaille avec plein de lignes commentées un peu partout, un vrai bronx ; si tu n'avais pas posté vite, toutes les lignes commentées étaient supprimées !
Pièce jointe 222573
13/10/2016, 22h30
anapurna

Salut

J'ai regardé ton code... le truc qui me gêne c'est que tu est obligé d'utiliser l'élément qui doit recevoir l'information...
Cela veut-il dire que les messages ne se propagent pas dans les frames ?
13/10/2016, 22h43
Jipété

Citation:

Envoyé par anapurna

j'ai regardé ton code ... le truc qui me gene c'est que tu est obligé d'utilisé l'element qui doit recevoir l'information ...

Comment ça, je suis obligé d'utiliser l'élément... ?
C''est quoi le problème ?
J'ai des frames qui font partie intégrante de l'IHM, en gros c'est comme s'il n'y avait pas de frames mais tout dans une seule form. Et s'il n'y a qu'une seule form, une seule IHM, ben oui, l'utilisateur qui est devant l'utilise, je ne comprends pas ce que tu veux dire et pourquoi ça poserait un problème d'utiliser quelque chose qui est prévu pour être utilisé...

C'est comme si tu montais dans une bagnole et là, "ah ben merde alors, elle roule" ! Ben oui, elle est prévue pour ça.

Citation:

Envoyé par anapurna

cela veut il dire que les messages ne se propagent pas dans les frames ?

Ben oui ils se propagent dans la frame, ou alors chez toi ça ne fonctionne pas ? Chez moi quand je clique sur le bouton en haut à gauche faisant partie de la form, ça écrit dans le TEdit en bas qui fait partie de la frame.
Là encore je ne comprends pas ce que tu dis, désolé.
13/10/2016, 22h50
anapurna
Salut

Je pense que l'on ne parle pas le même langage. ;)
Code:

1 2 3 4 5 procedure TForm1.Button1Click(Sender: TObject); begin Frame1.Perform(LM_USER+2, 2, 3); end;
Tu nommes bien la frame1 pour lui envoyer le message, c'est l'équivalent de

Code:

sendMessage(frame1.handle,...

à chaque frame et chaque destinataire ; il va donc falloir les désigner.

Citation:

Envoyé par anapurna

à chaque frame et chaque destinataire il va donc falloir les désigner

Exactement de la même manière que si tu écris à tes potes Pierre Paul et Jacques : tu mets leur nom et leur adresse sur les enveloppes qui leur sont destinées, je ne vois pas où est le problème...

Par exemple, dans la frame du ColorPick, voilà ce qui se passe à la réception des messages en provenance de la MainForm :
Code:

1 2 3 4 5 6 7 8 9 procedure TfrmColorPick.DefaultHandler(var Msg); begin // source : touches p, v, ENTER depuis MainForm if (TLMessage(Msg).Msg = LM_FROMOFFICE) then case Integer(TLMessage(Msg).WParam) of 1: TimerPicker.Enabled := boolean(Integer(TLMessage(Msg).LParam)); 2: ckbxVisible.Checked := boolean(Integer(TLMessage(Msg).LParam)); 3: btnCaptureClick(Self); end; end;
Sur 1 le TimerPicker est activé ou pas, sur 2 c'est la case à cocher qui indique son état, sur 3 on active le code de capture de couleur qui, pour des raisons historiques est écrit dans la procédure d'un bouton.
Et tout fonctionne impeccablement.

Et pour en revenir à la maquette de cet après-midi, une fois la solution trouvée, je peux facilement l'adapter à cette organisation.

Et si je voulais écrire à tous les destinataires (toutes les frames), j'ai prévu un message LM_GENERAL que tous les DefaultHandler devraient pouvoir traiter (si je mets le code, mais je ne pense pas que cette appli en ait besoin -- en tout cas, la maquette présentée il y a quelques jours l'avait en démo [case à cocher "toutes" dans le post "le boulot de la soirée"])

Bonsoir, encore un sujet bien intéressant et de quoi se faire encore plus de cheveux blanc.

Alors j'ai compilé ton exemple sous Windows 10 64bit et La dernière version téléchargeable de Lazarus
voila ce que j'ai remarqué dans :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 procedure TForm1.WndProc(var Message: TLMessage); begin // http://forum.lazarus.freepascal.org/index.php?topic=14939.0 if not (csDesigning in ComponentState) then begin case Message.Msg of LM_USER+1: //with TLMessage(Message) do with Message do ShowMessage('In the Form' + intToStr(WParam) +' '+ PChar(LParam));// 17 This is a message YAISSE ! LM_USER+2: //with TLMessage(Message) do with Message do ShowMessage('In The frame ' + intToStr(WParam) +' '+ intToStr(LParam));// 17 This is a message YAISSE ! end; end; inherited; // important to forward messages do default handlers end;
LM_USER+2 n'est jamais appelé car la form et la frame non pas le même handle, et c'est la frame qui reçois le message
cf :
Code:

1 2 3 4 5 6 7 8 procedure TFrame1.MessageReceiver(var msg: TLMessage); begin // http://www.swissdelphicenter.ch/de/showcode.php?id=163 with Msg do begin Edit1.Text := IntToStr(Msg) + ' '+ IntToStr(WParam) + ' '+ IntToStr(LParam); ShowMessage('In The frame ' + intToStr(WParam) +' '+ intToStr(LParam)); end; end;
Ici :
Code:

1 2 // pas vu de diff // aText: string = 'This is a message';
Paf dans les dents, un bon gros SIGSEGV

Dans :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 procedure TFrame1.Button1Click(Sender: TObject); var aMess: TLMessage; begin //ExecOnEvent('petit test from ' + Self.Name); // "... from FrameTest", yaisse ! with TLMessage(aMess) do begin Msg := LM_USER+1; WParam := length(aText); LParam := integer(pchar(aText)); end; Parent.Perform(aMess.Msg, aMess.WParam, aMess.LParam); //PostMessage(Parent.Handle,aMess.Msg, aMess.WParam, aMess.LParam); end;
Idem SIGSEGV et idem avec postmessage
"fpc_pchar_to_ansistr ......"

Alors me dis vus que je suis en 64bit je change LParam := integer(pchar(aText)); par Int64
Et la miracle ton exemple marche nickel (avec postmessage aussi:zoubi:)

Tout fonctionne, je comprend pas ou çela te bloque maintenant ? (un peu fatigué aussi a cette heure :aie:)

Bonne fin de soirée

15/10/2016, 09h20
Jipété

Bonjour,

Citation:

Envoyé par BeanzMaster

Bonsoir, encore un sujet bien intéressant et de quoi se faire encore plus de cheveux blanc.

Grand merci pour cette petite phrase¹ que je prends comme un compliment (sauf pour les cheveux blancs, mais les miens ne veulent pas sortir, ouf :mrgreen:)

Citation:

Envoyé par BeanzMaster

Alors me dis vu que je suis en 64bit je change LParam := integer(pchar(aText)); par Int64
Et là miracle ton exemple marche nickel (avec postmessage aussi :zoubi:)

Grand bravo pour cette trouvaille qu'il va falloir que j'intègre avec des {$IFDEF ...} sans doute mais je ne sais pas encore comment...

Citation:

Envoyé par BeanzMaster

Tout fonctionne, je comprend pas où çela te bloque maintenant ? (un peu fatigué aussi à cette heure :aie:)

Grand point d'interrogation dans ma tête car, comme je le disais à anapurna, j'ai abandonné sa combine d'events pour me tourner vers la mienne que je maîtrise beaucoup mieux, et rien ne me bloque.
Le zip est là juste parce qu'il me l'a demandé, pour essayer de trouver là où je coinçais dans mes essais avec sa manière de faire.
Mais ma manière fonctionne, alors tout va bien -- et en plus le soleil est revenu :ccool:

Bonne journée bon week-end,
---
¹ : si le sujet t'intéresse, j'ai posé là une question assez générique concernant la gestion des messages, et j'ai peur de ne pas avoir beaucoup de réponses... N'hésite pas à aller jeter un œil.

Salut JP.

Citation:

j'ai posé là une question assez générique...

Je vais te répondre ici (ou tenter de te répondre) pour donner un exemple sous Lazarus.

Prenons un message système généré par le bouton gauche de la souris : WM_LBUTTONDOWN.
Il y a plusieurs façons de l'intercepter :
1) dans la procédure WndProc
2) dans une procédure qui ne gère que ce message
3) pour nous faciliter la vie, dans l'événement OnMouseDown (événement déclenché par la réception du message).

C'est en fait l'ordre dans lequel le message est réceptionné. Bien évidemment, on n'utilisera qu'une méthode, c'est juste pour s'assurer de l'ordre.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 private procedure OnLeftButton(var Message: TMessage); message WM_LBUTTONDOWN; protected procedure WndProc(var Message: TMessage); override; //... procedure TForm1.WndProc(var Message: TMessage); begin if Message.Msg = WM_LBUTTONDOWN then ListBox1.Items.Add('wndproc'); inherited; // OBLIGATOIRE end; procedure TForm1.OnLeftButton(var Message: TMessage); // procédure spécifique au message begin ListBox1.Items.Add('procédure OnLeftButton'); inherited; // FACULTATIF end; procedure TForm1.FormMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer); // événement OnMouseDown de Form1 begin if Button = mbLeft then ListBox1.Items.Add('event'); end;
Bouton gauche sur la fiche.
Dans le ListBox :
WndProc
puis procédure OnLeftButton
puis event.

C'est la procédure WndProc qui est chargée de la réception des messages.
Comme le message y est mentionné, il y a traitement.
Le inherited placé après va déclencher la suite du traitement du message dans la procédure spécifique. Mais comme cette procédure mentionne aussi inherited, le traitement va encore se poursuivre dans l'événement !
Si j'enlève l'inherited (facultatif) dans la procédure OnLeftButton, l'événement ne sera pas appelé.
Par contre, inherited est absolument OBLIGATOIRE dans la procédure WndProc. Si il est en début de procédure, c'est d'abord le traitement spécifique qui va s'exécuter.
Dans le ListBox :
procédure OnLeftButton
puis event
puis WndProc.

Donc si tu traites un message dans la procédure WndProc, voici ce que je préconise grandement :
Code:

1 2 3 4 5 6 7 8 procedure TForm1.WndProc(var Message: TMessage); begin if Message.Msg = WM_LBUTTONDOWN then ListBox1.Items.Add('wndproc') // message système else if Message.Msg = MYMESSAGE then ListBox1.Items.Add('wndproc mymessage') // message user else inherited; end;
Pour les messages user, je préfère utiliser une procédure spécifique (question de goût).

Remarque : la procédure DefaultHandler n'est appelée que lorsqu'il n'y a pas de traitement prévu pour le message. Ainsi, pas d'appel pour le message système, mais appel pour le message user.
Code:

1 2 3 4 5 6 procedure TForm1.DefaultHandler(var Msg); begin if TMessage(Msg).Msg = WM_LBUTTONDOWN then ListBox1.Items.Add('defaulthandler'); if TMessage(Msg).Msg = MYMESSAGE then ListBox1.Items.Add('defaulthandler mymessage'); inherited; end;
Je ne sais pas si j'ai été très clair, alors n'hésite pas...

Amicalement
Thierry

Salut Thierry,
Citation:
Envoyé par ThWilliam
Remarque : la procédure DefaultHandler n'est appelée que lorsqu'il n'y a pas de traitement prévu pour le message. Ainsi, pas d'appel pour le message système, mais appel pour le message user.
Code:

1 2 3 4 5 6 procedure TForm1.DefaultHandler(var Msg); begin if TMessage(Msg).Msg = WM_LBUTTONDOWN then ListBox1.Items.Add('defaulthandler'); if TMessage(Msg).Msg = MYMESSAGE then ListBox1.Items.Add('defaulthandler mymessage'); inherited; end;
Je ne sais pas si j'ai été très clair, alors n'hésite pas...
Très clair à 99 % ! :ccool:
Le pourcent restant concerne ce que j'ai cité, et particulièrement la présence de ce inherited dans cette procédure censée ne travailler (d'après ce que tu écris en haut de citation et que j'ai mis en gras) que sur les message user.
En toute logique ce inherited ne va rien transmettre puisque tout aura été géré avant, ou alors je n'ai rien compris ?

18/10/2016, 19h50
tourlourou

En toute logique, il ne traitera rien.
Mais si on dérive une fiche d'une autre, son inherited appellera le DefaultHandler de l'ancêtre.
On peut considérer que c'est une bonne pratique de mettre inherited, qu'il serve ou pas, à condition de ne pas le mettre s'il ne fallait pas (cad si on doit remplacer complètement le comportement ancestral dans un descendant, et ne pas le déclencher) : si on ajoute un comportement, il intervient après ou avant le traitement ancestral, selon la position du inherited. Si on veut zapper un comportement, il faut ignorer celui de l'ancêtre, donc omettre le inherited).
19/10/2016, 15h08
ThWilliam
Salut tourlourou.

Tu as raison, inherited n'est pas obligatoire dans la procédure DefaultHandler.

Salut JP.

Petites précisions :
je n'ai jamais dit que DefaultHandler ne travaillait que sur les messages user. Tu as des messages système qui n'ont pas de traitement défini. Par exemple, des messages comme WM_NCHITTEST, WM_NOTIFY aboutissent à DefaultHandler, tandis que des messages comme WM_SIZE, WM_LBUTTONDOWN disposent de leur traitement (réception du message par le composant qui le "traduit" en événement (OnResize, OnMouseDown...).

Pour l'envoi d'un message, si on utilise Perform ou SendMessage (PostMessage) : le message est toujours analysé en premier lieu dans la procédure WndProc.
Par contre, si on utilise Dispatch, c'est la procédure DefaultHandler qui est directement appelée. Exemple :
Code:

1 2 3 4 5 6 7 8 procedure TForm1.Button1Click(Sender: TObject); var Msg: TMessage; begin Msg.msg:= MYMESSAGE; Msg.wParam:= 123; Form1.Dispatch(Msg); end;
Je n'utiliserais la méthode Dispatch que pour les messages user.

Amicalement
Thierry
19/10/2016, 17h27
Jipété

Citation:

Envoyé par ThWilliam

[...]Pour l'envoi d'un message, si on utilise Perform ou SendMessage (PostMessage) : le message est toujours analysé en premier lieu dans la procédure WndProc.
Par contre, si on utilise Dispatch, c'est la procédure DefaultHandler qui est directement appelée.

OK, mais dans mon cas à moi (communication inter-onglets d'un PageControl) à base de L(W)_USER(ou _APP, on en cause dans Delphi), qu'est-ce qu'il me faut utiliser pour être le plus performant tout en étant le moins impactant sur le système ?

Fuseau horaire GMT +2. Il est actuellement 22h04.