Registrieren einer benutzerdefinierten win32-Fenster-Klasse von c#
Habe ich eine neue Anwendung geschrieben in WPF, braucht zur Unterstützung eine alte API, die ermöglicht, dass Sie erhalten eine Nachricht, die gepostet wurde, zu einem versteckten Fenster. In der Regel einer anderen Anwendung verwendet FindWindow zu identifizieren, die das ausgeblendete Fenster mit den Namen Ihrer benutzerdefinierten Fenster-Klasse.
1) ich nehme an, implementieren Sie eine benutzerdefinierte Fensterklasse, die ich brauche, um die Nutzung der alten Schule-win32-aufrufen?
Meine alten c++ - Anwendung verwendet RegisterClass und CreateWindow, um die einfachste mögliche unsichtbare Fenster.
Ich glaube, ich sollte in der Lage sein, das gleiche zu tun, alle innerhalb von c#. Ich will nicht, dass mein Projekt zu kompilieren alle nicht verwalteten code.
Habe ich versucht Erben von System.Windows.Interop.HwndHost und mit System.- Laufzeit.InteropServices.DllImport ziehen in den oben genannten API-Methoden.
Tun, dies kann ich erfolgreich host einen standard-win32-Fenster z.B. "listbox" inside WPF.
Allerdings werden mir beim Aufruf von CreateWindowEx für meine benutzerdefinierte Fenster wird es immer null zurück.
Mein Aufruf von RegisterClass erfolgreich, aber ich bin mir nicht sicher, was ich einstellen
WNDCLASS.lpfnWndProc Mitglied.
2) weiß jemand, wie dies zu tun erfolgreich?
InformationsquelleAutor morechilli | 2008-09-24
Du musst angemeldet sein, um einen Kommentar abzugeben.
Für die Platte, die ich schließlich bekam dies funktioniert.
Stellte sich heraus die Schwierigkeiten, die ich hatte, Lagen an string-marshalling-Probleme.
Ich hatte, um genauer zu sein in meinem Import der win32-Funktionen.
Unten ist der code, erstellen Sie eine benutzerdefinierte Fenster-Klasse in c# - nützlich für die Unterstützung von alten APIs, die Sie haben könnten, die sich auf benutzerdefinierte Fenster-Klassen.
Sollte es entweder in WPF oder Winforms, wie lange eine Nachricht, die Pumpe läuft, auf dem thread.
BEARBEITEN:
Aktualisiert zum beheben des gemeldeten Absturz durch zu frühe Sammlung der Delegat umschließt, die den Rückruf. Die Stellvertretung ist nun hielt als Mitglied und die Stellvertretung ausdrücklich gemarshallt als Funktionszeiger. Dies behebt das Problem und macht es leichter zu verstehen, das Verhalten.
Dies funktioniert gut auf 32bit windows, aber stürzt auf 64bit. Ich habe Probleme beim Debuggen, warum, weil der Teil des Codes, stürzt ab, ist nichts zu tun mit den custom-Fenster. (Es passiert, wenn ich Visible = false in einem event-handler von einem anderen Formular, das hat nichts zu tun mit dieser Klasse, aber wenn ich nicht instanziieren, es stürzt nicht ab.) Haben Sie zufällig eine Idee warum es sein könnte, oder jeder Richtung, in die Sie mich?
Sollte jetzt behoben sein.
Ich fühle mich wie ein idiot, aber ich kann nicht ankommen dieses zu wirken. Ich bin mit windows forms und erstellen Sie ein Formular mit einem button-Klick und Aufruf von Show(). Ich bin-Verpackung, die in der Verwendung von (CustomWindow cw = new CustomWindow("Waffel")) { ... } In der Klasse, die erbt von form mache ich protected override CreateParams CreateParams { get { CreateParams param = base.CreateParams; param.ClassName = "waffle"; return param; } } Aber ich bekomme immer noch die Fehlermeldung "Fenster mit Klasse-name ist nicht gültig."
Hi - ich bin mir nicht sicher, was genau Sie versuchen zu erreichen - können Sie das erklären? Der obige code ist, sollte ein Fenster mit einer benutzerdefinierten Fenster-Klassennamen. Dies kann gehostet werden, in einer winforms-Anwendung, aber das Fenster selbst nicht eingewickelt in eine Instanz des Form-Objekts. Es wird jedoch in der Lage sein zu reagieren, um alle an Sie gesendeten Nachrichten. Es klingt wie Sie versuchen, ein Form Objekt erstellen, verwendet ein benutzerdefiniertes Fenster-Klasse - das ist eine andere Sache und würde den Rahmen dieser Lösung. Hilft das?
InformationsquelleAutor morechilli
Ich würde gerne kommentieren die Antwort von morechilli:
In den Konstruktor kopiert habe ich über ist leichte Fehler: Der WNDCLASS-Instanz erstellt, aber nicht gespeichert. Es wird schließlich von der garbage Collection freigegeben. Aber der WNDCLASS hält die WndProc zu delegieren. Dies führt zu einem Fehler, sobald WNDCLASS wird Müll gesammelt. Die Instanz von WNDCLASS werden sollte, halten Sie in einer member-variable, bis das Fenster zerstört wird.
InformationsquelleAutor Martini Bianco
1) Sie können nur eine Unterklasse ein normales Windows-Forms-Klasse... keine Notwendigkeit für alle diejenigen, die win32-Aufrufe, die Sie gerade brauchen, um analysieren Sie die WndProc-Nachricht manuell... ist alle.
2) können Sie importieren Sie System.Windows.Forms-namespace und verwenden ihn neben WPF, glaube ich, gibt es keine Probleme, solange Sie sich nicht Ineinander zu viel von windows forms in WPF-Anwendungen. Sie wollen einfach nur zu instanziieren der ausgeblendeten benutzerdefinierten Formular zu receieve eine Nachricht ist das richtig?
Beispiel der WndProc-Methode von Unterklassen:
Da Sie bereits wissen, RegisterClass und alle die Win32-Aufrufe, nehme ich die WndProc-Nachricht, wäre das kein problem für Sie...
Sie können den Namen der Klasse für Ihre Formulare bei der Verwendung von winforms.
Vielen Dank für das update. Ich bin nicht mehr dabei .net-Entwicklung, aber würde gerne aktualisiere ich meine Antworten, wenn Sie eine zuverlässige arbeiten Beispiel.
InformationsquelleAutor chakrit
WNDCLASS wind_class;
setzen Sie die definition der Klasse, nicht der Funktion und der Absturz behoben wird.
InformationsquelleAutor Paul