When drag the sash line of wxSplitterWindow, the target line has offset
When drag the sash line of wxSplitterWindow, the target line has offset
Hi, when I run this example 1 code in the : WxSplitterWindow - WxWiki page, I see that when I use mouse to drag the sash line in horizontal direction, the target line(a hint line) has some offset to the mouse position. See the screen shot as attachment, any ideas what does this happens?
I'm using the wx 3.1.1-rc build with mingw-build gcc 7.2 32bit compiler (under a 64bit windows 7 system).
Thanks.
EDIT This issue also happens when I use the wx 3.1.0 which build against a mingw-build gcc 5.4 32bit compiler.
I'm using the wx 3.1.1-rc build with mingw-build gcc 7.2 32bit compiler (under a 64bit windows 7 system).
Thanks.
EDIT This issue also happens when I use the wx 3.1.0 which build against a mingw-build gcc 5.4 32bit compiler.
Re: When drag the sash line of wxSplitterWindow, the target line has offset
Everything on the Wiki should be taken with a grain of salt, many things are heavily outdated.
Try with the "splitter" sample that comes with wxWidgets, that's the only valid point of reference.
Try with the "splitter" sample that comes with wxWidgets, that's the only valid point of reference.
Use the source, Luke!
Re: When drag the sash line of wxSplitterWindow, the target line has offset
OK, thanks. But I think I can reproduce this bug in the "splitter" sample.
I just build the sample with this code changes:
Note that I have comment out the "wxSP_LIVE_UPDATE", then I get such screen shot below:
So, it XOR line's position is wrong, it should near the mouse cursor, but I do see an offset here.
I just build the sample with this code changes:
Code: Select all
MySplitterWindow::MySplitterWindow(wxFrame *parent)
: wxSplitterWindow(parent, wxID_ANY,
wxDefaultPosition, wxDefaultSize,
wxSP_3D | /* wxSP_LIVE_UPDATE |*/
wxCLIP_CHILDREN /* | wxSP_NO_XP_THEME */ )
Re: When drag the sash line of wxSplitterWindow, the target line has offset
I post a thread in the wx user maillist, see here, and I see that the window position is not correct, see this post: https://groups.google.com/d/msg/wx-user ... 4n3vlfAAAJ
Re: When drag the sash line of wxSplitterWindow, the target line has offset
Very strange. Even if i comment out the wxSP_LIVE_UPDATE, i don't see that problem with any wx version.
Can you test this on another PC?
Can you test this on another PC?
Use the source, Luke!
Re: When drag the sash line of wxSplitterWindow, the target line has offset
OK, I will try another win7 PC and report back.doublemax wrote:Very strange. Even if i comment out the wxSP_LIVE_UPDATE, i don't see that problem with any wx version.
Can you test this on another PC?
Here, in my current win7(64bit) system, I see that this issue does not happens in wx 2.8.12. I can use Code::Blocks(which is wx2.8.12 based), and it has a buildin GUI designer called wxsmith. When I create a simple wxFrame which have a wxSplitterWindow, I can preview the wxFrame in the Code::Blocks, which shows correctly without this issue(The preview GUI is based on the wx2.8.12). But when I build the application(the application is build against wx3.1.0 or wx3.1.1), the built application have this issue.
Re: When drag the sash line of wxSplitterWindow, the target line has offset
OK, I just tried built application on another PC(which is Win7 64bit professional edition), and this issue does not happen there. So, what's the problem of my PC? My PC is Win7 64bit home basic edition. That's really strange.ollydbg23 wrote:OK, I will try another win7 PC and report back.doublemax wrote:Very strange. Even if i comment out the wxSP_LIVE_UPDATE, i don't see that problem with any wx version.
Can you test this on another PC?
Re: When drag the sash line of wxSplitterWindow, the target line has offset
It looks like this is an theme issue, my PC was using Windows 7 standard theme, as you see my previous screen shots.
I just change my theme to "Windows classic", and then this issue is gone.
I just change my theme to "Windows classic", and then this issue is gone.
Re: When drag the sash line of wxSplitterWindow, the target line has offset
I think the checkbox "Enable Desktop composition" in the performance options is what triggers it.
When i switch that on, i don't get the same redraw issue as you, but the whole redraw becomes slow and flickery.
When i switch that on, i don't get the same redraw issue as you, but the whole redraw becomes slow and flickery.
Use the source, Luke!
Re: When drag the sash line of wxSplitterWindow, the target line has offset
Thanks for this information.doublemax wrote:I think the checkbox "Enable Desktop composition" in the performance options is what triggers it.
When i switch that on, i don't get the same redraw issue as you, but the whole redraw becomes slow and flickery.
You are correct, I just see that if the option "Enable Desktop composition" is checked on, than this issue happens. If this option is checked off, then I don't see this issue now.
BTW: I even debugged this issue for several hours, I set some breakpoint inside the src\generic\splitter.cpp. When this issue happens, I see that I get the void wxSplitterWindow::OnSize(wxSizeEvent& event) function call twice. The first time, I see a correct event.size is passed in, and the sash position is correct, but it soon get another OnSize() call which passed a litter smaller size. Thus the sash position is recalculated, and get a litter smaller. And the two splited sub windows were set the wrong position.
Hope some wx devs can handle this issue.
Re: When drag the sash line of wxSplitterWindow, the target line has offset
Please add this information to your post on the mailing list and/or open a ticket for it.
Use the source, Luke!
Re: When drag the sash line of wxSplitterWindow, the target line has offset
I created a ticket here: #18090 (wrong xor line is drawn when I drag the wxSplitterWindow' sash bar with wxSP_LIVE_UPDATE disabled) – wxWidgets, the ticket both mention the thread and the discussion in wx maillist.
It looks like the dev(Vadim Zeitlin) has different result as yours, in fact, he can't reproduce this issue. Since your result are:
It looks like the dev(Vadim Zeitlin) has different result as yours, in fact, he can't reproduce this issue. Since your result are:
Thanks.doublemax wrote:I think the checkbox "Enable Desktop composition" in the performance options is what triggers it.
When i switch that on, i don't get the same redraw issue as you, but the whole redraw becomes slow and flickery.
Re: When drag the sash line of wxSplitterWindow, the target line has offset
Is it possible that you're running on a HiDPI screen, but your application is not marked as dpi-aware?
The problematic method is most likely wxSplitterWindow::DrawSashTracker(), which uses wxScreenDC to write directly onto the screen. Maybe the conversion from client coordinates to screen coordinates fails.
The problematic method is most likely wxSplitterWindow::DrawSashTracker(), which uses wxScreenDC to write directly onto the screen. Maybe the conversion from client coordinates to screen coordinates fails.
Use the source, Luke!
Re: When drag the sash line of wxSplitterWindow, the target line has offset
Hi, doublelmax, you are correct, I can confirm it. Thanks.doublemax wrote:Is it possible that you're running on a HiDPI screen, but your application is not marked as dpi-aware?
The problematic method is most likely wxSplitterWindow::DrawSashTracker(), which uses wxScreenDC to write directly onto the screen. Maybe the conversion from client coordinates to screen coordinates fails.
I checked my DPI settings of my computer's display, and I see it is 125%. My system is a 14 inch laptop which has 1920*1080 resolution.
(The setting in described in this page: https://www.techrepublic.com/blog/windo ... i-scaling/)
And I can confirm that if I explicitly run the executable from the command line like below, the issue is gone:
Code: Select all
@set "__COMPAT_LAYER=~ HIGHDPIAWARE" & start "" /max "mysplittertest.exe"
Re: When drag the sash line of wxSplitterWindow, the target line has offset
If everything in your application works correctly when set to "dpi aware", that's definitely the best option.So, it is definitely a HiDPI issue. Any idea how to solve this? I just need to add a manifest file to the executable to tell the system that don't scale the text in the application like the command line option I used above?
Use the source, Luke!