I am writing a small app in wxPython, using an XRC file, and ran into a
few issues.
First issue: I use two (nested) SplitterWindows to allow the user to
resize widgets to their liking. While the outermost one works as
advertized, the innermost one gives its left panel its minimal size,
despite of me specifying a sashpos of 0. I have found a workaround for
this: after calling the frame's Layout method, if I explicitly set the
sashpos in code, it works. However, I would like to know if I did
something wrong, or if this can be avoided somehow. The attached
stripped-down files demonstrate the problem (and workaround).
My second issue is with the TreeCtrl. In my app, I have two of those:
the left one displays available items, the right one selected items. I
would like to transfer items from left to right when double-clicking
them in the left TreeCtrl (and v.v.). This works; however, the selected
item also expands. I would like to avoid this. I currently use
EVT_TREE_ITEM_ACTIVATED to detect the double-click; I do not call
event.Skip(). I have tried using EVT_LEFT_DCLICK; however, this event
does not seem to be triggered. (Using doubleclick would complicate
things anyway, as the default keyboard navigation would no longer work.)
Is there a way to achieve what I want?
First issue: I use two (nested) SplitterWindows to allow the user to
resize widgets to their liking. While the outermost one works as
advertized, the innermost one gives its left panel its minimal size,
despite of me specifying a sashpos of 0.
The <minsize> tag for a splitterwindow is setting its MinimumPaneSize,
so that is why it is restricting the sash position to a value > 0.
Thanks, I would never have thought of that. Would you agree this is a
bug? The sashpos value zero means "place the sash in the middle", which
is what I want; it does not mean "give the left panel zero size".
Removing the minsize from the splitterwindow fixes the problem, but
introduces a new one: the user can now place the sash so far to the edge
that they can't get it back to resize again. I tried setting the two
TreeCtrl's minsize (in the sizeritem's properties), but that doesn't
seem to do anything.
[[Preventing TreeCtrl dblclick from expanding the tree item]]
You could try doing something with the EVT_TREE_ITEM_EXPANDING event (it
can be Vetoed) but I'm not sure how you would sense which ones you
should Veto and which shouldn't be.
Me neither; if I could catch the dblclick event I might give it a go,
but I fear that this would screw things up for other platforms than I
develop this on (Windows). I guess I'll live with it for now. (I have
added a context menu for the tree items that circumvents the problem
somewhat.)
You gave two explanations for this. The first one was that the minsize
setting overruled the sashpos setting. This would explain what I
described above, but sounds like a bug to me (sashpos 0 does not mean
panesize 0). The second explanation is an initialization order problem,
where the sash is placed before the final size of the splitter is
determined. This sounds less like a bug to me, but does not explain (to
me, anyway) why removing the minsize setting fixes the problem.
Actually, I think you've misunderstood the first one, it is just another aspect of the second. In other words, the minsize is not overriding the sashpos, it is just preventing the sash from being sized any smaller than that due to the tiny size of the splitter before the initial layouts are done.
While I am increasingly happy that I've found a simple workaround
(setting sashpos from code), I am curious what makes us see different
things here. Can you not reproduce what I am seeing using the attached
sample?
I can. When I tried to duplicate it before I didn't use nested splitters and so the built-in code that the splitter window has to compensate for this problem was effective. Your workaround is the proper way to deal with this.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
In other words, the minsize is not overriding the
sashpos, it is just preventing the sash from being sized any smaller
than that due to the tiny size of the splitter before the initial
layouts are done.
So if I understand correctly, the minsize setting is (initially, when
the splitterwindow is still very small) changing the sash position
because honouring 0 would make the (left) panel smaller than minsize? If
this is the explanation, I'd still call this a bug. The minsize setting
goes for both panels. Therefore, initially, if the left panel is too
small, the right panel will be too small as well. Changing sashpos might
make one better, but will then make the other worse.
I even looked at the C++ source code to see if I could fix this, but I
couldn't find out how/where to detect this special case. (Though I do
know C, I don't speak C++, so my chances were slim to begin with.) A
pity (for me), as I don't like the splitter window's resize behaviour
much and would have taken a stab at fixing that as well.
Anyway, thanks for persisting in explaining things to me, it is much
appreciated.
One last thing: I haven't been able to make the sash itself visible, no
matter what combination of flags I've tried. (I once managed to make it
sort-of visible by making the two panes sunken, but I don't want to do
that as it is hideously ugly.) Is there a way to influence how the sash
is displayed that actually does something?