Hello!
What is the best way in HaxeUI to have long-running/time-consuming functions called e.g. in button click handler? So UI is not blocked…
E.g. when reading TCP socket or loading huge file. For instance, in Qt, such time-consuming IO is integrated in the event loop itself, so the handler gets called with the subsequent chuck of data read. Is there anything like this in HaxeUI?
Hi, sorry, i missed this somehow 
So currently there is no concept of “main thread” inside haxeui, but it might be something worth exploring. What backend out of curiosity?
Cheers,
Ian
Hi Ian,
I believe this is backend-agnostic topic, but we can consider three most relevant: OpenFL, wxWidges and HTML5. So for instance, if the button click handler takes 10 seconds to execute - do we get 10 seconds freeze of the app? How can we avoid it?
Hi Zura,
It may very well be backend agnostic, but its very platform / framework specific. For example, in haxeui-html5, you’ll need web workers, for wxWidgets you’ll need threads (or expose a wxWidgets function to allow this deferred execution), for OpenFl, you could use threads or webworkers depending on the OpenFL target - this is what i mean by “nothing in core” - certainly not saying its a bad idea, just not something that is instantly obvious where to start.
I wonder if something like this: https://github.com/vegardit/haxe-concurrent
Would “just work” as user code… … ?
Cheers,
Ian
Hi Ian,
Another option could be to expose functions such as wxYield from wxWidgets. Not sure about HTML5 and OpenFL counterparts. So for instance, when you load (and maybe parse) a huge file, UI is not frozen, progress bar is being updated, user is able to press Cancel button, etc…
Yeah, that would be the first step, and then abstract it somehow so it can be used in haxeui… maybe “Platform.yeild” or something might be a good place - ill have to check it out and see… Im not sure how you would achieve the same in, say, openfl… probably threads…
Ian
Oh, i wonder if the “EventLoop” (haxe class / system) could help… 