On 11/04/11 08:51, David wrote:
> I was aware that the window my not redraw, but I can't
> really call it because it will be on things like device access
> using lower level routines that don't know anything about any
> UI and the device to respond may take awhile. I know I could
> thread, but it's all (deivce access/other things) intermixed
> with UI stuff.
If you want to post a dialog from a thread, I can think
of at least two ways, as I've had to do this before myself:
A. Have the child thread send a message to the parent
telling it to open the dialog with a message.
(Use an FLTK timer to monitor for messages)
This can be used for all kinds of 'messages'
between child threads and parent, and allows
a simple way for the two to talk to each other.
The message class you make would handle doing
the locking to ensure the messages move between
threads without races and deadlocks.
B. Have the thread start a new process to post the dialog.
This can be done easily by having the program recurse;
create a special command line argument for your program
that just opens a dialog window and exits. eg:
eg. 'yourprogram -dialog "Some message"'
You could have it read stdin for the message instead
(to avoid quoting issues). Then in your thread
invoke the program with popen() or the like to post
the dialog.
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
