| |
| |
Thanks Ian that was a great answer!
I guess I was being a little cyptic. You did guess what I meant. I would prefer, as you suggested, to put the long task into its own thread, but this would mean a whole load of refactoring which will have to be saved till another day. I tried calling Fl::check + scrapping threads and that works wonderfully :)
> On 21 May 2006, at 17:45, Geoff wrote:
>
> > While my main window is busy doing something long and complicated I
> > create a new thread which shows a new dialog with a please wait
> > message. Once the main app is finished the wait message is removed.
> > The problem is that the actual "please wait" window does get
> > removed but the main window is not refreshed and you can still see
> > parts of the wait message. I've tried calling Fl::redraw,
> > Fl::flush, window->damage, window->redraw. None of these have any
> > effect. The imprint will only go away when I open up some menus in
> > the area where the imprint is.
> > Any ideas how I can get rid of this imprint and refresh the whole
> > window?
>
> Hmm, what platform are you on? What version of fltk?
>
> Also, in particular, when you say "I create a new thread which shows
> a new dialog" do you literally mean you start another thread and make
> fltk calls from that thread, to display the dialog? i.e. Whilst the
> complicated processing goes on in the original "main" thread? (By
> which I mean the thread that the entry point "main" is in.)
>
> That can be pretty dodgy as a general rule, on most platforms, and
> particularly win32 platforms are bad for this...
>
> Basically, if you use the Fl::lock() / Fl::unlock() / Fl::awake()
> methods, you *can* manipulate existing widgets from child threads,
> but any processing that creates new widgets, and in particular
> creates new windows, will give spurious behaviours, perhaps like you
> are describing.
> It's not really a fltk bug, though, rather it is a problem with the
> underlying windowing systems. Under win32, for example, it's not even
> "legal" to create gui objects outside the main thread, but it still
> lets you, and if you do the result varies a lot from win32 version to
> version... X is vaguely similar in this regard.
>
> In your case, it *sounds* like you have created a window in a child
> thread, then removed it, but the main window does not get properly
> redrawn because the WM "knows" the window has not been damaged (since
> no new windows have been thrown from the main thread...) and
> therefore ignores your requests for a redraw.
>
> Your best bet is really to throw and hide the "wait" dialog from the
> main thread, on entry/exit to the processing task. And have the
> processing task call Fl::check(); every now and then to keep things
> updating (I'm assuming you threw a child thread so that it could be
> updating whilst the main thread "concentrated" on the task in hand...)
>
> Or, throw the long processing into the child thread, and only ever do
> gui operations from the main thread.
>
> Or I could have misunderstood your original question and be talking
> bo*****s.
>
> HTH,
> --
> Ian
>
[ Direct Link to Message ] | |
|
| |
