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

Version imprimable

Voir 40 message(s) de cette discussion en une page

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 ?

Voir 40 message(s) de cette discussion en une page