Caution: What follows is based on my understanding of the current
(1.1.9) behaviour and may not reflect the behaviour of 1.1.7. I know
that a lot of this changed, I think in 1.1.8 it was enhanced a fair bit!
> Thanks Ian. I got the sense that Fl::awake(...) is used
> specifically to send a *message* to the application's main
> thread, and that application logic (rather than FLTK code)
> was meant to act on that message.
Well, it might be better to think of Fl::awake() with no parameter as a
sort of inter-thread Fl::redraw() mechanism.
The message is handled by the fltk logic internally, but the last
message is also available (via thread_message) if the app layer wants to
access it, but that really only returns the last message actioned (not
the awake queue) so is not necessarily all that useful. I have never had
cause to use that ability, others may take a differing view, of
course...
> In my case, where Fl::run() (rather than application code) is
> executing on the main thread, is it still okay for me to
> Fl::awake()? And if so, what argument(s) should I provide to
> Fl::awake()?
You don't have to provide any arguments at all, in which case it behaves
kind of like calling redraw() in an inter-thread way (see above) but if
you do pass some parameters, then the interesting case for you might be
the:
int awake(void (*callback)(void*), void *userdata);
case, where you can pass in a pointer to a callback function (perhaps
even your onMessage function, that sort of thing) and when the fltk core
subsequently actions your awake message, it will execute that callback.
For example, this might allow you to have the main thread run the
subsidiary threads GUI update code for you, thus allowing the GUI to be
updated under the control of the main thread, thus obviating the need to
lock/unlock...
Of course, under the covers, awake is locking a mutex to access the
queue of awake events, so you might actually be no better off than using
Fl::lock directly, but it might be worth a shot as an alternative... I
still can't figure why the basic lock is taking so long to action...
That does seem very strange.
SELEX Sensors and Airborne Systems Limited
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
