Bonjour,

Existe-il dans l'API Windows la fonction contraire de
GetWindowThreadProcessId

--

Dominique

je ne comprends pas la question:

The GetWindowThreadProcessId function retrieves the identifier of the
thread that created the specified window and, optionally, the identifier
of the process that created the window.

l'inverse n'a pas de sens puisqu'une application ou un thread petu avoir
créé plein de fenêtres différentes.

> je ne comprends pas la question:
>
> The GetWindowThreadProcessId function retrieves the identifier of the thread
> that created the specified window and, optionally, the identifier of the
> process that created the window.
>
> l'inverse n'a pas de sens puisqu'une application ou un thread petu avoir créé
> plein de fenêtres différentes.

Je cherche à fermer proprement une application à partir d'une autre
appli, en envoyant un message WM_QUIT.
Je ne dispose que du nom du module. Avec CreateTool32Snapshot et
Process32First je trouve bien trace de mon application à fermer. Mais
comment faire après pour obtenir un handle à utiliser dans le
sendmessage ?

Merci d'avance

--

Dominique

Tu peux passer par EnumWindows. sinon je ne vois pas trop...

TedIF a écrit :
>> je ne comprends pas la question:
>>
>> The GetWindowThreadProcessId function retrieves the identifier of the
>> thread that created the specified window and, optionally, the
>> identifier of the process that created the window.
>>
>> l'inverse n'a pas de sens puisqu'une application ou un thread petu
>> avoir créé plein de fenêtres différentes.
>
> Je cherche à fermer proprement une application à partir d'une autre
> appli, en envoyant un message WM_QUIT.
> Je ne dispose que du nom du module. Avec CreateTool32Snapshot et
> Process32First je trouve bien trace de mon application à fermer. Mais
> comment faire après pour obtenir un handle à utiliser dans le sendmessage ?
>
> Merci d'avance
>

J'ai eu le même problème, en pire car l'application à surveiller était un .bat
qui (entre autre) lançait un fichier make.exe qui lançait successivement toutes
les commandes décrites par un fichier de construction.

Je n'ai à l'époque pas trouvé de solution fiable, et reste intéressé !
(je m'y remettrai surement un jour dans le siècle qui vient)

"TedIF" <TedIf@TedIF.fr> a écrit dans le message de news:
mn.4be77d7a6b49e9c8.65892@TedIF.fr...
> Bonjour,
>
> Existe-il dans l'API Windows la fonction contraire de
> GetWindowThreadProcessId
>
> --
>
> Dominique
>
Salut,
Je n'ai pas la réponse exact, mais quelques pistes :
Il faut que tu connaisses le type de la forme principal de ton autre appli,
tu dois pouvoir le trouver avec winsight utilitaire livré avec Delphi.
Ensuite il existe une fonction de l'api qui avec le type de la fenêtre
principal te permet de retrouver le processid.
La vacherie avec les appli Delphi, c'est qu'elles créés deux fenêtres au
démarrage dont une invisible.

Bon courage.



Raphaël Vivien

> "TedIF" <TedIf@TedIF.fr> a écrit dans le message de news:
> mn.4be77d7a6b49e9c8.65892@TedIF.fr...
>> Bonjour,
> Je n'ai pas la réponse exact, mais quelques pistes :
> Il faut que tu connaisses le type de la forme principal de ton autre appli,
> tu dois pouvoir le trouver avec winsight utilitaire livré avec Delphi.
> Ensuite il existe une fonction de l'api qui avec le type de la fenêtre
> principal te permet de retrouver le processid.
> La vacherie avec les appli Delphi, c'est qu'elles créés deux fenêtres au
> démarrage dont une invisible.
>
Le problème c'est que Winsight livré avec Rad Studio 2007 ne fonctionne
pas sur ma machine et j'ai désinstallé D7.

--

Dominique

Tu télécharges le GrizzlyPack et tu vois ce qu'il y-a dans l'unité
GzProcessUtils. Il y a des trucs pour faire ce que tu souhaites... Si mes
souvenirs sont bons. Ca devrait pouvoir te servir de source d'inspiration.

TedIF <TedIf@TedIF.fr>
::: "TedIF" <TedIf@TedIF.fr> a écrit dans le message de news:
::: mn.4be77d7a6b49e9c8.65892@TedIF.fr...
:::: Bonjour,
::: Je n'ai pas la réponse exact, mais quelques pistes :
::: Il faut que tu connaisses le type de la forme principal de ton
::: autre appli, tu dois pouvoir le trouver avec winsight utilitaire
::: livré avec Delphi. Ensuite il existe une fonction de l'api qui avec
::: le type de la fenêtre principal te permet de retrouver le processid.
::: La vacherie avec les appli Delphi, c'est qu'elles créés deux
::: fenêtres au démarrage dont une invisible.
:::
:: Le problème c'est que Winsight livré avec Rad Studio 2007 ne
:: fonctionne pas sur ma machine et j'ai désinstallé D7.
::
:: --
::
:: Dominique

procedure GetProcessWindowList(AProcessId : DWord; AList : TStrings);
var
LeHWnd : HWnd;
szTitre : Array[0..255] of Char;
AP2 : DWord;
begin
AList.Clear;
LeHWnd:=GetWindow(GetDesktopWindow,GW_CHILD);
LeHWnd:=GetWindow(LeHWnd,GW_HWNDFIRST);
while LeHWnd<>0 do
begin
GetWindowText(LeHWnd,szTitre,255);
GetWindowThreadProcessId(LeHWnd, @AP2);
if (AP2=AProcessId) and (AP2<>0) and (StrLen(szTitre)>0) then
AList.AddObject(StrPas(szTitre),Pointer(LeHWnd));
LeHWnd:=GetWindow(LeHWnd,GW_HWNDNEXT);
end;
end;


TedIF <TedIf@TedIF.fr>
::: "TedIF" <TedIf@TedIF.fr> a écrit dans le message de news:
::: mn.4be77d7a6b49e9c8.65892@TedIF.fr...
:::: Bonjour,
::: Je n'ai pas la réponse exact, mais quelques pistes :
::: Il faut que tu connaisses le type de la forme principal de ton
::: autre appli, tu dois pouvoir le trouver avec winsight utilitaire
::: livré avec Delphi. Ensuite il existe une fonction de l'api qui avec
::: le type de la fenêtre principal te permet de retrouver le processid.
::: La vacherie avec les appli Delphi, c'est qu'elles créés deux
::: fenêtres au démarrage dont une invisible.
:::
:: Le problème c'est que Winsight livré avec Rad Studio 2007 ne
:: fonctionne pas sur ma machine et j'ai désinstallé D7.
::
:: --
::
:: Dominique

> J'ai eu le même problème, en pire car l'application à surveiller était un
..bat
> qui (entre autre) lançait un fichier make.exe qui lançait successivement
toutes
> les commandes décrites par un fichier de construction.
> Je n'ai à l'époque pas trouvé de solution fiable, et reste intéressé !

Pourtant il y a moyen. Chaque processus garde quelque part la trace de son
"parent". Donc il est théoriquement possible de remonter les processus fils
jusqu'à trouver le processus initial, celui lancé par explorer.

--
francois.piette@overbyte.be
Auteur du freeware ICS - Internet Component Suite
Auteur du freeware MidWare - Multi-tiers framework
http://www.overbyte.be
http://francois-piette.blogspot.com

> procedure GetProcessWindowList(AProcessId : DWord; AList : TStrings);
> var
> LeHWnd : HWnd;
> szTitre : Array[0..255] of Char;
> AP2 : DWord;
> begin
> AList.Clear;
> LeHWnd:=GetWindow(GetDesktopWindow,GW_CHILD);
> LeHWnd:=GetWindow(LeHWnd,GW_HWNDFIRST);
> while LeHWnd<>0 do
> begin
> GetWindowText(LeHWnd,szTitre,255);
> GetWindowThreadProcessId(LeHWnd, @AP2);
> if (AP2=AProcessId) and (AP2<>0) and (StrLen(szTitre)>0) then
> AList.AddObject(StrPas(szTitre),Pointer(LeHWnd));
> LeHWnd:=GetWindow(LeHWnd,GW_HWNDNEXT);
> end;
> end;
>
>
Merci bien

--

Dominique

>>
> Salut,
> Je n'ai pas la réponse exact, mais quelques pistes :
> Il faut que tu connaisses le type de la forme principal de ton autre appli,
> tu dois pouvoir le trouver avec winsight utilitaire livré avec Delphi.
> Ensuite il existe une fonction de l'api qui avec le type de la fenêtre
> principal te permet de retrouver le processid.
> La vacherie avec les appli Delphi, c'est qu'elles créés deux fenêtres au
> démarrage dont une invisible.
>
> Bon courage.
>
>
>
> Raphaël Vivien

Merci bien

--

Dominique

Francois Piette a écrit :
>> J'ai eu le même problème, en pire car l'application à surveiller était un
> .bat
>> qui (entre autre) lançait un fichier make.exe qui lançait successivement
> toutes
>> les commandes décrites par un fichier de construction.
>> Je n'ai à l'époque pas trouvé de solution fiable, et reste intéressé !
>
> Pourtant il y a moyen. Chaque processus garde quelque part la trace de son
> "parent". Donc il est théoriquement possible de remonter les processus fils
> jusqu'à trouver le processus initial, celui lancé par explorer.
>

Le but était de fournir un menu "outil" paramétrable, avec une option (checkbox)
pour n'autoriser qu'une seule instance de l'outil, par exemple pour un module de
comm qui réserve ses ressources i/o, auquel cas il fallait juste remettre en
avant-plan l'instance déjà lancée.

A l'époque (et de mémoire, ça date un peu), je n'ai pas réussi à trouver une
info qui identifie de façon bijective une applic.

Il me semble que j'avais cherché à récupérer le chemin de l'exe, mais que les
infos que j'avais réussi à récupérer changeaient selon l'origine du lancement :
directement par l'exe ou par un raccourci (lnk) ou par .bat

La difficulté vient du fait que l'outil a pu être lancé auparavant et/ou en
dehors du contrôle de mon programme, en particulier par un bat ou un lnk.

Bref, j'ai capitulé et laissé l'utilisateur se débrouiller s'il ouvre 2 fois la
même applic.

Mais ça me titille encore la glande de la programmation, de temps en temps.
:-)

>
> Le but était de fournir un menu "outil" paramétrable, avec une option
> (checkbox) pour n'autoriser qu'une seule instance de l'outil, par exemple
> pour un module de comm qui réserve ses ressources i/o, auquel cas il fallait
> juste remettre en avant-plan l'instance déjà lancée.
>
> A l'époque (et de mémoire, ça date un peu), je n'ai pas réussi à trouver une
> info qui identifie de façon bijective une applic.
>
> Il me semble que j'avais cherché à récupérer le chemin de l'exe, mais que les
> infos que j'avais réussi à récupérer changeaient selon l'origine du lancement :
> directement par l'exe ou par un raccourci (lnk) ou par .bat
>
> La difficulté vient du fait que l'outil a pu être lancé auparavant et/ou en
> dehors du contrôle de mon programme, en particulier par un bat ou un lnk.
>
> Bref, j'ai capitulé et laissé l'utilisateur se débrouiller s'il ouvre 2 fois
> la même applic.
>
> Mais ça me titille encore la glande de la programmation, de temps en temps.
> :-)

Et quelque chose comme ceci ne suffit pas ?

//----------------------------------------------------------------------
function VerifExeTourne(const FileName: string): Boolean;
//----------------------------------------------------------------------
var
ContinueLoop : Boolean;
FSnapshotHandle: THandle;
FProcessEntry32: TProcessEntry32;
ProcName : string;
PathProcName : string;
begin

Result := False;
FSnapshotHandle := CreateTool32Snapshot(TH32CS_SNAPPROCESS, 0);
FProcessEntry32.dwSize := Sizeof(FProcessEntry32);
ContinueLoop := Process32First(FSnapshotHandle,FProcessEntry32);

while Integer(ContinueLoop) <> 0 do
begin
ProcName :=
UpperCase(ExtractFileName(FProcessEntry32.szExeFil e));
PathProcName := UpperCase(FProcessEntry32.szExeFile);

if (ProcName = UpperCase(FileName))
or (PathProcName = UpperCase(FileName)) then
begin
Result := True;
end;
ContinueLoop := Process32Next(FSnapshotHandle,FProcessEntry32);
end;
CloseHandle(FSnapshotHandle);

end;
//----------------------------------------------------------------------

--

Dominique

TedIF a écrit :
> [...]
> Et quelque chose comme ceci ne suffit pas ?
[...]

Je ne sais pas... Tout ce dont je me souvient c'est d'avoir pagaillé (trop)
longtemps avec toujours des cafouillages et d'avoir lu des tonnes de pages du SDK.
Je testerai ca la semaine prochaine, là je suis trop à la bourre.
Merci d'avance (on ne sait jamais !)