Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
hughbe opened this issue Nov 6, 2019 · 4 comments

Comments

@hughbe
Copy link
Contributor

@hughbe hughbe commented Nov 6, 2019

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

This comment has been minimized.

Copy link
Member

@JeremyKuhne JeremyKuhne commented Nov 6, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@hughbe hughbe commented Nov 6, 2019

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

@JeremyKuhne

This comment has been minimized.

Copy link
Member

@JeremyKuhne JeremyKuhne commented Nov 7, 2019

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

This comment has been minimized.

Copy link

@weltkante weltkante commented Nov 7, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.