Discussion :

[exe2bin]

Bonjour à tous,
j'ai un ptit bonhomme appelé joe qui se balade dans une fenêtre grâce aux touches fléchées du clavier; l'étape suivante consiste à balader joe sur l'écran entier !
Problème : Comment gérer le déplacement de joe avec le clavier puisque il n'existe pas de fenêtre associée qui reçoit les messages ?
Alors j'ai pensé aux" Hooks" permettant le "crochetage" des messages!!
Malheureusement , ce qui me semblait évident -- création du hook avec
SetWindowsHookEx() ,gestion des messages clavier dans la procédure de hook --- ne l'ai en fait pas du tout ; en bref je n'ai visiblement rien pigé !!
De plus , la littérature sur le sujet est assez absconse et peu claire .
Quelqu'un aurait-il un conseil où un exemple BIEN précis sur le sujet ?
merci.

[Andnotor]

La méthode à privilégier serait Raw Input. Les hooks sont de moins en moins apprécié. Un exemple en Delphi ici.

Par hook, il faut déjà distinguer les deux types : standard, bas niveau.

Standard:
Enregistré par WH_KEYBOARD. Le hook doit obligatoirement être dans une DLL qui sera injectée dans chaque processus.

Avantages :

• rapidité ;
• en cas de problème dans le hook, seul le processus impliqué risque le deadlock.

Inconvénient :

• le partage des données, surtout depuis l'arrivée de l'UAC et du niveau d'intégrité.

Bas niveau (Low Level):
Enregistré par WH_KEYBOARD_LL. Le hook peut être indifféremment dans l'exe ou une DLL (même si la littérature voudrait qu'il soit aussi dans une DLL). Il y a commutation de processus ; le code sera toujours exécuté dans celui de ton application.

Avantages :

• exe sans dll ;
• un seul espace mémoire, donc partage des données facilité ;

Inconvénients :

• plus lent dû à la commutation ;
• risque de deadlock du système complet (XP) ;
• depuis Vista, déchargement du hook par le système en cas de problème ou de traitement trop long (évite le deadlock) mais sans aucune forme de notification !

Dans les deux cas, le traitement du hook doit être le plus rapide possible sous peine de ralentir le système. Les mieux est d'uniquement filtrer les messages et de renvoyer les informations intéressantes par PostMessage. En Delphi, quelque chose comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
function KeyBoardLLProc(Code: integer; wParam: WPARAM; lParam: LPARAM):LRESULT; stdcall;
begin
  if (Code >= HC_ACTION) then
  begin
    if MesConditions then
    begin
      PostMessage(MaFenêtre, MonMessage, 0, 0);
    end;
  end;

  Result := CallNextHookEx(0, Code, wParam, lParam);
end;

[exe2bin]

Merci pour ta réponse.
Une précision toutefois : dans cette application il n'y a pas de fenêtre et encore moins de procédure de fenêtre ,pourquoi faire d'ailleurs puisque l'affichage doit se faire sur l'écran du bureau ?
Ensuite ,est-il obligatoire de poster un message à la procédure de fenêtre dans le hook ?!
De même est-il nécessaire d'appeler CallNextHook() ?
Tu l'auras compris je débute en programmation ; ce qui me faudrait c'est un bon tuto là-dessus .

[Andnotor]

La fenêtre peut très bien être "message-only" (sans visuel).
Non, il n'est pas obligatoire de passer par un PostMessage mais comme je te l'ai dit, le traitement du hook doit être le plus rapide possible. En envoyant un message asynchrone, il est immédiatement libéré. Ton application elle, peut prendre son temps

CallNextHookEx est obligatoire à moins que tu veuilles "manger" le message. Les hooks installés sont chaînés et c'est cette fonction qui appelle le hook suivant.

Tu as pourtant ici des exemples complets. Si tu disais plutôt ce qui se passe, ça nous aiderait
ps: à noter que ces exemples sont plutôt ancien. Le premier paramètre de CallNextHookEx peut être fixé à 0.

[Mat.M]

Problème : Comment gérer le déplacement de joe avec le clavier puisque il n'existe pas de fenêtre associée qui reçoit les messages ?
A

en programmation Windows et dans tous les langages il y a toujours une fenêtre associée qui reçoit les messages.
Ou alors c'est un programme console

[moldavi]

Bonjour.

Je n'ai pas testé ce programme, mais il semble récupérer les évènements clavier. Et ni sans hook, ni sans fenêtre :

http://tcharles.developpez.com/simul/

Code C :

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
18
19
20
21
22
23
24
25
 
#include <windows.h>
int main(int argc, char *argv[])
{
     POINT pt;
     BOOL bContinue = TRUE;
     const SHORT Mask = 32768;
     while (bContinue)
     {
          if (GetKeyState(VK_ESCAPE) & Mask)
               bContinue = FALSE;
          GetCursorPos(&pt);
          if (GetKeyState(VK_UP) & Mask)
               pt.y -= 1;
          if (GetKeyState(VK_DOWN) & Mask)
               pt.y += 1;
          if (GetKeyState(VK_LEFT) & Mask)
               pt.x -= 1;
          if (GetKeyState(VK_RIGHT) & Mask)
               pt.x += 1;
          SetCursorPos(pt.x,pt.y);
          Sleep(10);
     }
     return 0;
}

Après, il est certainement nécessaire que ce programme nécessite d'avoir le focus, c'est-à-dire que s'il est en arrière-plan cela ne marche pas. J'imagine que GetKeyState ne fonctionne que pour l'application qui est en premier plan.

Un article en .net sur le hook :

http://humann.developpez.com/hook/

Un autre en C/C++ :

http://www.developpez.net/forums/d17...vier-sans-dll/

[Andnotor]

Je n'ai pas testé ce programme, mais il semble récupérer les évènements clavier. Et ni sans hook, ni sans fenêtre

Non seulement le faire avec une boucle est très très laid mais il y a surtout beaucoup de chance pour que tu loupes des états

c'est-à-dire que s'il est en arrière-plan cela ne marche pas

Si, si. ça fonctionne.

[Médinoc]

Avec GetKeyState(), ça fonctionne? Ça m'étonne, vu qu'il me semblait que GetKeyState() c'est l'état du clavier tel que transmis à la fenêtre... (par opposition à GetAsyncKeyState(), qui lit directement l'état global du clavier)

[Andnotor]

Disons que l'état est correct (stable) jusqu'à ce que le message ait été traité par l'application cible. C'est sûr qu'il est préférable d'utiliser GetAsyncKeyState depuis une application tiers.
Par contre le bit Toggle est conservé.