API win32 et gestion d'applications (background/foreground)
5 réponses
Altaïr
Bonjour =E0 tous,
je d=E9veloppe actuellement une application en C (avec Labwindows CVI
pour =EAtre pr=E9cis).
Avec cette premi=E8re application, je lance une seconde qui est d=E9j=E0
cod=E9e et que je ne peux pas modifier. Ces deux applications
communiquent entre elles grace =E0 des =E9changes TCP et jusque l=E0 tout va=
bien.
Je souhaiterais que la seconde application reste au premier plan
lorsque je le d=E9sire car pour le moment la premi=E8re application sur
laquelle l'utilisateur travaille prend sa place dans le foreground.
Je me suis renseign=E9 sur l'API win32 et j'ai appris =E0 cr=E9er des
fen=EAtres, =E0 y associer des controles et =E0 les faire passer au premier
plan. J'ai r=E9ussi en outre =E0 trouver le HWND et le HINSTANCE de la
seconde application mais l'utilisation des fonctions SetActiveWindow()
ou SetForegroundWindow() ne sont pas concluantes. L'application reste
au second plan.
Est-il possible d'ins=E9rer ma deuxi=E8me application dans une fen=EAtre
cr=E9=E9e par la premi=E8re application afin de pouvoir g=E9rer le foregroun=
d
gr=E2ce aux deux fonctions =E9voqu=E9es pr=E9c=E9demment?
Si non, auriez vous une solution en t=EAte ou d'autres fonctions de
l'API pouvant m'aider?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Christian ASTOR
On 22 avr, 10:48, Altaïr wrote:
Je me suis renseigné sur l'API win32 et j'ai appris à créer des fenêtres, à y associer des controles et à les faire passer au premie r plan. J'ai réussi en outre à trouver le HWND et le HINSTANCE de la seconde application mais l'utilisation des fonctions SetActiveWindow() ou SetForegroundWindow() ne sont pas concluantes. L'application reste au second plan.
SetForegroundWindow() a des limitations à contourner (KB97925 : AttachThreadInput(), SPI_SETFOREGROUNDLOCKTIMEOUT) Sinon, SwitchToThisWindow() marche généralement.
On 22 avr, 10:48, Altaïr <altair_...@hotmail.com> wrote:
Je me suis renseigné sur l'API win32 et j'ai appris à créer des
fenêtres, à y associer des controles et à les faire passer au premie r
plan. J'ai réussi en outre à trouver le HWND et le HINSTANCE de la
seconde application mais l'utilisation des fonctions SetActiveWindow()
ou SetForegroundWindow() ne sont pas concluantes. L'application reste
au second plan.
SetForegroundWindow() a des limitations à contourner (KB97925 :
AttachThreadInput(), SPI_SETFOREGROUNDLOCKTIMEOUT)
Sinon, SwitchToThisWindow() marche généralement.
Je me suis renseigné sur l'API win32 et j'ai appris à créer des fenêtres, à y associer des controles et à les faire passer au premie r plan. J'ai réussi en outre à trouver le HWND et le HINSTANCE de la seconde application mais l'utilisation des fonctions SetActiveWindow() ou SetForegroundWindow() ne sont pas concluantes. L'application reste au second plan.
SetForegroundWindow() a des limitations à contourner (KB97925 : AttachThreadInput(), SPI_SETFOREGROUNDLOCKTIMEOUT) Sinon, SwitchToThisWindow() marche généralement.
Altaïr
> SetForegroundWindow() a des limitations à contourner (KB97925 : AttachThreadInput(), SPI_SETFOREGROUNDLOCKTIMEOUT) Sinon, SwitchToThisWindow() marche généralement.
Merci pour ta réponse Christian.
A propos de AttachThreadInput(): Jusqu'à présent j'obtenais le HWND de la seconde application à son lancement par une fonction Labwindows. Mais je me suis rendu compte qu'en appliquant GetWindowThreadProcessId() avec cette valeur, j'obtenais le même Id que pour ma première application...
J'ai donc du mal à obtenir la liste des threads composants ma seconde application. Avec cette liste je pourrais réaliser un SetForegroundWindow() sur chacune des fenêtres composant les threads (ce que je sais faire).
> SetForegroundWindow() a des limitations à contourner (KB97925 :
AttachThreadInput(), SPI_SETFOREGROUNDLOCKTIMEOUT)
Sinon, SwitchToThisWindow() marche généralement.
Merci pour ta réponse Christian.
A propos de AttachThreadInput():
Jusqu'à présent j'obtenais le HWND de la seconde application à son
lancement par une fonction Labwindows. Mais je me suis rendu compte
qu'en appliquant GetWindowThreadProcessId() avec cette valeur,
j'obtenais le même Id que pour ma première application...
J'ai donc du mal à obtenir la liste des threads composants ma seconde
application. Avec cette liste je pourrais réaliser un
SetForegroundWindow() sur chacune des fenêtres composant les threads
(ce que je sais faire).
> SetForegroundWindow() a des limitations à contourner (KB97925 : AttachThreadInput(), SPI_SETFOREGROUNDLOCKTIMEOUT) Sinon, SwitchToThisWindow() marche généralement.
Merci pour ta réponse Christian.
A propos de AttachThreadInput(): Jusqu'à présent j'obtenais le HWND de la seconde application à son lancement par une fonction Labwindows. Mais je me suis rendu compte qu'en appliquant GetWindowThreadProcessId() avec cette valeur, j'obtenais le même Id que pour ma première application...
J'ai donc du mal à obtenir la liste des threads composants ma seconde application. Avec cette liste je pourrais réaliser un SetForegroundWindow() sur chacune des fenêtres composant les threads (ce que je sais faire).
Altaïr
> J'ai donc du mal à obtenir la liste des threads composants ma seconde application. Avec cette liste je pourrais réaliser un SetForegroundWindow() sur chacune des fenêtres composant les threads (ce que je sais faire).
J'arrive désormais à lister tous les threads et identifier leur windows respectives. Il me reste désormais à pouvoir identifier les threads qui correspondent à ma seconde application... Si quelqu'un a une idée...
Merci.
> J'ai donc du mal à obtenir la liste des threads composants ma seconde
application. Avec cette liste je pourrais réaliser un
SetForegroundWindow() sur chacune des fenêtres composant les threads
(ce que je sais faire).
J'arrive désormais à lister tous les threads et identifier leur
windows respectives. Il me reste désormais à pouvoir identifier les
threads qui correspondent à ma seconde application... Si quelqu'un a
une idée...
> J'ai donc du mal à obtenir la liste des threads composants ma seconde application. Avec cette liste je pourrais réaliser un SetForegroundWindow() sur chacune des fenêtres composant les threads (ce que je sais faire).
J'arrive désormais à lister tous les threads et identifier leur windows respectives. Il me reste désormais à pouvoir identifier les threads qui correspondent à ma seconde application... Si quelqu'un a une idée...
Merci.
Christian ASTOR
On 22 avr, 18:36, Altaïr wrote:
> SetForegroundWindow() a des limitations à contourner (KB97925 : > AttachThreadInput(), SPI_SETFOREGROUNDLOCKTIMEOUT) > Sinon, SwitchToThisWindow() marche généralement.
Merci pour ta réponse Christian.
A propos de AttachThreadInput(): Jusqu'à présent j'obtenais le HWND de la seconde application à son lancement par une fonction Labwindows. Mais je me suis rendu compte qu'en appliquant GetWindowThreadProcessId() avec cette valeur, j'obtenais le même Id que pour ma première application...
J'ai du mal à comprendre... Si je lance une autre appli, comme Notepad par ex : ShellExecute(NULL, "", "notepad", "", "", SW_SHOW);
Et si je fais : HWND hWndNotepad = FindWindow("Notepad",NULL ); DWORD dwProcessID; DWORD dwThreadId = GetWindowThreadProcessId(hWndNotepad, &dwProcessID);
dwThreadId ne peut pas être égal à GetCurrentThreadId()
Si on veut mettre au premier plan Notepad, on peut faire :
On 22 avr, 18:36, Altaïr <altair_...@hotmail.com> wrote:
> SetForegroundWindow() a des limitations à contourner (KB97925 :
> AttachThreadInput(), SPI_SETFOREGROUNDLOCKTIMEOUT)
> Sinon, SwitchToThisWindow() marche généralement.
Merci pour ta réponse Christian.
A propos de AttachThreadInput():
Jusqu'à présent j'obtenais le HWND de la seconde application à son
lancement par une fonction Labwindows. Mais je me suis rendu compte
qu'en appliquant GetWindowThreadProcessId() avec cette valeur,
j'obtenais le même Id que pour ma première application...
J'ai du mal à comprendre...
Si je lance une autre appli, comme Notepad par ex :
ShellExecute(NULL, "", "notepad", "", "", SW_SHOW);
Et si je fais :
HWND hWndNotepad = FindWindow("Notepad",NULL );
DWORD dwProcessID;
DWORD dwThreadId = GetWindowThreadProcessId(hWndNotepad,
&dwProcessID);
dwThreadId ne peut pas être égal à GetCurrentThreadId()
Si on veut mettre au premier plan Notepad, on peut faire :
> SetForegroundWindow() a des limitations à contourner (KB97925 : > AttachThreadInput(), SPI_SETFOREGROUNDLOCKTIMEOUT) > Sinon, SwitchToThisWindow() marche généralement.
Merci pour ta réponse Christian.
A propos de AttachThreadInput(): Jusqu'à présent j'obtenais le HWND de la seconde application à son lancement par une fonction Labwindows. Mais je me suis rendu compte qu'en appliquant GetWindowThreadProcessId() avec cette valeur, j'obtenais le même Id que pour ma première application...
J'ai du mal à comprendre... Si je lance une autre appli, comme Notepad par ex : ShellExecute(NULL, "", "notepad", "", "", SW_SHOW);
Et si je fais : HWND hWndNotepad = FindWindow("Notepad",NULL ); DWORD dwProcessID; DWORD dwThreadId = GetWindowThreadProcessId(hWndNotepad, &dwProcessID);
dwThreadId ne peut pas être égal à GetCurrentThreadId()
Si on veut mettre au premier plan Notepad, on peut faire :
Merci. J'ai finalement réussi avec une méthode assez "buldozer". J'aurais du utiliser ShellExecute et FindWindows pour obtenir le handle de la fenêtre. La complication venait du fait que j'utilisais des fonctions CVI pour lancer l'application et la fermer.
Merci beaucoup pour ce code.
Merci. J'ai finalement réussi avec une méthode assez "buldozer".
J'aurais du utiliser ShellExecute et FindWindows pour obtenir le
handle de la fenêtre. La complication venait du fait que j'utilisais
des fonctions CVI pour lancer l'application et la fermer.
Merci. J'ai finalement réussi avec une méthode assez "buldozer". J'aurais du utiliser ShellExecute et FindWindows pour obtenir le handle de la fenêtre. La complication venait du fait que j'utilisais des fonctions CVI pour lancer l'application et la fermer.