Dans .NET CF 2.0, un hook de clavier global interférera-t-il avec P/Invoke nécessitant une pression sur une touche?

Question

Mes données: appareil mobile personnalisé exécutant Windows CE 4.2, Compact Framework 2.0 SP1. C# application faisant un usage décent de P/Invoke sans problèmes jusqu'à présent.

J'ai écrit un hook pour clavier de bas niveau (similaire à, mais pas identique à, this CodeProject post) qui fonctionne à merveille à une exception près. Une chose que notre logiciel fait est de permettre l'accès à la fonctionnalité de calibrage d'écran de Windows CE; C'est l'écran sur lequel vous devez appuyer sur une série de cibles, enfin appuyer sur Esc pour annuler ou sur Enter pour accepter. Nous appelons cette fonctionnalité via a P/Invoke, et je pense que la touche qui se produit dans cette fonction de l'API Win32 est interférée par mon crochet de clavier.

Mon crochet de clavier ne fait rien d'intensif, et ne change pas le flux d'exécution, mais je pense que l'utilisation des deux peut être fondamentalement incompatible. Lorsque je quitte le débogueur après l'exécution de cet écran, toutes les touches Entrée enfoncent que j'ai tenté de tout "frapper" à la fois (cet appareil fait un bruit de frappe clicky) lorsque le programme se ferme. Cela me fait penser que le crochet ne transmet pas correctement la touche dans la fonction API Win32 comme il le fait correctement à une application .NET. Des pensées?

Pensez-vous que:
a) crochets de clavier et d'un clavier nécessitant P/Invoque sont incompatibles, ou
b) ma mise en œuvre du crochet du clavier est à blâmer, ou
c) dépend-elle du tout sur le fabricant du matériel, les pilotes, etc?

Merci pour votre aide!

Answer 1

a) Non, ils sont entièrement compatibles. L'accrochage au clavier se fait au niveau du noyau, de sorte que tout ce qui utilise un message du clavier le traverse, qu'il provienne du code natif ou du code managé.

b) Difficile à dire puisque nous ne pouvons pas voir votre implémentation

c) Il est possible (tout ce qui est depuis à peu près tout dans C'est OEM modifiable), mais pas très probable. La plupart des équipementiers ne font pas grand-chose avec GWES (ce qui est le cas) parce que cela fonctionne hors de la boîte.

Maintenant le morceau spécifique que vous regardez est d'un appel à TouchCalibrate, correct? Le meilleur pari ici est de regarder spécifiquement le code source TouchCalibrate - il est livré avec Platform Builder (y compris la version eval). Je pense que c'est "intercepter" ou au moins empêcher les messages d'être expédiés. Cela faisait un moment que j'étais là-bas, et en faisant un pilote de panneau tactile, je ne regardais pas beaucoup la manipulation du clavier, mais ce qu'il fait, c'est de passer le contrôle au sous-système GWES pour voir les points bruts de l'écran tactile il ne fonctionne pas une application Windows. Il est donc probable que la pompe de message de l'application, qui gère l'envoi de ces touches, ne fasse rien (un peu comme lorsque vous lancez une boîte de dialogue modale).

J'ai vraiment besoin d'une meilleure explication de ce qui se passe exactement. Vous dites "lorsque vous quittez le débogueur après avoir exécuté cet écran" mais je ne comprends pas ce que cela signifie. Vous voulez dire que vous appelez TouchCalibrate dans le code, puis arrêtez le débogage et que les messages sont envoyés, ou sont-ils envoyés une fois que l'écran TouchCalibrate se ferme? Remote Spy ++ ou Kernel Tracker peut également donner un aperçu de ce qui se passe.