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...