Discussion :

[Robxley]

Dans mon programme j'ai besoin d'envoyer des saisies claviers&souris virtuelles à notepad.

Dans une premier approche cela fonctionne, mais que lorsque je ramène notepad au premier plan. Voici le morceau code de mon application concernée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
        HWND idWindow = FindWindow("notepad","test1.txt - Bloc-notes"); //récupère le handle de la fenêtre concernée
	if( idWindow != NULL) //si elle existe
	{
		cout<< "Fenetre trouvée" <<endl;
		SwitchToThisWindow(idWindow,0); //la rend active
		SendInput(1, &npt, sizeof(INPUT)); //envoie la touche souhaitée
        }

Donc j'aimerai éviter de devoir toujours remettre le notepad en premier plan, et de pouvoir continuer à lui envoyer des instructions en le laissant en arrière plan et même lorsqu'il est réduit si possible

Alors j'ai essayé un SetFocus(idWindow) au lieu de SwitchToThisWindow(idWindow,0); mais sans succès rien ne se passe.

J'ai pensée à relever le handle de la fenêtre courante (avec GetForegroundWindow) pour lui redonner la main ensuite, mais les animations fenêtre n'étant pas instantané c'est pas très fonctionnel surtout quand plusieurs envoie à intervalle régulier sont effectué.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
        HWND idWindow = FindWindow("notepad","test1.txt - Bloc-notes"); //récupère le handle de la fenêtre concernée
	if( idWindow != NULL) //si elle existe
	{
                
		cout<< "Fenetre trouvée" <<endl;
                HWND currentWindow = GetForegroundWindow(); //sauvegarde de l'application courante
		SwitchToThisWindow(idWindow,0); //rend actif notepad
		SendInput(1, &npt, sizeof(INPUT)); //envoie la touche souhaité

                SwitchToThisWindow(currentWindow ,0); //rend la main à l'application courante
        }

Est - ce que quelqu'un aurait une solution qui permettrait d'envoyer évènements claviers à une application sans pour autant devoir la ramener au premier plan.

[minnesota]

Salut,

Est - ce que quelqu'un aurait une solution qui permettrait d'envoyer évènements claviers à une application sans pour autant devoir la ramener au premier plan.

Oui, des messages du type WM_KEYDOWN/WM_KEYUP ou WM_CHAR ... transmis par une fonction comme PostMessage() peuvent faire l'affaire.

[Robxley]

Oui effectivement c'est ce que j'ai pu trouvé sur le net. Merci pour ta réponse Minnesota.

Bien que je n'ai pas très bien compris la différence entre la fonction

PostMessage() et SendMessage().

Seul différence que j'ai pu constater après plusieurs tests c'est que les WM_CHAR ne marchent qu'avec les SendMessage. Enfin pour ce que je voulais en faire ça fonctionne.

Mais bon, si quelqu'un a une explication entre la différence PostMessage et SendMessage je suis preneur, je suis pas trop fan de marcher à l'aveugle.

Ce que j'ai pu en lire sur MSDN c'est que contrairement à PostMessage, SendMessage attend un "accusé réception" de fin d'exécution de procédure du message avant de rendre la main. Mais bon en aucun cas il n'est expliqué pourquoi WM_CHAR ne marche pas avec ce dernier.

[Melem]

SendMessage appelle directement la procédure de fenêtre (et attend donc la fin du traitement), tout comme DispatchMessage, qui soumet un message à la procédure de fenêtre qui lui va. PostMessage ne fait que placer ("poster") un message dans la queue des messages - le message ne sera traité qu'après qu'il aura été retiré de la queue, par GetMessage par exemple, pour être soumis à la procédure de fenêtre qui lui va. Il est possible que Windows sache vérifier "l'authenticité" d'un WM_CHAR, c'est-à-dire vérifier s'il y avait réellement un WM_KEYDOWN correspondant avant, au moment du GetMessage ou du TranslateMessage par exemple. Dans ce cas, PostMessage(... WCHAR ...) n'aura que peu de chances de fonctionner. Avec SendMessage, tu ne fais qu'appeler la WndProc, donc rien de mal si tu sais ce que tu fais.

[minnesota]

En production, il faut éviter l'usage de SendMessage et préférer SendMessageTimeout, ceci pour ne pas avoir un état bloquant. Sinon, pour utiliser le couple PostMessage()/WM_CHAR, sauf erreur, c'est la zone d'édition qu'il faut cibler (par son "handle") et non sa fenêtre parent.

Cordialement.

[Robxley]

Merci pour toutes ces réponses.
J'y vois un peu plus claire parmi toutes ces fonctions.

Effectivement j'étais pas fan de SendMessage qui provoquait un état bloquant.

minnesota, comme tu l'as fait remarquer effectivement je sélection le champ "Edit" du note pad avec un FindWindowEx si non sans ça, ca ne fonctionne pas.

Tout fonction nickel chrome.
Merci pour votre aide.

Je poste le résultat de mon code si ca peut servir à quelqu'un autre.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

         HWND idWinPad = FindWindow("notepad",NULL);
         if(idWinPad)
	   cout<< "Fenetre trouvee" <<endl;
        else cout<<"Erreur Fenetre non trouvee"<<endl;

        HWND idEdit = FindWindowEx(idWinPad , NULL, "Edit" , NULL );
	if( idEdit != NULL)
	{
		cout<< "Edit trouvee" <<endl;
		
                 PostString(idEdit ,"test si marche");  //simulation de touche correspondant à une chaine de caractère
                 PostMessage(idEdit ,WM_KEYDOWN,VK_SPACE,0);	
		//PostMessage(idEdit ,WM_KEYUP,VK_SPACE,0);	

	}