Hi, The thread situation is generally used when the application actually do multiprocessing of somehow.
> What do IUP users typically do when they have a long running process they need to provide UI feedback on, but can't break the long running process up into time slices suitable for IupTimer? Just for a long running process, to free the interface and allow the user to interact with a cancel button for instance, you just have to call IupLoopStep from inside your long loop. Calling IupLoopStep several times will allow the events to be processed. You can implement a counter for instance, that displays progress by calling a function from inside your loop and in that function call IupLoopStep and also update a IupGauge or IupProgressBar in your interface. Best, Scuri Em qui, 4 de jul de 2019 às 18:29, Matthew Kennedy <burnsid...@gmail.com> escreveu: > I'm a bit stumped on how to communicate with the IUP thread from another > thread. > > Are the options basically polling from idle action, or an IupTimer > callback? I measured the idle action overheard and it's basically 8% of a > CPU core and so an IupTimer seems better. If I use an IupTimer though, I'll > need to pick a timer rate. I could queue up the functions I want to run on > the main thread and drain the queue on a single IupTimer callback, though. > > Another approach perhaps is to set a semaphore on the non IUP thread when > assigning the idle function (i.e. when calling IupSetFunction for > IDLE_ACTION) and then signaling the semaphore on the IUP thread from > *within the callback* just before it returns IUP_IGNORE. This has it's own > problems though, since the callback's not really complete until IUP_IGNORE > *is* returned. Hmmm... > > What do IUP users typically do when they have a long running process they > need to provide UI feedback on, but can't break the long running process up > into time slices suitable for IupTimer? > > Matt > > > > > On Thu, Jul 4, 2019 at 2:31 PM Antonio Scuri <antonio.sc...@gmail.com> > wrote: > >> No, there isn't. Once the idle is set, it will be called the next time >> the MainLoop regain control. But your are setting from another thread so >> the mainloop is running. Maybe the solution would be to set the idle in the >> main loop thread where you can have more control about that. >> >> Best, >> Scuri >> >> >> Em qui, 4 de jul de 2019 às 15:18, Matthew Kennedy <burnsid...@gmail.com> >> escreveu: >> >>> Hi, >>> >>> I've trawled through the mailing list archives trying to research this. >>> I hope I haven't missed a solution to this already: >>> >>> I have IUP's main-loop running on thread, and I have another thread that >>> needs to update something in the GUI. I gather it's not safe to call IUP >>> functions from a NON IUP main-loop thread, so I've settled on acquiring a >>> lock on and setting the IUP idle function to a function that includes the >>> work needed to be performed by the non IUP main-loop thread (returning >>> IUP_IGNORE, so as to run once). >>> >>> This works pretty well, but I believe if the NON IUP main-loop thread >>> sets IUP idle function faster than the idle function is called by IUP, then >>> my IUP idle functions will not always be called. Is there a way to set the >>> idle function and wait for it to be called? Or even some way to set the >>> idle function and trigger it to run immediately? >>> >>> Matt >>> _______________________________________________ >>> Iup-users mailing list >>> Iup-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/iup-users >>> >> _______________________________________________ >> Iup-users mailing list >> Iup-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/iup-users >> > _______________________________________________ > Iup-users mailing list > Iup-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/iup-users >
_______________________________________________ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
