Alternative à SendKeys lors de l'exécution de Remote Desktop?

Question

J'ai une application qui injecte des frappes dans les applications via SendKeys.

Malheureusement, l'application ne fonctionnera pas lorsque je l'exécute via Remote Desktop en raison du problème bien connu que SendKeys ne fonctionne pas avec Remote Desktop.

Est-ce que quelqu'un a déjà résolu ce problème ou a-t-il de bonnes suggestions pour le résoudre?

Answer 1

SendKeys n'est pas un bon ajustement principalement en raison de:

• Il ne peut envoyer les clés à l'application active/concentrée, ce qui est jamais garanti de travailler parce que la l'application active peut changer entre le moment où les touches sont effectivement envoyé.
• RDP et de nombreuses autres bibliothèques (par exemple, DirectX) les bloquent principalement pour des raisons de sécurité.

De meilleures alternatives:

• Utilisez SendMessage ou SendInput pour les besoins simples
• Quelques bons exemples de la façon d'utiliser SendMessage se trouvent:
  • Send strings to another application by using Windows messages
  • SendMessage via pInvoke
  • How To Send Keystrokes To Extern Win Application
• Pour des besoins plus élaborés, il est recommandé d'utiliser WCF
• Pour vous aider à démarrer, lisez ce Basic Tutorial qui parle de Inter Process Communication

Exemple de code utilisant SendMessage:

HWND hwndNotepad = FindWindow(_T("Notepad"), NULL); 
HWND hwndEdit = FindWindowEx(hwndNotepad, NULL, _T("Edit"), NULL); 
SendMessage(hwndEdit, WM_SETTEXT, NULL, (LPARAM)_T("hello")); 

Answer 2

Dans mon cas, j'utilisais sendkeys dans le cadre de l'automatisation des tests. Cela ne fonctionnerait pas à partir de ma machine de génération, où l'agent de génération s'exécute via le protocole de bureau distant. Je ne suis pas content mais j'ai été capable d'ignorer ce test dans le cadre de mes builds automatisés. L'utilisation des appels Win32 pour envoyer des messages de fenêtre pourrait fonctionner, si j'ai le temps j'essaierai cela un jour

Quoi qu'il en soit, voici le chèque pour voir si le code actuel est en cours d'exécution dans une session de bureau à distance:

System.Environment.GetEnvironmentVariable("SESSIONNAME").StartsWith("RDP-") 

Answer 3

Vous pouvez contourner problème RDP en ayant bureau toujours connecté avant d'utiliser (ou configuré pour auto login @ chaque démarrage). Et même avec la connexion automatique, si vous avez besoin d'un accès au bureau à distance pour exécuter l'automatisation ou gérer le système, etc., la méthode préférée utilise VNC pour l'accès distant plutôt que RDP. Raison est VNC est multi-plateforme et vous ne rencontrerez pas ce problème RDP. VNC fonctionne comme un relais de votre bureau réel (session 0 de la console RDP ou "tête" de la machine), l'inconvénient étant une session à distance à la fois (ou vous partagez tous le même bureau + clavier + souris). VNC fonctionnera aussi pour les machines virtuelles.Utilisez VNC au lieu de l'accès RDP ou local (RDP) à partir du logiciel de gestionnaire de machine virtuelle (VMWare/Hyper-V/Xen). La seule chose à surveiller avec VNC est que le bureau ne peut pas être configuré pour se verrouiller automatiquement sur l'écran inactif ou l'économiseur d'écran, ce qui peut également empêcher l'exécution des touches d'envoi et de l'automation GUI, alors assurez-vous de le désactiver. Économiseur d'écran & économie d'énergie de moniteur est ok, juste pas de verrouillage automatique & mot de passe protéger. NOTE: Je ne suis pas sûr, mais je crois que puisque VNC relaie le bureau "tel quel", c'est la même chose qu'exécuter localement du point de vue de l'app/système, donc il devrait théoriquement pouvoir tromper le système/l'application qui n'autorise pas SendKeys via RDP. Déconnecté (sendkeys/automation continue de fonctionner après la déconnexion car sur le bureau actuel actif).

Answer 4

Dans mon cas, j'utilisais avec succès SendInput de WinAPI avec des codes de balayage matériel. Il semble que les chargements de cartes SendKeys ne permettent pas d'analyser correctement les codes.