[Bug 41909] New: Calling TBM_SETPOS after TBM_SETRANGEMIN/ TBM_SETRANGEMAX does not draw slider control properly
https://bugs.winehq.org/show_bug.cgi?id=41909 Bug ID: 41909 Summary: Calling TBM_SETPOS after TBM_SETRANGEMIN/TBM_SETRANGEMAX does not draw slider control properly Product: Wine Version: 1.9.23 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: wine(a)sagagames.de Distribution: --- The default range for a slider is 0 to 100, so the value 0 is on the left side of the slider (assuming a horizontal slider). I have a slider control ranging from -500 to +500, the range is being set using TBM_SETRANGEMIN / TBM_SETRANGEMAX. This means that the value 0 should be precisely in the middle. However, after calling TBM_SETPOS with a parameter of 0, the slider stays at the left side of the control, even though it should now be located in the middle. This works as expected on Windows, but not in Wine 1.9 on latest Xubuntu. Code to reproduce: SendMessage(hWnd, TBM_TBM_SETRANGEMIN, FALSE, -500); SendMessage(hWnd, TBM_TBM_SETRANGEMAX, FALSE, 500); SendMessage(hWnd, TBM_SETPOS, TRUE, 0); -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41909 --- Comment #1 from Johannes <wine(a)sagagames.de> --- Obvious typo in the example: TBM_TBM should just be TBM. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41909 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Component|-unknown |comctl32 Assignee|wine-bugs(a)winehq.org |bunglehead(a)gmail.com --- Comment #2 from Nikolay Sivov <bunglehead(a)gmail.com> --- Hi, Johannes. I can reproduce this, thanks for . It doesn't happen if you start with range [0, 100], with position at 50 and then run your message sequence, but it does happen if initial position is 0. I'm looking at possible fix. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41909 --- Comment #3 from Johannes <wine(a)sagagames.de> --- Hi Nikolay, Yes, my current workaround is to just set the slider to *any* position that is not 0 before setting it to the actual value, that way it moves to the intended position. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41909 --- Comment #4 from Nikolay Sivov <bunglehead(a)gmail.com> --- Actually, I don't think it's supposed to work like you expect it to. I did some more testing and it's clearly checking previous position and if it's the same thumb does not move. Could you attach your test application here, so I can test it myself? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41909 --- Comment #5 from Johannes <wine(a)sagagames.de> --- (In reply to Nikolay Sivov from comment #4)
Actually, I don't think it's supposed to work like you expect it to. I did some more testing and it's clearly checking previous position and if it's the same thumb does not move. Could you attach your test application here, so I can test it myself?
The real-world example where this is taken from is OpenMPT: https://openmpt.org/download Run the application, go to File -> New -> OpenMPT Module, then View -> Song Properties, then click "Configure Swing". You will notice that all sliders are centered on Windows (their value is 0 in a -500...500 range), but on Wine they are all on the left. OpenMPT is an MFC application but I checked that MFC's wrappers don't do anything else apart from these SendMessage calls. If this is too complicated to debug, I can try whipping together a minimal example. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41909 --- Comment #6 from Nikolay Sivov <bunglehead(a)gmail.com> --- Ok, thanks. I checked out your trunk revision, and I think I see where this comes from, this dialog does: --- r->valueSlider.SetRange(-SliderResolution / 2, SliderResolution / 2); r->valueSlider.SetTicFreq(SliderResolution / 8); r->valueSlider.SetPageSize(SliderResolution / 8); --- According to my testing SetTicFreq() makes a difference, because it updates thumb position (TBM_SETTICFREQ does not have additional deferred update argument, so it always updates). We currently don't touch thumb at all on TBM_SETTICFREQ. Could you do a test build of your application without SetTicFreq and SetPageSize call to confirm that it breaks on windows too? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41909 --- Comment #7 from Johannes <wine(a)sagagames.de> --- Yes, this does indeed seem to cause the difference. Without those two calls, the handles all stay on the left side of the slider. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41909 --- Comment #8 from Nikolay Sivov <bunglehead(a)gmail.com> --- Ok, thanks for testing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41909 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bunglehead(a)gmail.com |wine-bugs(a)winehq.org --- Comment #9 from Nikolay Sivov <bunglehead(a)gmail.com> --- I've just sent a fix for that, https://www.winehq.org/pipermail/wine-patches/2016-December/156440.html. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41909 --- Comment #10 from Nikolay Sivov <bunglehead(a)gmail.com> --- This should be fixed with a6aabe0159b6c38664380718b57418618e305704. Please retest. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41909 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |a6aabe0159b6c38664380718b57 | |418618e305704 URL| |https://openmpt.org/downloa | |d Keywords| |download Status|NEW |RESOLVED --- Comment #11 from Nikolay Sivov <bunglehead(a)gmail.com> --- Resolving, I tested it, and it works properly now. Please remove any workaround for that you have in trunk, so we can have some testing from your users too. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41909 --- Comment #12 from Johannes <wine(a)sagagames.de> --- Sorry for the delay, I finally got to test it and can confirm that it works as expected in OpenMPT 1.26.07.00. However, I am hesistant to remove the workaround at this point in time as I can see that the majority of our Wine users are on Wine 1.6. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41909 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #13 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 2.0-rc3. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41909 Michael Stefaniuc <mstefani(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.8.x -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41909 Michael Stefaniuc <mstefani(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.8.x |--- --- Comment #14 from Michael Stefaniuc <mstefani(a)redhat.com> --- Removing 1.8.x milestone from bugs included in 1.8.7. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org