I'm fairly sure I have not understood your explanation, so what follows is likley to be wrong. However, on the basis of what I *think* you asked, I don't think this is going to work as you describe it. It may be possible to dig into the internals of fltk and expose more of the event handling, to make what (I think that) you want possible, but not with a "vanilla" fltk build.
Anyway, more comments interleaved below... > I'm working on an app that drives fltk from a client program. I'd > like to be able to pass events out to the client and also for the > client to be able to run things in fltk. OK, first things first. Which fltk variant? What host platform(s) are you targeting? Do your "client" and "server" run on the same host, or over a network from different hosts, or both? Are you convinced you have "client" and "server" the right way round for what you hope to achieve? > So on the client end I have > a thread which sits in a Fl::wait() loop. When the client wants to do > some fltk stuff, it sticks the actions in a queue and calls > Fl::awake(0). When wait() returns, it goes through the queue and does > the actions. Now I want to be able to pull all of the UI events that > have happened and do something with them on the client end. You might have to draw me a picture of this, with bright primary colours, as I don't think I'm following the words... > The problem is I can't see any kind of guarantee that exactly one > event was delivered since the last time wait() returned, so I can't > use the Fl::event_* functions directly. This is where I think you might have to get in amongst the low-level internals... > One way I came up with to do this is for each window to keep a queue, > and its handler append the event to the queue before going about its > business. Then when wait returns I can go through each of the windows > and clear out their queues. This seems like it would work but also > seems clumsy. Isn't there a better way? I'm not sure. If you can tell us what it is you are actually trying to do (at the high level) rather than how you have gone about doing it, maybe someone here will have alternative approaches that might be more fruitful. > Also, since I am only ever calling FLTK from one thread, I don't think > I need all the locking and unlocking. Is there a simpler way to > interrupt wait()? I gather I could wait on an fd, but that seems > harder than just calling Fl::awake(). If I could deliver a custom ui > event that said "message arrived", I could know that wait() returns on > every arriving event, and dispense with the per-window queues. Actually, waiting on an fd is very easy and reliable - except maybe it doesn't always work so well on win32 systems, unfortunatley, due to win32's odd ways... 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
