Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
There are multiple different ways of sending a message to a control:
These two (
What should we standardise on?
The thought was to put everything in
User32.SendMessageW(this, (User32.WindowMessage)ComCtl32.PBM.SETBKCOLOR, IntPtr.Zero, (IntPtr)ColorTranslator.ToWin32(BackColor)); User32.SendMessageW(this, (User32.WindowMessage)ComCtl32.PBM.SETBARCOLOR, IntPtr.Zero, (IntPtr)ColorTranslator.ToWin32(ForeColor));
User32.SendMessageW(this, User32.WindowMessage.PBM_SETBKCOLOR, IntPtr.Zero, (IntPtr)ColorTranslator.ToWin32(BackColor)); User32.SendMessageW(this, User32.WindowMessage.PBM_SETBARCOLOR, IntPtr.Zero, (IntPtr)ColorTranslator.ToWin32(ForeColor));
I'm also keen on us structing out some of the defines, which would make these calls simpler and safer. In particular I want to create an
(On a somewhat related note, we may get native ints in 5.0)
Control specific message are reusing the same numeric values in the WM_USER range, having conflicting definitions in the same enum can cause confusion during debugging, when the debugger picks an arbitrary unrelated WindowMessage for display just for having the same value.
Personally I'd leave the WM_USER/WM_APP range (0x0400 to 0xBFFF) out of the central enum because you can't figure out the "right" meaning of the message without knowing which control you use. Also the "discoverability" of having control specific messages in the same enum is risking sending an inappropriate message to a control.
And (just to keep in mind) as an edge case we've seen with RichTextBox that there can be different numeric values associated with the same name.