Standardise between User32.SendMessageW(this, ...) and this.SendMessage(...)

[hughbe]

There are multiple different ways of sending a message to a control:

                SendMessage((int)ComCtl32.PBM.SETRANGE32, _minimum, _maximum);
                SendMessage((int)ComCtl32.PBM.SETSTEP, _step, 0);
                SendMessage((int)ComCtl32.PBM.SETPOS, _value, 0);
                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));

These two (User32.SendMessageW and SendMessage) are functionally the same but we're not consistent in how we use them

What should we standardise on?
/cc @JeremyKuhne

[JeremyKuhne]

The thought was to put everything in User32.WindowMessage, even if there are duplicates for given numeric values. That gives the best discoverability and tersest code (in particular with switch statements).

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));

Becomes:

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 LPARAM and WPARAM struct that can have safe explicit/implicit casts to/from common usage types (int, uint, WindowMessage, Color, etc.). It is easy to mess up when casting to IntPtr as it is effectively checked.

(On a somewhat related note, we may get native ints in 5.0)

[hughbe]

I thought we were deliberately moving against putting things in WindowMessage enum and making our own enums

[JeremyKuhne]

It isn't the way we did it in the designer. There is real value in having them all in the same enum (reduces casting, improves discoverability), I don't know that there are any positives to having them separated out that would outweigh that.

cc: @RussKie

[weltkante]

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.

[dreddy-work]

Thanks @hughbe for pointing this out. This is ongoing cleanup work and would welcome community contributions here. We can go this iteratively (may be file by file or control by control).

[ghost]

This issue is now marked as "up for grabs", and we’re looking for a community volunteer to work on this issue. If we receive no interest in 120 days, we will close the issue. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[elachlan]

Does the move to CsWin32 make this resolved?

#7445

[elachlan]

@dreddy-work as far as I can tell the changes to using CsWin32 have resolved this issue. We have standardised to PInvoke.SendMessage.

[dreddy-work]

Agree. If any remaining will be done soon.