> > On 27 Oct 2011, at 21:38, David wrote: > > > Okay, so my group boxes look and work good execpt for one issue. If = > say you have a main window with one, then pop up something like = > fl_choice. Take that box and overlay the main window so the bottom edge = > of the popup is just above the groupbox line (covering part of the = > text), the text is not redrawn. However, the part within the line is = > always redrawn ok, as it is if your in the box and move out fast. To me = > it looks like the text control isn't getting called to be repainted = > (does it only check the first level because the Text (Fl_Box) is a = > within the group (Fl_Group), not on the main window?). > >=20 > > Where is that code logic performed (search for widgets that are within = > the area to be repainted)? > > The simple workaround may be to request a redraw of the groups parent in = > that case - the group is only painting the items inside what it = > perceives as its bounds, but if the label is outside that bound... = > well...=20 > > Triggering a redraw of the group's parent should cause the label to be = > redrawn though since it will be within the parent's bounds. >
So you're saying the logic is that after a window area is marked as damaged (I presume that's what's happening, but don't know for sure) it is the group that determines if a child should be repainted and it only looks at its bounds (even though the position of a child is window oriented)? Or would it be more in the lines of something like something is only scanning the first level of items in a window / group and if found to be within those bounds that it would then send that group a redraw request? In this case it's a member of a group, and it just protrudes a little above the group bounds. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
