Stan wrote:
>>> I'm sort of guessing, but I think you just have to put
>>> scrlBar->redraw() at the end.
>> I've tried of course, but it doesn't work.
Yes, typically that's the cause. But in this case, apparently not.
Looking at the code for Fl_Scroll::draw(), it appears the calculations
for determining if scrollbars should be on or off are being done at
draw time,
i.e. in Fl_Scroll::draw(), and /not/ in Fl_Scroll::resize() where one
might expect it to be.
> Ah, I see. Well, until someone can give you a real answer,
> here's a horrible hack that seems to work
>
> [..]
> void draw()
> {
> Fl_Scroll::draw();
> if(scrollbar.visible() && hscrollbar.visible()) {
> color(FL_GRAY);
> }
> else {
> color(FL_WHITE);
> }
> Fl_Scroll::draw(); // again
> }
> };
Given how the scrollbar visibility is being calculated, I'd say
the above seems to be 'consistent' with how Fl_Scroll is written.
I'd suggest to the OP that you derive from Fl_Scroll, and not the
window,
since all this logic is with respect to the scroll and its contents.
This won't help the resize() code work, but it will be a bit 'cleaner'
implementation-wise.
I'm thinking that since you have an Fl_Double_Window, you won't see
a 'flash' when you call draw() twice, but it does kinda suck draw()
has to be called twice to update the scroll visibility logic.
The other way would be to copy/paste the visibility logic into
your draw() code, so that you don't have to call draw() twice
to get the visibility calculations to update.
Maybe the core folks have a better suggestion, I'm not sure I see one.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
