KeyboardProc qui renvoie TRUE entraîne une baisse des performances
https://stackoverflow.com/questions/1052992
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je développe une interface pour un add-on à un jeu. Je ne peux pas utiliser l'API de jeu (pour plusieurs raisons, notamment le fait que le code doit être indépendant du jeu) et je dois obtenir une saisie au clavier de l'utilisateur. J'ai donc décidé d'utiliser un hook pour clavier (WH_KEYBOARD) pour traiter l'utilisateur. saisie lorsque certaines conditions sont remplies.
Le problème est que, bien que je puisse recevoir et traiter correctement les entrées, mon hook renvoie TRUE au lieu de CallNextHookEx , le système semble prendre beaucoup de temps (bien plus de 800 ms) avant de laisser les choses se dérouler comme prévu et ce n'est pas acceptable car il ne permet même pas un typage fluide expérience.
Ce que je dois faire, c'est empêcher que le message clé de la presse parvienne au WndProc. La question est donc: que puis-je faire pour atteindre mon objectif sans nuire tellement aux performances du jeu que le résultat sera inacceptable?
EDIT: en raison d'exigences spécifiques (les jeux utilisant des anticheat qui pourraient créer des problèmes avec mon code bien qu'il ne soit pas lié à une tricherie), le sous-classement du wndproc actif n'est pas une option.
La solution 4
Bien que je n'aime pas répondre à ma propre question, j'ai trouvé la cause du retard. La pompe de messages des jeux pour lesquels j'ai testé mon code a été implémentée avec un moment (PeekMessage) {GetMessage ...} et la suppression du message d'entrée au clavier a provoqué le blocage de GetMessage pendant un certain temps. L'utilisation de PostMessage et de WM_NULL a permis d'éviter le blocage de GetMessage.
Autres conseils
-
Tout d'abord, vous avez besoin que votre DLL soit injectée dans le processus cible, soit par des hooks, soit par de toute autre manière .
-
Trouvez le descripteur de fenêtre qui vous intéresse.
-
Obtenez la procédure de fenêtre actuelle de cette fenêtre en appelant GetWindowLongPtr (wnd, GWLP_WNDPROC) et enregistrez-la.
-
Sous-classez la fenêtre en appelant SetWindowLongPtr (wnd, GWLP_WNDPROC, & et NewWndProc), où NewWndProc est votre procédure de message implémentée par DLL.
Dans NewWndProc, vous voudrez traiter les messages du clavier (vous en avez une douzaine, saisissez & "entrée au clavier &" dans l'index MSDN, je ne peux pas publier plus d'un lien). Pour le reste de Windows, appelez la procédure de fenêtre originale que vous avez enregistrée au cours de (3) et renvoyez la valeur renvoyée. Ne l'appelez pas directement, utilisez plutôt CallWindowProc.
Cette méthode n’est pas très fiable, certains logiciels antivirus et anti-robots (par exemple, & "; client de gardien &";) risquent de ne pas l’aimer et le débogage peut s'avérer difficile.
Cependant, cela devrait fonctionner.
Un crochet de clavier ne devrait pas ralentir les choses. Il y a probablement autre chose qui cause le délai de 800 ms. Est-il toujours lent si votre crochet ne fait rien et renvoie simplement TRUE?
Si vous souhaitez empêcher l'envoi d'un message au WndProc, vous devez créer une sous-classe avec SetWindowLong . Ainsi, vous pourrez intercepter tous les messages et décider de poursuivre ou non leur itinéraire.
