SendMessage et THandle non correct

Bonjour,
Je suis devant la situation suivante: j'ai plusieurs instances de mon application ( en ligne de commande ) sur des sessions différentes sur ma machines.
Exemple : Session de l'administrateur (utilisateur courant) : MonProg.exe -T -H
Session de Client1 (en mode déconnecté) : MonProg -T -D -S
Session de Client2 (en mode déconnecté) : MonProg -F -R -D -A
Le but est de créer une application qui permet de transporter des données entre ces différentes instances de programmes lancés.
L'idée est de récupérer le PID de chaque nom de l'image (exécutable) afin de pouvoir effectuer un traitement sur ce dernier selon le contenu du paquet de données envoyés.
Tout va bien jusqu'à un SendMessage qui ne fonctionne pas avec le PID mais avec le THandle, donc il a fallu trouver le bon handle du process en question. Exemple

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

procedure TForm4.Button2Click(Sender: TObject); var packet: TDataTraites; CopyDataStruct:TCopyDataStruct; vyPid: string; h: THandle; begin vyPid := ListView1.Selected.SubItems[0]; packet.Type:=0; packet.Champs:='CLOSE'; packet.Valeur:='32767'; packet.Table:=55; CopyDataStruct.dwData:=1; // Optionnel CopyDataStruct.cbData:=SizeOf(packet); CopyDataStruct.lpData:=@packet; h := FindWindow(pchar('TFMain'), nil); SendMessage(h, WM_COPYDATA, application.Handle, LongInt(@CopyDataStruct)); end;

---

Jusqu'ici tout est bon, mais, voilà, le FindWindow peut faire l'affaire si une seule instance de mon programme est lancée mais il ne fera pas l'affaire si :
- plusieurs instance de mon programmes sont lancées sur la session en cours.
- Si une ou plusieurs instances sont lancées sur des sessions déconnectés du Client1 ou bien le Client2.
Mon but est de pouvoir envoyer mon paquet de données à des instances selon le PID de chaque instance.
J'ai essayé avec le OpenProcess

Code:

---

1 2	h := OpenProcess(PROCESS_QUERY_INFORMATION or PROCESS_VM_READ, False, StrToInt(myPid));

---

Mais ça ne fonctionne pas, le but étant de récupérer le bon Handle sur la base du PID du process à traiter.
Alors, ma question est :
- Est ce que le SendMessage peut se faire sur un processus inter-session ?
- Si c'est faisable alors, comment récupérer le bon handle (qui sert pour le SendMessage) selon le PID du process qu'on veut traiter ?

Merci d'avance.

Citation:

---

Envoyé par Moez.B

Est ce que le SendMessage peut se faire sur un processus inter-session ?

---

Non, il faut utiliser d'autres formes d'IPC comme des Named Pipes mais ça entraîne pas mal de boulot.

Dans la session en cours, tu peux passer par EnumWindows et ensuite contrôler que cette fenêtre appartient à un certain processus par GetWindowThreadProcessId.
Tu pourrais même imaginer ajouter une propriété à tes fenêtres par SetProp contenant le PID pour éviter l'appel à GetWindowThreadProcessId.

Salut
J'ai lancé mon programme dans la session courante à travers le planificateur de tâches : l'option que j'ai choisi est : "Exécuter même si aucun utilisateur n'a ouvert de session".
Lorsque j'ai cette tâche qui est lancée, je la vois dans la liste des process actif et je récupère son PID.
Je veux créer un SendMessage basique entre ce mon programme de commande et l'application qui est en arrière plan.
Si je lance ce bout de code sur mon application en avant plan (lancée manuellement), le SendMessage est réussi :

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

function TForm4.GetHWndByPID(const hPID: THandle): THandle; type PEnumInfo = ^TEnumInfo; TEnumInfo = record ProcessID: DWORD; HWND: THandle; end;   function EnumWindowsProc(Wnd: DWORD; var EI: TEnumInfo): Bool; stdcall; var PID: DWORD; begin GetWindowThreadProcessID(Wnd, @PID); Result := (PID <> EI.ProcessID) or (not IsWindowVisible(WND)) or (not IsWindowEnabled(WND));   if not Result then EI.HWND := WND; //break on return FALSE end;   function FindMainWindow(PID: DWORD): DWORD; var EI: TEnumInfo; begin EI.ProcessID := PID; EI.HWND := 0; EnumWindows(@EnumWindowsProc, Integer(@EI)); Result := EI.HWND; end;   begin if hPID<>0 then Result:=FindMainWindow(hPID) else Result:=0; end;   procedure TForm4.Button5Click(Sender: TObject); var myPid: string; h: THandle; begin myPid := ListView1.Selected.SubItems[0]; h := GetHWndByPID (StrToInt(myPid)); SendMessage(h, WM_CLOSE, application.Handle, 0); end;

---

Mais si l'application est lancée via le planificateur de tâches (et donc elle est en arrière plan), le retour de de mon GetHWndByPID est toujours 0.
Je crois que c'est tout à fait normal car je suis entrain d'utiliser EnumWindowsProc qui cherche le MainWindow via le PID de l'application. Alors, évidement si l'application est arrière plan, la fenêtre principale est caché et je ne peux pas récupérer son Handle.
Ce que je souhaite faire c'est de pouvoir échanger des messages entre mon application (que ce soit en arrière plan ou bien en avant plan) sur la session courante active ou bien sur des sessions déconnectées d'autres utilisateurs de la même machine.
Est ce que un Process Windows en arrière plan ne peut pas recevoir les messages (WM_CLOSE, WM_COPYDATA ...) ?
Merci d'avance

Affiche la colonne ID de session dans le gestionnaire des tâches. Si l'ID est différent de la session courante, SendMessage ne peut pas marcher.

Bonjour, :P

Merci pour la réponse.

Évidement, les échanges des messages Windows ne peuvent se faire qu'avec entre session et même avec les communications inter-processus, il faut échanger des messages avec des fenêtres visibles et actives de d'une session autre que celle courante.
J'ai reprise le code de François Piette :
http://francois-piette.blogspot.com/...ing-pipes.html
et apparemment, il faut que les IsWindowVisible et IsWindowEnabled sont vérifiées pour qu'un SafeSendMessage puisse se faire :

Extrait du code de l'unité Pipes.pas du composant IPC de François Piette :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

function TPipeThread.SafeSendMessage(AMsg : UINT; AWParam : WPARAM; ALParam : LPARAM): LRESULT; begin // Check notification window if IsWindow(FNotify) then // Send the message Result := SendMessage(FNotify, AMsg, AWParam, ALParam) else // Failure Result := 0; end;

---

Si le Handle du Window à notifier n'est pas valide alors l'envoi du message ne sera pas fait.

Bonne journée:P

Une fenêtre n'a pas besoin d'être visible et encore moins active pour recevoir des messages, il faut juste qu'elle possède une boucle de messages. Il est même très fréquent de créer des fenêtres message-only sans aucune partie graphique.

Quant à cette exemple, il ne devrait pas être utilisé dans une communication inter-process. IsWindow contrôle simplement que le handle soit valide mais rien ne dit que le processus qui a servi à déterminer FNotify soit toujours en cours et s'il ne l'est plus, que le handle n'a pas déjà été réutilisé par une autre application. Le message risque d'être envoyé à la mauvaise fenêtre. Mieux vaut passer par un FindWindow avant SendMessage ;)

Le MSDN met d'ailleurs en garde sur l'utilisation de IsWindow entre threads. Dans une même application, les risques sont limités mais il faut y penser.

Bonjour,
Dans une session courante, on peut lancer une application en mode normal en avant plan comme on peut la lancer en arrière plan avec les tâches planifiées.
Si elle est lancée en mode utilisateur déconnecté ( ce qui est mon cas ) , mon application est dans le gestionnaire de tâche comme étant un processus actif mais il n'y a rien comme fenêtre active ( pas de fenêtre principale ni de traitement lancé vu par l'utilisateur ) . Comment alors récupérer le bon THandle de mon TMainForm par exemple lorsque cette dernière est en arrière plan ?
Si j'arrive à le trouver, je peux donc échanger un message avec ce TMainForm via le SendMessage, non ? :koi:
Merci d'avance.

Je ne suis même pas encore assez précis lorsque je parle de sessions, les messages Windows ne peuvent être échangés que par des applications s'exécutant sur le même bureau. En lançant la tâche avec l'option Exécuter même si aucun utilisateur n'a ouvert de session, cette application est exécutée dans la session 0 (dédiée aux services) dans laquelle est créé un nouvel environnement sécurisé (Windows Station) ;)

Un petite essai pour s'en convaincre. Ce code renvoie l'identificateur de session, le Window Station et le desktop. Si une seule donnée diffère, pas de dialogue par message possible:

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

function GetObjectName(aHandle :THandle) :string; var Len :cardinal; begin if aHandle <> 0 then begin GetUserObjectInformation(aHandle, UOI_NAME, nil, 0, Len); SetLength(Result, Len div SizeOf(Char) -1); GetUserObjectInformation(aHandle, UOI_NAME, PChar(Result), Len, Len); end else Result := '?'; end;   procedure TForm1.FormCreate(Sender: TObject); var s :TStringList; SessionID :cardinal; const FileName = 'D:\Temp\ProcessInfo.txt'; begin s := TStringList.Create;   try ProcessIdToSessionId(GetCurrentProcessID, SessionID);   s.Add('Session ID: ' +IntToStr(SessionID)); s.Add('Window Station: ' +GetObjectName(GetProcessWindowStation)); s.Add('Desktop name: ' +GetObjectName(GetThreadDesktop(GetCurrentThreadId)));   s.SaveToFile(FileName); finally s.Free; end; end;

---

Citation:

---

Envoyé par Andnotor

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

function GetObjectName(aHandle :THandle) :string; var Len :cardinal; begin if aHandle <> 0 then begin GetUserObjectInformation(aHandle, UOI_NAME, nil, 0, Len); SetLength(Result, Len div SizeOf(Char) -1); GetUserObjectInformation(aHandle, UOI_NAME, PChar(Result), Len, Len); end else Result := '?'; end;   procedure TForm1.FormCreate(Sender: TObject); var s :TStringList; SessionID :cardinal; const FileName = 'D:\Temp\ProcessInfo.txt'; begin s := TStringList.Create;   try ProcessIdToSessionId(GetCurrentProcessID, SessionID);   s.Add('Session ID: ' +IntToStr(SessionID)); s.Add('Window Station: ' +GetObjectName(GetProcessWindowStation)); s.Add('Desktop name: ' +GetObjectName(GetThreadDesktop(GetCurrentThreadId)));   s.SaveToFile(FileName); finally s.Free; end; end;

---

---

Salut,
J'ai copié/collé cette source , j'ai comme informations dans le fichier ProcessInfo.txt

• Session ID: 0
• Window Station: WinSta0
• Desktop name: Default

Mais la Session ID est (via le gestionnaire de tâches) est par exemple 3.
Je n'ai pas trop saisi les valeurs de retours du code car tout se joue sur la valeur du PID du process actuel (par GetCurrentProcessID) donc normalement, je dois avoir 3 comme Session ID :koi:
Merci

C'est que tu as lancer plusieurs fois le programme depuis des sessions différentes et écrasé le fichier :aie:

Lance-le une fois depuis ton bureau et regarde ce que ça donne. Puis lance-le une fois par tâche planifiée et regarde encore (quitte à tuer la tâche par le gestionnaire entre chaque essai, ça évitera les quiproquos) ou encore mieux, renomme aléatoirement ce fichier.
Tu es manifestement sous XP, une interaction pourrait être possible avec le premier utilisateur (pas les suivants) mais à oublier depuis Vista. Tu devrais vraiment oublier ces messages et passer par une autre forme d'IPC.

Citation:

---

Envoyé par Andnotor

C'est que tu as lancer plusieurs fois le programme depuis des sessions différentes et écrasé le fichier :aie:.

---

Je l'ai lancé une plusieurs fois mais dans la session "Administrateur" actuelle.

Citation:

---

Envoyé par Andnotor

Lance-le une fois depuis ton bureau et regarde ce que ça donne.

---

j'ai mis l'exe généré sur le bureau, j'ai lancé pour voir, ça donne toujours : Session ID: 0; Window Station: WinSta0; Desktop name: Default :?

Citation:

---

Envoyé par Andnotor

Puis lance-le une fois par tâche planifiée et regarde encore (quitte à tuer la tâche par le gestionnaire entre chaque essai, ça évitera les quiproquos) ou encore mieux, renomme aléatoirement ce fichier.

---

ça donne toujours les mêmes résultats dans le fichier de sortie. :roll:

Citation:

---

Envoyé par Andnotor

Tu es manifestement sous XP, une interaction pourrait être possible avec le premier utilisateur (pas les suivants) mais à oublier depuis Vista. Tu devrais vraiment oublier ces messages et passer par une autre forme d'IPC.

---

:kiss: c'est la solution idéale : en faite, j'ai repris les composants que François Piette a créé à la base de l'unité Pipes.pas qui a été créée pour la première fois par Russell Libby en 2003. (Lien: http://francois-piette.blogspot.com/...ing-pipes.html). L'avantage de ces composants, c'est que je vais utiliser directement des méthodes du serveur pour se connecter et envoyer des messages à un/plusieurs clients. Pour le moment, ce message est un Stream et donc je récupère des entêtes de types chaînes. Après je vais essayer de voir si je peux échanger d'autres types de messages ( pourquoi pas des booléens dont j'ai absolument besoin ). 8-)