Bugzilla – Bug 161
Preferences: Vertical scrollbar in treeview doesn't display when required √
Last modified: 2018-08-20 11:45:24 UTC
GA: When Preferences tree is not tall enough to display all items (when dragging up, or given larger fonts, even on opening) the vertical scrollbar flickers then is hidden, and the treeview bleeds into the static boxes to right. On systems with larger fonts, the text of the last item (Mouse) is truncated until you drag the window down. According to another report at: http://article.gmane.org/gmane.comp.lib.wxwindows.general/67888 this may mean we can't add more items to tree unless we increase height of preferences. LRN: After a couple of hours of toying with wxTreebook i have to conclude that it is difficult to fix this either way. wxTreeCtrl resizing is handled automatically by DefWindowProc(), so it is Windows who actually removes or hides the scrollbar, and there is no control over this behaviour - Tree Control in Windows doesn't have anything like TVS_DISABLENOSCROLL style (there is LBS_DISABLENOSCROLL, but that is for list boxes) which should have prevented it from hiding the scrollbar. Also, wxTreeCtrl lacks any scrollbar control interface, because it is not derived from wxScrolledWindow, so changing window styles to something like wxALWAYS_SHOW_SB doesn't work either. It is possible to force tree control to show disabled scrollbar instead of hiding it by calling SetScrollInfo() WinAPI function (or the corresponding wx wrapper, although that's a bit tricky), but that has to be done each time AFTER DefWindowProc() does its destructive wxSizeEvent handling job, and i haven't seen a wx event handler with "after-default" placement (like the ones in GTK+) The "difficult" solution here is to fix the sizer function (or whatever arranges child widgets) to make it react adequately on ever-changing wxTreeCtrl size. Alas, my humble wxSkills are not enough for that.
current height is 333 -- 340 px tall eliminates the problem (no scrollbar needed) until we add another section
(In reply to comment #1) Not a problem on Win XP or for Bill on Mac. Again for me on Win 7 x64, the window launches with "Mouse" truncated, no scrollbar. I see that scrollbar subliminally when I drag the window down a bit so that I can see the "Mouse" without truncation.
From private e-mail to Bill: On 6-Apr-11, at 6:37 PM, Ed Musgrove wrote: > In re. bug 161: current prefs dialog height is 333 -- 340 px tall > eliminates the problem (no scrollbar needed) until we add another > section. > > In re. bug 295 -- Bill, can you drag the Prefs dialog down a tiny bit > at a time until it's just enough to fix the problem then measure it's > height? > Ed: Resizing the prefs dialog down by 1 pixel fixes the display problem. The dialog can then be resized back to it's minimum size and the display remains OK. So it seems the "redraw-on-resize" code is fixing the problem? -- Bill ------------------- I would like to see a test build with the Prefs window @340 tall to see if it clears both this and 295; will try to post a patch later but have no way to get a Mac build for Bill to test.
Created attachment 172 [details] make prefs window a tiny bit taller Index: PrefsDialog.cpp =================================================================== --- PrefsDialog.cpp (revision 11161) +++ PrefsDialog.cpp (working copy) @@ -157,7 +157,7 @@ sz.y = 600; } - SetSizeHints(sz.x, sz.y, 800, 600); + SetSizeHints(sz.x, sz.y+7, 800, 600); // Center after all that resizing, but make sure it doesn't end up // off-screen
Ed - bug 295 has another proposed solution - try and activate the layout/redraw code on opening prefs. However resizing down and back up does not stop the truncation of "Mouse" in the tree for me. Perhaps we need both solutions?
There are known issues with wxTreeControls in re. this issue, I do not understand the ShuttleGUI code so cannot determine if <i>this</i> bug is due to a problem in one or the other. My patch (if it works on Mac as it does on Windows & Linux) only <i>masks</i> the problem by eliminating the need for a sizer. As for the bug 295 thought of "activate the layout/redraw code on opening prefs" as I understand it that code is already exercised every time one opens Prefs--that is how ShuttleGUI does its work (I think). Any chance of getting this patch in a Mac build so that Bill may report on the result? I do not know if making the Prefs window 7 px taller is a major decision which would be contentious or something you could do unilaterally. Doing it in a nightly alpha and reverting it a few days later should not get anyone's knickers in a twist <grin>.
(In reply to comment #6) Clearly things aren't working correctly in bug 295 now, whatever actually happens. I can't really judge what ramifications + SetSizeHints(sz.x, sz.y+7, 800, 600); could have beyond the obvious one so I'd suggest asking Michael or Leland to give it a try to see if it does what you want on Mac.
Another result of this problem is that the right edge of the Preferences tree is widened and jams against left edge of the static boxes. In the "Extended Import" Preferences this causes the "Attempt to use" checkbox to not respond to mouse clicks when clicking in the checkbox - it responds only when you click in the corresponding text. I applied Ed's patch 22Jan12 on Windows and it had the desired effect on this bug. Putting the "Attempt to use" checkbox in its own static box (on the grounds it has nothing to do with the table below it) or other solution to add space below it also has the same effect as Ed's patch.
(In reply to comment #7) This patch is a hack, but it's about a bug in wxTreeBook and this fix works for 2.0. Ed, whenever your code adds a "magic number", it is crucial to document it. Otherwise, it's completely baffling.
OK of course on Windows, doesn't hurt Linux.
This Widgets bug appears to refer http://trac.wxwidgets.org/ticket/14496 .
