2010-03-03 3 views
0

Tout d'abord des informations générales ...Sont physiques et programmatiques pressions sur les touches traitées différemment par .NET ou soit le système d'exploitation

J'ai un C# .NET qui fonctionne sur un PC en ardoise dire pas de clavier physique. Nous utilisons le clavier à l'écran intégré dans Windows XP Tablet édition pour remplir les contrôles TextBox sur un formulaire. Il n'y a pas de manipulation de touche spéciale pour le formulaire (bien que d'autres composants de l'interface utilisateur traitent les touches).

Il arrive que le clavier à l'écran arrête d'enregistrer certaines touches. Le formulaire a toujours le focus et le curseur reste dans la zone de texte. Si vous appuyez plusieurs fois sur une touche, le caractère sera éventuellement affiché. Notre application utilise un certain nombre de threads de traitement occupé, mais il est loin d'utiliser 100% du processeur. Lorsque ce problème se produit, il reste ainsi jusqu'à ce que notre application soit redémarrée, après quoi le clavier se comporte normalement. Le problème ne se produit pas du tout lorsqu'un clavier USB est connecté et utilisé pour l'entrée.

Je m'intéresse aux différences entre les touches physiques et programmatiques? Est-ce que les touches programmatiques génèrent des interruptions matérielles comme le ferait un clavier physique? Est-ce que .NET pourrait gérer chaque type différemment?

Toutes les suggestions qui pourraient aider à déboguer le problème seraient grandement appréciées!

Répondre

0

Je n'ai jamais travaillé avec la version tablette de XP OSK, mais j'ai utilisé la version XP Embedded. Autant que je puisse dire que l'API Windows envoyait des pressions sur les applications .NET et MFC de la même manière. En fait, si je me souviens bien, il n'y avait aucun moyen de faire la différence entre les deux par programme. Autant que je sache, un OSK ne causera pas d'interruption matérielle, cependant le code de la clé virtuelle sera envoyé aux programmes au niveau de l'application exactement de la même manière qu'un code physique.

Sauf si vous exécutez un pilote personnalisé ou quelque chose (qui a accès à la couche matérielle), il semble que ce ne soit pas votre application qui cause le problème.

Si ce n'est pas déjà fait, je vérifierais que l'écran tactile possède les derniers pilotes et qu'il est correctement calibré. Je vérifie également que l'OSK a toutes les dernières mises à jour de Microsoft.

Questions connexes