1

Wenn ich einen WindowEvents_WindowActivated-Handler zu meinem Modul Visual Studio 2005 Makros EnvironmentEvents hinzufüge, bekomme ich einen seltsamen Nebeneffekt: wenn ich in Visual Studio von einem Fenster auf ein anderes klicke Klicken wird als Doppelklick behandelt.Visual Studio-Makros: WindowActivated-Handler macht Klicks zu Doppelklicks

So zum Beispiel, legte ich den Fokus in einem Editor-Fenster und klicken Sie auf eine Datei im Projektmappen-Explorer, und die Datei öffnet sich.

Oder ich stelle den Fokus in die Toolbox und klicke in ein Editorfenster, und das Wort, auf das ich klicke, wird ausgewählt. In den meisten Fällen, wenn ein einzelner Klick dazu führt, dass ein Fenster aktiviert wird, wird dieser Klick als Doppelklick behandelt.

Dies geschieht auch mit einem leeren Ereignishandler:

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

ich das WindowActivated Ereignis verwenden mag coole Sachen zu tun, aber das ist ein Killer. Hat das schon mal jemand gesehen und gearbeitet? (Ich weiß, ich könnte einen Timer verwenden und für das aktuelle Fenster abfragen, aber yuck.)

+0

Das gleiche lästige Verhalten tritt auf, wenn Sie aus einem anderen Fenster in einen Dataset-Designer klicken. Sie gelangen in die Datenbank code-behind. –

+1

Wird der Event-Handler auch zweimal aufgerufen? – Steven

+0

@Steven: Der Handler wird nur einmal aufgerufen, aber siehe meinen Kommentar zu AMissicos Antwort. – RichieHindle

Antwort

2

Ich habe dieses Problem nicht. Wahrscheinlich wird das WindowActivated-Ereignis zweimal ausgelöst. Dies passiert normalerweise, wenn ein anderer Prozess den Fokus, wie ein anderes Add-In, aus dem aktivierten Fenster stiehlt, dann wird das Fenster wieder aktiviert. Sie können das Verhalten duplizieren, indem Sie einen MsgBox-Aufruf innerhalb des WindowActivated-Ereignisses hinzufügen.

Bearbeiten von RichieHindle: Die echte Antwort ist in den Kommentaren begraben: "Haben Sie das in einem Add-In versucht?" Es funktioniert gut in einem Add-In.

+1

Ich denke, Sie haben Recht, ein Fokus/Aktivierungsproblem zu sein, aber die Umstände sind seltsam. Der Unterschied zwischen Arbeiten und Scheitern scheint eine native Funktion über P/Invoke aufzurufen. Mein Makro hat SetWindowText aufgerufen, wodurch das Problem verursacht wird. Entfernen Sie diesen Anruf und es ist in Ordnung. Wie es in einen Zustand kam, in dem ein leerer Handler es zum Scheitern brachte, weiß ich nicht - ich kann das jetzt nicht reproduzieren. Ich weiß, dass die Laufzeitumgebung von VS Macros in einem separaten Prozess lebt. Vielleicht liegt es an der Verwendung von P/Invoke, dass dieser Prozess den Fokus erhält. (Der Handler wird nur einmal aufgerufen, BTW.) – RichieHindle

+0

Hinweise für SetWindowText-Status: "Um den Text eines Steuerelements in einem anderen Prozess festzulegen, senden Sie die WM_SETTEXT-Nachricht direkt anstelle von SetWindowText." Ich erinnere mich, dass ich vor vielen Jahren etwas über SetWindowText gelesen habe, was dazu geführt hat, dass ein Prozess den Fokus erfasst hat ... blah ... blah ... blah. Vielleicht kann ich eine Referenz finden. Aber die obige Aussage könnte ein Hinweis sein. – AMissico

+0

Führt SetWindowText zu Null, aber setzt den Text noch? – AMissico