2013-06-10 19 views
12

Ich fand dieses Juwel (IMO) in System.Windows.Forms Namespace. Ich kämpfe um herauszufinden, warum es so eingestellt ist.Odd Enum-Werte in Windows.Forms.MouseButtons

[Flags] 
public enum MouseButtons 
{ 
    None = 0, 
    Left = 1048576, 
    Right = 2097152, 
    Middle = 4194304, 
    XButton1 = 8388608, 
    XButton2 = 16777216, 
} 

Kann jemand erklären, warum es diese Werte (Leistung von 2^20-2^24) statt dessen verwendet:

public enum MouseButtons 
{ 
    None = 0, 
    Left = 1,  // 2^0 
    Right = 2,  // 2^1 
    Middle = 4, // 2^2 
    XButton1 = 8, // 2^3 
    XButton2 = 16, // 2^4 
} 

Der erste Wert ist 100000000000000000000 binär, was Raum für weitere 20 Bits verlässt! Warum brauchen wir solchen Raum und warum wird er so erhalten?

+2

Es liegt wahrscheinlich an einem Kompatibilitätsproblem von Win32. –

+1

@newStackExchangeInstance Mind Sharing einen Link oder eine Erklärung, die zu so etwas führen könnte? – Odys

+0

Ich habe keine Informationen zu diesem speziellen Fall, aber was ich weiß, ist, dass es in Enums in .NET viele ungerade Werte gibt, aufgrund von win32. –

Antwort

3

Aufzählungswerte, die in Winforms verwendet werden, tendieren dazu, die entsprechenden Bits im winapi zu entsprechen, aber das ist bei Mausknöpfen überhaupt nicht der Fall. Um dies zu erklären, bedarf es einer ziemlich wilden Vermutung.

Ich habe eine, die Art, wie Sie den Zustand der Maustasten abrufen, ohne sich auf eine Windows-Nachricht verlassen ist sehr seltsam. Sie rufen GetAsyncKeyState() auf und übergeben VK_LBUTTON durch VK_XBUTTON2. Gefälschte virtuelle Schlüssel, die eigentlich Maustasten und keine Tastaturtasten darstellen. Dies geschah Weg zu lange her, für mich zu erraten, warum sie es auf diese Weise getan, anstatt eine ordnungsgemäße GetMouseButtonState() WinAPI-Funktion.

Die Keys Enumeration hat auch diese Werte, wie Keys.LButton und so weiter. Etwas anderes an Keys ist, dass es auch den Status eines Modifizierschlüssels codieren kann. Es gibt zum Beispiel Keys.Control und Keys.ControlKey. Und Keys.Shift vs Keys.ShiftKey, und so weiter. Der erste zeigt den Zustand des Schlüssels an, der zweite den tatsächlichen Schlüssel. Which erlaubt freundlichen Code wie keydata == (Keys.Control | Keys.F) zu überprüfen, ob Strg + F gedrückt wurde.

Die Bedeutung dieser Enumerationswerte von MouseButtons ist dann, dass sie in einen Keys Enum-Wert passen, um den Zustand der Maustasten anzuzeigen. Belassen von 20 Bits für die Bits, die den Schlüssel codieren.

Hört sich gut an, oder? Der einzige Schluckauf ist, dass es nie innerhalb des Winforms-Objektmodells so kombiniert wird. Aber könnte in Ihrem eigenen Code eine Verknüpfung definieren, die auch den Mausstatus verwendet.

1

Meine Vermutung ist, dass es damit zu tun hat, wie die zugrunde liegende Windows-API Mausinformationen an .NET weitergibt.

Windows-Pakete, auf die die Mausschaltflächen geklickt werden, sowie Zeigerposition in einem Informationsblock (denken Sie an die alte MOUSE_EVENT-Struktur). Die Enums in .NET sind so eingerichtet, dass sie effizient sind, also passen sie wahrscheinlich gut zu der zugrunde liegenden Windows-Nachricht.

Anstatt also die untergeordnete Nachricht zu erhalten und sie in eine neue Menge von Werten zu konvertieren, zielt .NET nur auf die Bits in der unteren Nachricht, an der es interessiert ist - keine Konvertierung, keine Mathematik, nur Effizienz.