Ce qui se passe "derrière" les fenêtres de l'écran de verrouillage?
Je travaille sur windows automation et de contrôle.
Ce qui se passe exactement quand je verrouiller l'écran d'un ordinateur windows?
Je travaille avec Windows 7 pour le moment, il y a de grandes différences de comportement si je passe à Vista ou les versions de serveur?
Est-il encore un ordinateur de bureau qui peut être consulté via l'api?
Je sais que je peux toujours envoyer des touches et de clics de souris pour windows spécifique (via ControlSend et ControlClick), mais il semble y avoir pas de "bureau" lui-même.
Quelqu'un pourrait jeter de la lumière sur toute cette affaire ou me pointer à un lisible de la source où je pourrais obtenir une vue d'ensemble sur le sujet?
Vous devez vous connecter pour publier un commentaire.
Essentiellement ce qui se passe, c'est que Windows utilise le bureau sécurisé, rend l'actuel, de sorte que l'entrée est maintenant associé avec elle.
L'ancien bureau reste là où il était: tout le Hwnd sur le bureau sont toujours là, et n'importe quel thread attaché à ce bureau peut toujours accéder à ces Hwnd, obtenir leur emplacement, et ainsi de suite. Vous pouvez encore envoyer des messages de windows sur cet ordinateur de bureau, aussi longtemps que le fil de l'envoi du message est également sur ce bureau.
Cependant, depuis le bureau est maintenant inactif, il ne peut pas recevoir d'entrée. GetForegroundWindow renvoie la valeur NULL (IIRC), et vous ne pouvez pas utiliser SendInput plus, depuis l'entrée appartient maintenant à [un sujet] un bureau à l'autre; aucun contrôle sur ce inactif bureau peut recevoir le focus.
Notez que l'envoi de pression de touche des messages à un contrôle qui n'a pas l'accent peut parfois provoquer un comportement inattendu, depuis l'application ou le contrôle généralement on ne s'attend à recevoir un clavier d'entrée sans faire la mise au point de la première. (Cela peut être problématique pour les contrôles mis en place une sorte de contexte d'entrée dans WM_SETFOCUS et clair dans WM_KILLFOCUS, par exemple.)
En bref, l'INTERFACE utilisateur est toujours là: vous pouvez faire certaines requêtes, mais vous ne pouvez plus l'automatiser comme vous le feriez sur un bureau ordinaire par l'envoi d'entrée, et quelques autres fonctions qui se rapportent à se concentrer ou de saisie peut échouer.
Je ne suis pas super familier avec AutoHotKey, mais le nom et la description de la fonctionnalité suggère qu'il est fortement dépendante de la sous-jacentes Win32 API SendInput. Cela ne fonctionne pas du tout pour la saisie au clavier quand un ordinateur de bureau est inactif.
Bon aperçu de la façon dont les ordinateurs de bureau de travail et comment ils se rapportent à winstations, le bureau verrouillé, et ainsi de suite, découvrez le Bureau article sur MSDN.
Un problème que j'ai couru dans le passé avec les ordinateurs de bureau et d'automatisation est: comment puis-je quitter un long test en cours qui utilise une certaine forme de l'automatisation de la saisie de l'utilisateur (souris, clavier de simulation), mais encore de verrouillage de mon PC, de sorte que quelqu'un ne pouvez pas simplement marcher et interférer avec elle. Une fois que vous verrouillez l'ordinateur, le bureau est inactif, et donc l'automatisation des arrêts de travail. Un problème similaire se produit si l'économiseur d'écran coups de pied dans: les commutateurs de bureau, et l'échec d'automation.
Une solution consiste à utiliser deux Pc: appelons-la Principale et de Test: à partir de main, ouvrir à distance un client des services terminal server sur la machine de Test, puis exécutez le test automatisé sur la machine de test, mais à partir d'une fenêtre du client terminal server sur la machine Principale. Maintenant, la partie la plus cool: vous pouvez réduire les du CST de la fenêtre, ou même de verrouillage de la machine Principale (ou laisser l'économiseur d'un coup), et que la session virtuelle va continuer à travailler, à penser qu'elle est toujours active - c'est juste que personne n'est à payer toute l'attention. C'est une façon de créer un "connecté" session avec un ordinateur de bureau, mais personne ne peut interférer avec, parce qu'il est protégé derrière le bureau verrouillé de la machine Principale.
Je ne connais pas les détails, mais je crois que le verrouillage de l'écran constitue un "bureau" et peut-être aussi une fenêtre de la gare" (ce que je comprends d'une station de fenêtre est qu'un conteneur pour les ordinateurs de bureau). La MSDN section sur les stations de fenêtre devrait être utile: http://msdn.microsoft.com/en-us/library/windows/desktop/ms687098%28v=vs.85%29.aspx
Afin d'accéder à un ordinateur de bureau, vous aurez besoin pour l'utilisation de l'api de windows à partir d'un fil qui est sur ce bureau. SetThreadDesktop serait probablement la façon la plus simple de le faire en C, tant que le bureau n'est pas sur une autre fenêtre de la gare.
Malheureusement, c'est déjà difficile pour un terrain privilégié d'application, et à l'aide de AutoHotkey complique encore plus. Puisque vous n'avez pas de contrôle sur les threads ou processus d'initialisation, vous aurez probablement à créer un nouveau processus dans l'autre bureau (vous pouvez faire cela en utilisant l'API CreateProcess, qui semble avoir un wrapper disponibles pour AHK à laquelle vous pouvez fournir un nom du bureau: http://www.autohotkey.com/forum/topic1952.html). Votre processus aurez besoin des privilèges spéciaux pour ce faire; je ne suis pas sûr que même en cours d'exécution en tant qu'Administrateur est assez.