I've run into a problem that has me quite baffled. I'd love to post a
bit of code but it's so ingrained in the application it would take me
some considerable effort to make a readable, demostrative app.
My biggest problem stems from the fact that I don't quite understand
the underlying mechanism of sizers. Here's the problem:
I've a ScrolledWindow that, among some default widgets, contains a
PyWindow derived class I created as a sort of StaticText. It's capable
of either wrapping long text into several lines, or cropping the
visible text and adding a "..." at the end of it, among other things.
While I've squashed out all the kinks of the ellipsis method, the
wrapping one presents some problems.
The biggest problem lies with the containing ScrolledWindow. The
custom widget reads the available width correctly and sets a new
height for the control based on how many extra lines of text are
needed, but the ScrolledWindow, at some point during its Layout phase,
misreports the available width to the widget, a much lesser value,
resulting in way more text lines than needed, and uses this incorrect
size to size its virtual area.
At drawing time, the widget is drawn and sized correctly, but the
extra space in the scrolledwindow is covered up by whatever remaining
controls have a proportion greater than 0.
I know this is very enigmatic without some code, so I'll rephrase my
question; what steps and functions are involved when it comes to
Layout()? Does the children mandate the parent's size, is it the other
way around? Both? Which events are involved?
I've run into a problem that has me quite baffled. I'd love to post a
bit of code but it's so ingrained in the application it would take me
some considerable effort to make a readable, demostrative app.
My biggest problem stems from the fact that I don't quite understand
the underlying mechanism of sizers. Here's the problem:
I've a ScrolledWindow that, among some default widgets, contains a
PyWindow derived class I created as a sort of StaticText. It's capable
of either wrapping long text into several lines, or cropping the
visible text and adding a "..." at the end of it, among other things.
While I've squashed out all the kinks of the ellipsis method, the
wrapping one presents some problems.
Sounds like a useful widget.
The biggest problem lies with the containing ScrolledWindow. The
custom widget reads the available width correctly and sets a new
height for the control based on how many extra lines of text are
needed, but the ScrolledWindow, at some point during its Layout phase,
misreports the available width to the widget, a much lesser value,
resulting in way more text lines than needed, and uses this incorrect
size to size its virtual area.
At drawing time, the widget is drawn and sized correctly, but the
extra space in the scrolledwindow is covered up by whatever remaining
controls have a proportion greater than 0.
I know this is very enigmatic without some code, so I'll rephrase my
question; what steps and functions are involved when it comes to
Layout()? Does the children mandate the parent's size, is it the other
way around? Both? Which events are involved?
Basically when the window that has a sizer gets a EVT_SIZE event, that results in window.Layout being called. This runs the layout calculation and gets info from each of the widgets and sizers contained in the sizer about their minimum and best sizes, along with the other sizer item attributes, then it makes another pass and actually positions and sizes the items that need it. If any of them have a sizer, or is a sizer, then the process is repeated recursively for them.
ยทยทยท
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!