Ich muss auf die Win32-Fensterhandles einiger meiner WPF-Fenster zugreifen, damit ich Win32-Aktivierungsnachrichten verarbeiten kann. Ich weiß, dass ich PresentationSource.FromVisual oder WindowInteropHelper verwenden kann, um das Win32-Fenster-Handle zu erhalten, aber ich habe Probleme, wenn das WPF-Fenster noch nicht erstellt wurde.
Wenn ich PresentationSource.FromVisual verwende und das Fenster nicht erstellt wurde, ist das zurückgegebene PresentationSource null. Wenn ich WindowInteropHelper verwende und das Fenster nicht erstellt wurde, ist die Eigenschaft Handle IntPtr.Zero (null).
Ich habe versucht, this.Show() und this.Hide() im Fenster aufzurufen, bevor ich auf das Handle zugreifen wollte. Ich kann dann den Griff bekommen, aber das Fenster blinkt kurzzeitig auf dem Bildschirm (hässlich!).
Kennt jemand eine Möglichkeit, ein WPF-Fenster zu erzwingen? In Windows Forms war dies so einfach wie der Zugriff auf die Eigenschaft Form.Handle .
Bearbeiten: Am Ende ging ich mit einer Variante von Chris Taylors Antwort. Hier ist es, falls es jemand anderem hilft:
%Vor%Eine Option besteht darin, den Fensterstatus auf "minimiert" zu setzen und ihn nicht in der Taskleiste anzuzeigen, bevor das Fenster angezeigt wird. Probieren Sie so etwas aus.
%Vor% Verwenden Sie WindowInteropHelper.EnsureHandle , es tut genau das, was Sie brauchen.
Ich habe nach einer Lösung gesucht, wenn das Handle von WindowInteropHelper NULL ist. Hoffentlich gibt dieser Post einige zusätzliche Informationen, wie man es löst.
Eine Lösung ist zu verwenden:
%Vor%Dies funktioniert nur mit .NET Framework 4.
Im Moment verwende ich .NET Framework 3.5, also brauchte ich eine andere Lösung. Dann habe ich einen Forum-Thread mit einer WindowInteropHelper-Erweiterungsmethode gefunden:
%Vor%Das WindowInteropHelper.EnsureHandle () erwartet nicht, dass ein Fenster bereits erstellt wird.
Referenz: Alexander Yudakov - Ссылка
Ich steckte in demselben Problem und ging mit J Pollacks Antwort (weil es mir sauberer scheint), aber benötigt etwas, das sowohl auf der .NET-Laufzeitumgebung 2.0 als auch 4.0 ausgeführt werden würde.
Aber als ich das gemacht habe, endete ich mit einer hässlichen MissingMethodException , weil SafeCreateWindow in der .NET-Laufzeitumgebung 4.0 nicht mehr existiert. Um den Code für beide Laufzeiten funktionsfähig zu machen, entschied ich mich, die MissingMethodException abzufangen und das Äquivalent in der .NET 4.0-Laufzeit stattdessen wie folgt aufzurufen:
%Vor%Dadurch konnte ich den Code mit .NET 3.5 kompilieren, aber auf .NET Runtime 4.0 auf Systemen, auf denen nur die höhere Laufzeitversion installiert ist (nämlich Windows 8 und höher).