1

Si j'ajoute un gestionnaire WindowEvents_WindowActivated à mon module Visual Studio 2005 Macros EnvironmentEvents, j'ai un effet secondaire bizarre: lorsque je clique d'une fenêtre à une autre dans Visual Studio, cela signifie que le clic est traité comme un double clic. Ainsi, par exemple, je mets le focus dans une fenêtre de l'éditeur et je clique sur un fichier dans l'Explorateur de solutions, et le fichier s'ouvre.Macros Visual Studio: le gestionnaire WindowActivated transforme les clics en double clics

Ou je mets le focus dans la boîte à outils et clique dans une fenêtre de l'éditeur, et le mot sur lequel je clique est sélectionné. Dans la plupart des cas, lorsqu'un simple clic provoque l'activation d'une fenêtre, ce clic est traité comme un double-clic.

Cela se produit même avec un gestionnaire d'événements vide:

Private Sub WindowEvents_WindowActivated(ByVal GotFocus As EnvDTE.Window, _ 
             ByVal LostFocus As EnvDTE.Window) _ 
             Handles WindowEvents.WindowActivated 
    ' Do nothing. 
End Sub 

Je veux utiliser l'événement WindowActivated de faire des choses cool, mais c'est un tueur. Est-ce que quelqu'un a déjà vu ça et a travaillé autour de ça? (Je sais que je pourrais utiliser une minuterie et un sondage pour la fenêtre actuelle, mais beurk.)

+0

Le même comportement gênant se produit lorsque vous cliquez dans un concepteur de dataset à partir d'une autre fenêtre. Vous entrez dans le code de la base de données. –

+1

Le gestionnaire d'événements est-il appelé deux fois également? – Steven

+0

@Steven: Le gestionnaire n'est appelé qu'une seule fois, mais voir mon commentaire à la réponse d'AMissico. – RichieHindle

Répondre

2

Je n'ai pas ce problème. L'événement WindowActivated est probablement déclenché deux fois. Cela se produit généralement lorsqu'un autre processus vole la mise au point, comme un autre complément, à partir de la fenêtre activée, puis la fenêtre est réactivée. Vous pouvez dupliquer le comportement que vous rencontrez en ajoutant un appel MsgBox dans l'événement WindowActivated.

Edité par RichieHindle: La vraie réponse est enterrée dans les commentaires: "L'avez-vous déjà essayé dans un add-in?" Cela fonctionne très bien dans un complément.

+1

Je pense que vous avez raison de dire que c'est un problème de mise au point/activation, mais les circonstances sont bizarres. La différence entre travailler et échouer semble appeler une fonction native via P/Invoke. Ma macro appelait SetWindowText, ce qui provoque le problème. Supprimer cet appel, et ça va. Comment est-il arrivé dans un état où un gestionnaire vide l'a fait échouer, je ne sais pas - je ne peux pas le reproduire maintenant. Je sais que l'environnement d'exécution des macros VS vit dans un processus distinct, alors peut-être que l'utilisation de P/Invoke permet de mettre l'accent sur ce processus. (Le gestionnaire n'est appelé qu'une seule fois, BTW.) – RichieHindle

+0

Remarques sur les états de SetWindowText: «Pour définir le texte d'un contrôle dans un autre processus, envoyez directement le message WM_SETTEXT au lieu d'appeler SetWindowText. Je me souviens d'avoir lu quelque chose il y a plusieurs années à propos de SetWindowText provoquant un processus pour capturer le focus ... blah ... blah ... blah. Peut-être que je peux trouver une référence. Mais la déclaration ci-dessus pourrait être un indice. – AMissico

+0

Est-ce que SetWindowText génère zéro, mais définit toujours le texte? – AMissico

Questions connexes