On 03/16/12 20:10, Adam wrote:
> So I am building a program with a "status bar." ..
> when I try redraw() [..] for the bar itself
> the program seems to ignore me and draw the
> new status ontop of the other.
This is likely because the widget has no background
of its own, so it just redraws the text.
Set the box() for the widget to be FL_FLAT_BOX
or FL_XXX_BOX instead of FL_XXX_FRAME.
FL_XXX_FRAME's are see 'through', and assume that
the background is managed by the widget above it.
But in your case you want the widget to manage
its own background, so give it a solid box type
so when you redraw() it, it draws its own bg too.
Use redraw() so that it draws the whole widget,
including the widget's bg (once you change the
widget to include an FL_XXX_BOX). I don't think
you should call redraw_label().
> I can call redraw on the window and this fixes the draw over issue but it
> wont update until something external to this process causes the window to
> refresh (mouse move, keyboard input, etc). What is causing this?
Keep in mind calling redraw() just /schedules/ a redraw,
it does not actually redraw.
Sounds like there's another issue afoot; your program
is probably 'blocking' between changes, and not giving
cpu to the FLTK event loop so that it can actually /do/
the redraw()s you've scheduled.
To update the status bar between operations that may
block, you should at least call Fl::check() after calling
redraw() to force FLTK to fixup anything that's changed,
since you're not returning to the event loop.
Probably make a UpdateStatus(const char *s) method
that does the following:
void YourWidget::UpdateStatus(const char *s) {
status_widget->label(s); // change the widget's label
status_widget->redraw(); // force redraw of widget
Fl::check(); // give some cpu to fltk to handle
actual redraw
}
Thing is, if you're doing operations that block, you
probably should be doing them in a separate thread,
so that the main thread can be running the fltk event
loop to keep the interface alive.
Often network operations will take a while to run,
so if you want the UI to 'stay alive' enough to
handle buttons that cancel operations, etc.
use separate threads.
Remember when netscape was single threaded?
You'd type in a URL and hit 'Enter' and the whole
interface would /freeze/ while DNS would resolve
the url's hostname, and while the app was waiting
for data to come from the webserver, the interface
was dead too. There was no 'X' button to cancel
loading the page; you had to /wait/ until either
the web server answered, or the TCP connection timed out.
When they added threads, that all became workable.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
