@Olina-Zhang Can your team please verify this?

@Olina-Zhang Can your team please verify this?

Verified this issue in .Net framework 4.8.1 and .Net Core different versions, all have same result: when using mouse move the mouse pointer over the list items, the value in text box area is not changed, and when using up/down keyboard to go through the list items, the value in text box area is changed. It seems a by design issue.

.Net 8.0

.Net framework 4.8.1

Hi @Olina-Zhang
please try hovering over list item even faster like in my video. You need to have time to move the mouse while the list of elements unfolds - very quickly. It doesn't work the first time.

@Olina-Zhang, as I can see you didn't reproduce step 5.
It cannot be "by design", because it is very strange that depending on mouse cursor moving speed user has different values inside TextBox part.

@gc-maximloverov How you change the value from 111 to 555 in your sample?

@Olina-Zhang to do this, you need to click on the button to open the drop-down list of elements with the mouse, then very quickly hover the mouse cursor over the "555" element. The main thing is the speed of hovering the mouse over the element "555", if it is not high enough, the problem will not be reproduced. This will take several tries. Restart the application if the attempt fails. In the video that I have attached, you can see how fast I move the mouse cursor.

@gc-maximloverov our team memebers all tried this scenario with very quickly hover the mouse cursor over other elements, no textBox value changes. It's hard to reproduce. Did you have accidental mouse-click operation when moving cursor process?

@Olina-Zhang, several our team members can successfully reproduce this issue.
Also, our customers complain about this MS issue inside our controls.
All of us didn't perform mouse click acidentally or intentionally during moving cursor process.

@Olina-Zhang I didn't have a accidental mouse click operation. Can you try when moving the mouse cursor over the list of elements not to point to the element "111", but immediately to "555"?

@Olina-Zhang I have attached a project of a new test application, which, on pressing the "click me" button, reproduces the problem by simulating mouse control through the Windows API, can you run it and test it? When you click on a button, you do not need to move the mouse or press the buttons.
TestComboBox6-sim.zip

@Olina-Zhang added HighDpi support to test app.
TestComboBox6-sim.zip

@gc-maximloverov Thanks for your application, we tested it with some chance of reproducing this problem, but not 100%. In addition, when this problem is reproduced, then move mouse and click in form other place, the comboBox dropdown is collapsed, its textBox value is still "111", not "555"

@Olina-Zhang Thanks. Will this problem be fixed?

@gc-maximloverov this is an edge case, needs our engineer team to triage, @merriemcgaw what is your opinion?

@Olina-Zhang, we have custom code in our controls which uses MeasureItem and DrawItem events.
This code allows to reproduce this issue with less quicker mouse moves.
If we'll provide you this code, will there be any chance that MS team will try to fix this issue?
In other case we can answer to our users that the core problem is inside MS ComboBox and we cannot do anything on our side.

@denjmpr If this is causing problems for you and your customers. It might be a good idea to look into the problem yourself and possibly put in a MR fixing the issue. I am sure the team would be super grateful for the effort.

@denjmpr this docs should get your started https://github.com/dotnet/winforms/blob/main/docs/developer-guide.md. You can add your sample to https://github.com/dotnet/winforms/tree/main/src/System.Windows.Forms/tests/IntegrationTests/WinformsControlsTest project, set breakpoints and F5.

Given that this is potentially related to the interaction between your code and the ComboBox, there's a better than even chance that the underlying common control is the source of the problem. CommonControls are not being enhanced anymore.

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

Happy Coding!

Guys, I've tried to research it a little and what I've got for now:

1. If I'm disabling visual styles for application, the issue is not reproducible.
2. I tried to comment out this line of code:
   

   winforms/src/System.Windows.Forms/src/System/Windows/Forms/ComboBox.cs

   Line 3903 in 654da71

   base.WndProc(ref m);

   
   And the issue is not reproducible.
   I've dig it a little and it goes to:
   

   winforms/src/System.Windows.Forms/src/System/Windows/Forms/NativeWindow.cs

   Line 516 in 654da71

   m.Result = User32.CallWindowProcW(_priorWindowProcHandle, m.HWnd, (User32.WM)m.Msg, m.WParam, m.LParam);

   .

So, might it be that the actual reason is inside some OS/Native code and I cannot figure it out?
Could someone propose any other ideas or hints where I can look into?

I'm not surprised at all to learn that the underlying OS is doing something odd between the VisualStyles ON and VisualStyles OFF modes. ProgressBar control with Visual Styles OFF can change the ProgressBar color, but Windows changed that ability in WinXP and now you can try to set a color but it won't do anything.

My assumption at this is that this would be the native code, but I have a deeper philosophical question. My expectation as a user would be for the TextBox part of the control to update once focus has settled on a new value. Moving at that speed may not even register as setting the focus. Is this a particularly visible, problematic change in the OS for your apps? If so, I would file a Feedback Ticket via the Windows Feedback Hub in the OS. It should get routed to the right team. That said, they are not taking many (if any) changes to what is considered legacy UI, so the bar for getting a fix will require a strong business justification. If you have a support contract, consider using that to engage with the Windows team as well, you may get better results that way. Unfortunately, I don't think this is something WinForms will be able to impact.

You could try with cpu speed reduced to e. g. 5 or 10 %. You can apply that in power settings in maximal CPU usage option. This might help "moving fast" the mouse compared to the redraw speed of the forms.

@denjmpr you previously mentions a simplifying of the steps to reproduce. Could you provide them here incase anyone picks this issue up again?