Discussion :

[racine carrée]

Bonsoir à tous,
j'ai cherché longuement sur la manière d'envoyer des messages à une fenêtre qui n'est pas au premier plan, et j'ai beaucoup de mal à comprendre pourquoi certains codes marchent et d'autres non:
Ce code censé simuler l'appui de la combinaison ctrl+P sur une fenêtre dont on a au préalable récupéré le handle, ne fonctionne pas:

Code :

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

1
2
3
4
     PostMessage(fenetre,WM_KEYDOWN,VK_CONTROL,0);
     PostMessage(fenetre,WM_KEYDOWN,'P',0);
     PostMessage(fenetre,WM_KEYUP,'P',0);
     PostMessage(fenetre,WM_KEYUP,VK_CONTROL,0);

Pourtant ce code fonctionne:

Code :

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

1
2
     PostMessage(fenetre,WM_KEYDOWN,VK_SPACE,0);
     PostMessage(fenetre,WM_KEYUP,VK_SPACE,0);

(ce dernier fonctionne sur certains programme, mais pas sur le bloc notes, ce qui est encore plus bizarre...)
Donc si quelqu'un peut m'éclairer (surtout sur la simulation de combinaison de touches sur une fenêtre qui n'est pas au premier plan),
je le remercie d'avance.

[bacelar]

Ce que vous tentez de faire avec ces appels, c'est de "truander" le programme cible.
Le programme cible n'est pas obligé de se faire "avoir" par votre "astuce".

Des programmes utilisant des API comme DirectInput ou autre n'utilisent pas du tout les messages "WM_KEYUP/WM_KEYDOWN", etc...

C'est quoi votre "vrai" besoin, à part "truander" ces pauvres programmes.

[foetus]

Ce que je soupçonne c'est que les touches ne sont pas combinées (<- *)

Parce que le comportement de Windows est

1) je reçois la touche CTRL (message WM_KEYDOWN) -> j'attends
2) je reçois la touche P (message WM_KEYDOWN) -> je combine les touches, j'envoie le message CTRL+P (message WM_CHAR)
3) la fenêtre reçoit le message CTRL+P

.... et ainsi de suite jusqu'aux messages WM_KEYUP

Mais en lisant stackoverflow , les messages CTRL+P ne contiennent pas forcément un code CTRL et un code P (<- Windows style)

Handling keyboard input in win32, WM_CHAR or WM_KEYDOWN/WM_KEYUP? (<- lien stackoverflow en anglais)

Apparently, windows works in really strange ways. [...] It seems that when you press [shift]+9, windows sends a VK_LEFT in the wParam of message WM_CHAR

* Édit : parce que la touche espace fonctionne pour un logiciel mais pas CTRL+P qui est la combinaison de 2 touches en 1 message

[bacelar]

Le "CTRL+P" n'est pas généré par Windows directement. C'est le "TranslateMessage" de votre application qui convertie les WM_KEYDOWN en WM_SYSKEYDOWN/WM_SYSCOMMAND.
Si votre application n'utilise pas de "TranslateMessage" pas de raccourci, pas de Print.

[racine carrée]

Bonsoir et merci pour ces réponses,
y a-t-il alors un moyen de simuler l'appui de touches sur une fênetre qui n'a pas le focus (équivalent de la fonction keybd_event pour une fenêtre visée en particulier, sans devoir la mettre au premier plan).
Sinon Bacelar, je n'ai pas trop compris ta dernière réponse; il faut convertir les WM_KEYDOWN en WM_SYSKEYDOWN/WM_SYSCOMMAND avec la fonction TranslateMessage? Mais comment ? il faudrait créer un objet de type MSG, exécuter la fonction translate dessus? mais comment faire si c'est bien cela qu'il faut faire?

[bacelar]

"keybd_event", c'est aussi une astuce.
Elle est plus bas niveau, donc plus de programme se font avoir.

il faut convertir les WM_KEYDOWN en WM_SYSKEYDOWN/WM_SYSCOMMAND avec la fonction TranslateMessage?

Non, c'est l'application que t'essaye de blouser qui fait son traitement pépère, généralement, en appelant la fonction "TranslateMessage" de Win32 pour convertir les WM_KEYDOWN en WM_CHAR.
Il suffit que l'application que t'essaye de blouser utilise une méthode de traitement qui ne fonctionne pas avec ton arnaque (comme GetAsyncKeyState https://docs.microsoft.com/en-us/win...tasynckeystate) pour que ta combine ne fonctionne pas.

C'est quoi votre "vrai" besoin, à part "truander" ces pauvres programmes.

(BIS)

[racine carrée]

Bonsoir,
Mon but est de comprendre mieux comment marchent les messages, et mon application pratique était de pouvoir mettre en pause le windows media player, mais je viens de trouver une solution plus efficace à cette application pratique en observant les messages de la fenêtre du lecteur dans spy++:

Code :

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

1
2
3
4
5
//UTILISER:
PostMessage(FindWindow("WMPlayerApp",0),WM_COMMAND,0x14978,0);
//AU LIEU DE:
PostMessage(FindWindow("WMPlayerApp",0),WM_KEYDOWN,VK_SPACE,0);
PostMessage(FindWindow("WMPlayerApp",0),WM_KEYUP,VK_SPACE,0);

(remarque: les codes 0x14978 et 0 pourraient peut-être être différent pour une autre version du lecteur de musique)
Mais ça n'empêche pas que si je peux trouver des informations plus précises sur les messages ça m'intéresse.

* Édit : parce que la touche espace fonctionne pour un logiciel mais pas CTRL+P qui est la combinaison de 2 touches en 1 message

Effectivement, ce doit être le problème.
Merci des réponses.

[foetus]

Mais ça n'empêche pas que si je peux trouver des informations plus précises sur les messages ça m'intéresse.

La référence c'est cette page A Key’s Odyssey ... par contre c'est long, tortueux (prévoir de l'aspirine ) et peut être daté/ obsolète


Édit: c'est spécifique à la bibliothèque VCL (Delphi/ C++), surcouche de la Win32, donc peut être HS.

[racine carrée]

Merci beaucoup,
je lirai ça quand j'en aurai le temps.

c'est long, tortueux (prévoir de l'aspirine )

... et surtout c'est de l'anglais !

[Médinoc]

La raison principale pour laquelle la méthode PostMessage() pour les touches ne marche pas, c'est que la gestion du Keyboard State en est indépendante.

keybd_event() et SendInput() génèrent des "vrais" appuis de touches, mais ne permettent pas de cibler une fenêtre: Tout part vers ce qui a le focus.

À ma connaissance, il n'existe pas de fonction cumulant les avantages des deux, et Microsoft ne semble pas avoir d'intention d'en ajouter une, vu que ce n'est pas comme ça qu'un programme est supposé être "automatisé" (supporter OLE Automation ou Active Accessibility, c'est ce qui est recommandé à la place).

Pour tout ce qui utilise directement l'API Win32 ou tout ce qui en est "assez" proche, un bon WM_COMMAND doit suffire pour la plupart des fonctionnalités. Mais on ne peut en dire autant de Windows Forms (qui ne semble pas permettre de spécifier un Control ID) ou d'un framework dit "windowless"...

[bacelar]

Pour le pilotage du Windows Media Player, il y a beaucoup beaucoup plus simple :
https://www.howtogeek.com/howto/1935...-media-player/
(Usage des "global hotkeys")

J'ai l'impression que vous subissez le syndrome du marteau de Maslow (quand on ne connait que le marteau, tous les problèmes ressemblent à des clous).

Comme l'indique @Médinoc, le hacking des touches claviers, et des messages Windows pour autre chose que leur fonction première (cf. WM_COPY et consort), c'est clairement de la bidouille que M$ n'encourage pas.
C'est déjà bien assez l'enfer pour la rétrocompatibilité avec les fonctionnalités qu'ils ont documentées, alors s'ils font l'erreur de simplifier ces immondes bidouilles, c'est la fin des haricots.

La référence de @foetus, c'est ce qui se passe DANS l'application, et chaque framework, VCL, MFC, .NET gère les messages de la file de message d'un thread graphique selon SA tambouille.

Résultat, des bidouilles qui fonctionnent avec des applications faites avec un framework ne fonctionneront pas forcement avec un programme écrit avec un autre framework. Et comme c'est une partie "user" du programme, les développeurs des applications sont tout à fait à même de changer le comportement du framework pour leurs besoins et donc une bidouille qui fonctionne avec un programme qui utilise un framework peut ne pas fonctionner sur un autre programme qui utilise le même framework.

En résumé, comme l'indique @Médinoc, utilisez les API de pilotage du programme que fournit le programme et arrêtez de tenter de le blouser.

L'usage du PostMessage avec un WM_COMMAND DOCUMENTE peut très bien servir d'API officiel, mais il faut que cela soit documenté. Sinon, à la prochaine version, voir à la prochaine mise à jour ou installation de plug-ins, vous l'aurez dans le baba.

Mais ça n'empêche pas que si je peux trouver des informations plus précises sur les messages ça m'intéresse.

Ce traitement des messages est en zone "user", chaque programmeur est libre dans faire ce qu'il veut.
Il peut utiliser des routines pré-construite par l'OS, comme DefWindowProc (https://docs.microsoft.com/en-us/win...defwindowproca), ou, plus couramment par une framework graphique (qui peut utiliser les routines de l'OS mais pas forcement, cf. les framework JAVA), MAIS le développeur est totalement libre de tout changer (ce que font bon nombre de "gros" programmes, comme Photoshop, etc...).

Ce qui est "constant" c'est ce qui se passe avant qu'un message provenant du système se retrouve dans la file de message d'un thread graphique.
- interruption matériel du périphérique ou du bus
- prise en charge par le driver matériel des informations à collecter sur le périphérique
- remonter dans la pile des drivers des informations avec transformation si nécessaire
- prise en charge d'évènements "Kernel" comme le Ctrl-Alt-Sup ou le "Alt-Tab" ou encore les "global hotkeys"
- passage de l'évènement à toutes les routines de "hooking système" enregistrées sur ce type d'évènement (si les routines de hooking sont bien programmées et foutent pas la grouille).
- dépôt dans la file de message d'un thread cible de l'évènement.
- passage de l'évènement à toutes les routines de "hooking utilisateur" enregistrées sur ce type d'évènement.

[racine carrée]

Merci beaucoup de ces réponses.
Ceci m'a bien éclairé sur la notion de messages dans Windows (même s'il me reste encore beaucoup de travail de compréhension et d'application à faire).