Hier gehts um wie man WindowMessages auswerten kann, um Änderungen an Usb-Anschlüssen wahrzunehmen.
Eine Windowmessage ist eine Struktur mit vier Elementen:
Wie dem auch sei, zunächstmal muss man nur wissen, dass Windows die WM_DEVICECHANGE-Message verschickt, wenn man was an einen Usb-Buchse anschließt oder rauszieht.
Windows hält so ein Ereignis für so wichtig, dass es die Message ungefragt an jede Fensterhandle verschickt, die herumfährt.
Das ist bequem, denn für viele andere WMs muss man erst noch eine unmanaged Register-Funktion aufrufen, und ein FensterHandle angeben, an das Windows die Message senden soll (gugge zB Globaler Hotkey )
Wie empfängt man nu eine WM?
Das kann jedes Control, sogar jede Komponente, und auch die kleine Klasse
Hier überschreibe ich mal einfach die WndProc meines MainForms, filtere die msg auf WM_DEVICECHANGE, und logge die Treffer ins Outputfenster:
Mehr erstmal nicht - das ist der wichtigste Einstieg in den Umgang mit WMs: Erstmal filtern und dann loggen, was kommt. Filtert man nicht, so wird man schier erschlagen von einer unglaublichen Menge an Messages, die auflaufen.
Beachte auch, dass als erste Amts-Handlung
Hier mal der Log, der entsteht, als ich einen Usb-Stick reingesteckt habe:
Ja, leider wird
Aber trotzdem liegt bereits hiermit schon ein Mechanismus vor, der aufs Anschließen an Usb-Anschlüsse reagiert.
msg und hwnd sind natürlich immer dieselben - mein Filter lässt ja keine andere msg passieren, und hwnd ist ja die FensterHandle meines Forms.
Aber in zeile#5 des Logs - da treten abweichend besondere wparam und lparam auf.
Wie gesagt - je nach WM können diese Params alles mögliche bedeuten, hier bedeutet der wparam eine der beiden Konstanten
(Nomen est Omen) zu deutsch: Device angekommen bzw entfernt.
Und lparam bedeutet hier noch viel mehr, das ist in diesem Fall nämlich ein Pointer auf eine unmanaged Structure. Deren .Net-Pendant sieht so aus:
Also 4 Integer.
Wir kümmern uns nur um
(Ich hoffe, die Bit-Operationen
Also hier nochmal die ganze Geschichte, ein Logger, der
Ach - fast vergessen:
Übrigens habich dem Download auch noch ein Enum mit allen WM-Konstanten beigelegt - ach kann ich ja auch zeigen:
Eine Windowmessage ist eine Struktur mit vier Elementen:
- msg (
Integer): der MessageCode
Im Windows-Betriebsystem sind ca. 200 verschiedene Messages hinterlegt, als namentlich bekannte Integer-Konstanten, die Benennung beginnt per Konvention mitWM_ - hwnd (
IntPtr): Handle des Ziel-Fensters - wparam (
IntPtr): eine Zusatz-Information - lparam (
IntPtr): noch eine Zusatz-Information - result (
IntPtr): ein Message-Member, über den man dem Betriebssystem Informationen und Daten auch zurückgeben kann.
Wie dem auch sei, zunächstmal muss man nur wissen, dass Windows die WM_DEVICECHANGE-Message verschickt, wenn man was an einen Usb-Buchse anschließt oder rauszieht.
Windows hält so ein Ereignis für so wichtig, dass es die Message ungefragt an jede Fensterhandle verschickt, die herumfährt.
Das ist bequem, denn für viele andere WMs muss man erst noch eine unmanaged Register-Funktion aufrufen, und ein FensterHandle angeben, an das Windows die Message senden soll (gugge zB Globaler Hotkey )
Wie empfängt man nu eine WM?
Das kann jedes Control, sogar jede Komponente, und auch die kleine Klasse
NativeWindow kanns. Es muss halt die WndProc() - Sub vorhanden und überschreibbar sein.Hier überschreibe ich mal einfach die WndProc meines MainForms, filtere die msg auf WM_DEVICECHANGE, und logge die Treffer ins Outputfenster:
Beachte auch, dass als erste Amts-Handlung
MyBase.WndProc() aufgerufen wird, meine Überschreibung will die Message ja nicht abfangen, sondern nur mithören - deshalb reicht sie die Message schön weiter (und deshalb wird auch nicht am result-Member rumgefummelt.) Hier mal der Log, der entsteht, als ich einen Usb-Stick reingesteckt habe:
Beachte, dassOutputWindow schrieb:
msg=0x219 (WM_DEVICECHANGE) hwnd=0x830b9a wparam=0x7 lparam=0x0 result=0x1
msg=0x219 (WM_DEVICECHANGE) hwnd=0x830b9a wparam=0x7 lparam=0x0 result=0x1
msg=0x219 (WM_DEVICECHANGE) hwnd=0x830b9a wparam=0x7 lparam=0x0 result=0x1
msg=0x219 (WM_DEVICECHANGE) hwnd=0x830b9a wparam=0x7 lparam=0x0 result=0x1
msg=0x219 (WM_DEVICECHANGE) hwnd=0x830b9a wparam=0x8000 lparam=0x582e460 result=0x1
msg=0x219 (WM_DEVICECHANGE) hwnd=0x830b9a wparam=0x7 lparam=0x0 result=0x1
msg=0x219 (WM_DEVICECHANGE) hwnd=0x830b9a wparam=0x7 lparam=0x0 result=0x1
msg=0x219 (WM_DEVICECHANGE) hwnd=0x830b9a wparam=0x7 lparam=0x0 result=0x1
msg=0x219 (WM_DEVICECHANGE) hwnd=0x830b9a wparam=0x7 lparam=0x0 result=0x1
msg.ToString() die msg sogar selbst übersetzt, zu (WM_DEVICECHANGE). Dies zeigt, dass diese Konstanten im Betriebssystem wirklich festverdrahtet vorliegen.Ja, leider wird
WM_DEVICECHANGE offsichtlich viel zu oft gesendet.Aber trotzdem liegt bereits hiermit schon ein Mechanismus vor, der aufs Anschließen an Usb-Anschlüsse reagiert.
msg und hwnd sind natürlich immer dieselben - mein Filter lässt ja keine andere msg passieren, und hwnd ist ja die FensterHandle meines Forms.
Aber in zeile#5 des Logs - da treten abweichend besondere wparam und lparam auf.
Wie gesagt - je nach WM können diese Params alles mögliche bedeuten, hier bedeutet der wparam eine der beiden Konstanten
Und lparam bedeutet hier noch viel mehr, das ist in diesem Fall nämlich ein Pointer auf eine unmanaged Structure. Deren .Net-Pendant sieht so aus:
Wir kümmern uns nur um
dbcv_unitmask, denn das kann man als Bitmuster dekodieren, um den Laufwerksbuchstaben zu erhalten:<< und And sind bekannt, ansonsten fragen, wie Zeile#4 funktioniert.)Also hier nochmal die ganze Geschichte, ein Logger, der
WM_DEVICECHANGE-Messages loggt, und bei UsbSticks auch den Laufwerksbuchstaben herausfindet:VB.NET-Quellcode
- Imports System.Runtime.InteropServices
- Public Class Form2
- Private Const WM_DEVICECHANGE As Integer = &H219
- Private Shared DBT_DEVICEARRIVAL As New IntPtr(&H8000)
- Private Shared DBT_DEVICEREMOVECOMPLETE As New IntPtr(&H8004)
- Private _Counter As Integer = 0
- Protected Overloads Overrides Sub WndProc(ByRef msg As Message)
- MyBase.WndProc(msg)
- If msg.Msg <> WM_DEVICECHANGE Then Return
- Dim remark = ""
- Select Case msg.WParam
- Case DBT_DEVICEARRIVAL
- remark = "add drive: " & DEV_BROADCAST_VOLUME.FromPointer(msg.LParam).GetDriveChar
- Case DBT_DEVICEREMOVECOMPLETE
- remark = "remove drive: " & DEV_BROADCAST_VOLUME.FromPointer(msg.LParam).GetDriveChar
- End Select
- Debug.WriteLine(msg.ToString)
- WriteLog(msg.ToString, remark)
- End Sub
- ''' <summary> fügt msg und remark als numerierte neue Zeile einer Richtextbox an (die maximal 30 Zeilen anzeigt) </summary>
- Private Sub WriteLog(msg As String, remark As String)
- 'zb: msg=0x219 (WM_DEVICECHANGE) hwnd=0x950d8e wparam=0x7 lparam=0x0 result=0x1
- If remark <> "" Then remark = String.Concat(" remark=""", remark, """")
- Dim newLine = String.Concat(_Counter.ToString("000"), ": ", msg.ToString, remark)
- Dim lines = RichTextBox1.Lines.Concat({newLine})
- RichTextBox1.Lines = lines.Skip(lines.Count - 30).ToArray
- _Counter += 1
- End Sub
- End Class
- ' Struct for parameters of the WM_DEVICECHANGE message
- <StructLayout(LayoutKind.Sequential)> _
- Public Structure DEV_BROADCAST_VOLUME
- Public dbcv_size As Integer
- Public dbcv_devicetype As Integer
- Public dbcv_reserved As Integer
- Public dbcv_unitmask As Integer
- Public Function GetDriveChar() As Char
- 'die Position des in dbcv_unitmask gesetzten Bits entspricht dem Laufwerks-Buchstaben
- For i = 0 To 31
- If (1 << i And dbcv_unitmask) <> 0 Then Return Convert.ToChar(65 + i)
- Next
- Return "?"c
- End Function
- Public Shared Function FromPointer(ptr As IntPtr) As DEV_BROADCAST_VOLUME
- Return DirectCast(Marshal.PtrToStructure(ptr, GetType(DEV_BROADCAST_VOLUME)), DEV_BROADCAST_VOLUME)
- End Function
- End Structure
Marshal.PtrToStructure(IntPtr, structType) (zeile#54) - das ist die Methode, die die Daten vom unmanaged Pointer ausliest in eine geeignete .Net-Structure.Übrigens habich dem Download auch noch ein Enum mit allen WM-Konstanten beigelegt - ach kann ich ja auch zeigen:
