Controle Souris sur n'importe quelle application

Bonjour,

> Je souhaiterais r�aliser une gestion automatique de la souris (et plus tard du clavier). C'est � dire que c'est le programme lui-m�me, par l'interm�diaire de la souris, qui cliquerais sur les icones du bureau, sur des �l�ments interactifs dans le navigateur web, ouvrirais des applications ... sans les connaitre vraiment (je veux parler des HANDLEs des applications).
> C'est en fait comme le programme VNC.

J'ai de r�elles probl�mes avec les clicks : "mouse_event()" ou "SendInput()" !

Les clicks g�n�r�s ne font pas le poids face � un vrai click utilisateur !
De plus, si je simule une s�rie de clicks (par l'entremise d'une touche clavier), des clicks "syst�me" donc, il ne me les prend pas ; il faut alors que je clique moi-m�me avec la souris pour restaurer un "�tat" normal des choses et pour que les clicks simul�s re-fonctionne ... bref, c'est pas la joie !

On dirais que mouse_event() perd windows rapidement.

J'avais tent� aussi SendMessage() mais pas de r�ponse lors des tests !
Ayant regard� un bout de code des sources VNC (compliqu�es!!) :
- on dirais qu'il utilise SendMessage().

Pouvez-vous m'apporter des pistes, du moins, pour que je puisse �muler parfaitement des clicks jusqu'� en simuler en rafale sans perdre Windows au passage ! ...

J'ai regard� et longuement �tudi� le tutoriel ("simuler le clavier et la souris") qui se trouve sur ce site (ce qui m'a fourni un bon d�part car j'�tais parti sur le sujet du "Hooking clavier" ! ...) et aussi la documentation de Microsoft sur le sujet mais je retombe sur les m�mes cas de clicks simul�s qui "marchottent" ... quand ca veux.

Merci de vos apports !
S�bastien.

V�rifiez avec Spy++ les messages envoy�s aux fen�tres durant une session interactive et essayez d'avoir exactement la m�me dynamique dans votre simulation.
Moi j' n'aurais utilis� que des "SendMessageTimeout".

Les messages ne suffisent pas: il y a des choses qui ne se traduisent pas par un message, notamment pour le clavier: un WM_KEYDOWN ne change pas le statut de la touche.

Normalement, SendInput() est le plus bas niveau: �a simule un clic en un point de l'�cran, ou une touche press�e. Mais s'il y a un utilisateur loggu� sur la m�me session, �a ne fera pas bon m�nage...

Les messages sont des informations de bien plus bas niveau que l'API SendInput.
En claire, SendInput utilise PostMessage qui lui-m�me utilise les files de messages.
Quand on touche au clavier et � la souris, vous verez, gr�ce � Spy++, qu'il y bien plus que "WM_KEYDOWN" qui est envoy�. N'oubliez pas que chaque message est accompagne d'un ensemble de structures contenant des param�tres et des contextes.
SendInput est tellement bas niveau qu'il y a des interf�rence savec l'activit� de l'utilisateur interactif, c'est plut�t la preuve du contraire, il est d�pendant d'un ensemble de fonctionnalit� de bas niveau qui font l'assertion que le thread devant g�rer les entr�es est celui qui a cr�e la fen�tre qui a le focus.

Donc l'insiste, utilisez Spy++ pour avoir des indice sur le probl�me, pas pour s'en servir comme API.

Citation:

---

Envoy� par bacelar

Les messages sont des informations de bien plus bas niveau que l'API SendInput.

---

Perdu, les messages sont de bien plus HAUT niveau que SendInput(). Pour preuve, Windows sait d�j� � quelle fen�tre envoyer le message. Rien de tout �a avec SendInput(), qui simule une entr�e � bas niveau. Le traitement de cette entr�e � bas niveau par les couches sup�rieures entrainera l'envoi des messages et les mises � jour du keyboard state.

Edit: Euh, une minute: Dans une phrase de ton message tu dis une chose, puis dans tout le reste tu dis son contraire ? 8O

Enfin, en effet, SendInput() suppose qu'il n'y a pas un aga�ant utilisateur pour jouer avec le clavier et la souris. Par contre, je n'ai jamais assez bien compris les Desktops et Window Stations pour savoir si le fait d'ex�cuter les deux programmes dans un autre Desktop permet d'�viter une interf�rence de l'utilisateur...

SendInput -> Module gestion des p�riph�riques d'entr�e -> module de gestion des fen�tres -> envoye de messages au thread de la fen�ter ayant le focus -> bubbling du message vers les threads des fen�tres parentes si n�cessaire.

PostrMessage -> module de gestion des fen�tres -> envoie de messages au thread ayant cr�e une fen�tre sp�cifi�.

Je crois bien qu'au niveau du nombre d'interm�daire, je gagne haut la main.

J'adore le passage "entr�e � bas niveau par les couches sup�rieures" ;-)). A bas niveau, on passe pas par les couches sup�rieur, mais avec des donn�es brutes ont doit passer par les couches sup�rieurs pour les raffiner. "Brutes" pas "Bas Niveau", ou alors bas niveau d'ABSTRACTION.

Bon, c'est pas �a qui va aider cyber_N.

cyber_N, avez-vous vu, avec Spy++, des diff�rences entre VNC et votre programme ?

Citation:

---

Envoy� par M�dinoc

Le traitement de cette entr�e � bas niveau par les couches sup�rieures

---

Ce sont les couches sup�rieures qui traitent l'entr�e, pas l'entr�e qui entre par elles... :roll: Et c'est l'entr�e qui est � bas niveau, pas le traitement.
En gros:
couchesSup�rieures.Traitement(entr�e�BasNiveau). C'est plus compr�hensible comme �a ?


Quant au "nombre de niveaux interm�diaires", je n'en ai jamais parl�. Ton diagramme, je le vois plut�t comme �a:

Code:

---

1 2 3 4 5 6 7

Module de gestion des fen�tres DefWindowProc:Remont�e au parent ^ \ ^ / v / Module d'entr�e PostMessage(fen�tre focus) ^ / SendInput()

---

Ou � la rigueur comme �a:

Code:

---

1 2 3 4

SendInput() Module de gestion des fen�tres DefWindowProc:Remont�e au parent \ ^ \ ^ v / v / Module d'entr�e PostMessage(fen�tre focus)

---

L'entr�e est bien envoy�e aux couches basses (module de gestion des p�riph�riques d'entr�e), et ce sont bien les couches hautes (module de gestion des fen�tres) qui transmettent � la bonne fen�tre...

Et j'en profite: http://blogs.msdn.com/oldnewthing/ar...30/423202.aspx

couchesSup�rieures.Traitement(entr�eBrute).
Nous sommes donc d'accord ?

Pour comparer VNC et votre solution, je pense que M�dinoc est d'accord avec moi pour dire que seul Spy++ et non un hook sur le clavier et la souris ou une interception par r��criture de IAT est viable.

Comme, avec Spy++, nous somme proche de la destination, et non de la source, on peut comparer VNC et votre solution sans assertion sur l'impl�mentation de VNC.

Avec les diff�rences entre les messages produits par VNC et par votre programme, on aura des billes pour rechercher le probl�me.
Je n'ai pas dis que LA solution �tait postMessage mais que les messages donneraient des r�ponses.

Le probl�me, qui est mentionn� dans mon lien, c'est que les messages ne mettent pas � jour le Keyboard state de l'application. Cela est fait autrement, d'une mani�re interne indisponible pour l'utilisateur (et pour spy++!)...

Tu sais, j'ai essay� de jouer avec les messages. Je n'ai jamais r�ussi � envoyer automatiquement une lettre majuscule avec �a...