Eric,
sorry, you missunderstood my proposed solution.
I wanted to suggest to NOT put additional events into whatever queue Iup
uses behind the scenes.
Instead better maintain you own queue and process this before you complete
Iup's queue once using IupFlush.
On Apr 18 2018, Eric Wing wrote:
It's easy to see the problem you're facing.
I'm no IUP expert, however I'm pretty positive that this can be solved
without introducing another API.
In a similar situation I have been able to abstain from using the
complete IUP abstraction around the main loop and resort to using
IupFlush() instead. Doing so allows to queue requests from other threads
for execution
in the GUI thread, which processes said queue right before calling
IupFlush().
Once I had these roughly 40 lines of code in place begin factoring out
IupFlush()s and run them just once before IupFlush() to reduce some
flickering.
Maybe such an approach can work for you too.
Thanks for the idea. But I don't think IupFlush() addresses the problem.
IupFlush() solves a problem of needing to process a request
immediately already in the event queue.
But the missing piece of the puzzle is *how to put an event (from
another thread) into the event queue*.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Iup-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/iup-users
