| |
| |
On 8/14/22 04:09 lifeatt...@gmail.com wrote:
Trying your program on Linux / gcc / FLTK 1.4, I get the same behavior
you describe.
Thanks, Kevin, for testing. I didn't find the time but your test results
are to the point.
As far as I can tell, the issue is tied to calling move_to() from
inside the Scroll_B::draw() function. I don't understand _why_ it's a
problem. Every change
I tried to force Scroll_C to be redrawn failed.
The draw() method is meant to ... draw things, not to change the
widgets. [Side note: unfortunately we *have* widgets that change their
layout in draw(), namely Fl_Pack, which can lead to unexpected behavior.]
Calling redraw() on a widget means to set all damage() bits in the
widget's status. If you do this inside draw() of the widget these
damage() bits will be cleared after draw() which means that you can't
effectively call redraw() inside draw(). You *may* call it on other
widgets but you should not assume any drawing order to avoid undefined
behavior.
I'm not sure if this is exactly the effect in the original test program,
but users should always respect the rule not to change widgets inside
draw() to avoid unexpected / undefined behavior.
I attach my modified version of ScrollB which provides the behavior I
think you want. I moved the invocation of move_to() outside the
Scroll_B::draw()
method, into a callback function for ScrollB's vertical scrollbar.
Excellent! Without checking the code in detail or testing it myself (I
only read your code quickly), this is generally how it should be done.
Thanks for investigating and helping!
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/058e531c-172a-ab03-ff4e-9461b3704e5f%40online.de.
[ Direct Link to Message ] | |
|
| |
