While developing our project λPage, we've found something we like to
share with you all.
We have an application with a main window and we want to update a
part of the window (in this case, a textbox) while letting the user
work with the rest of the UI.
To accomplish that, we need to parallelize things and the natural way
of doing so is using Control.Concurrent.forkIO.
So, we have the main thread that handles the UI (like all wx apps do)
and another one, started with forkIO, that periodically updates a
textbox using textCtrlAppendText.
Then we noticed that the forked thread only worked when the user
*actually* used the UI, i.e. if the user just waited to see the new
values appear in the textbox, those updates never happened. But in
the very instant he moved the mouse or touched a key, BOOM, the
textbox was updated.
We found out what was going on and I think Jeremy will explain it
better than me (maybe as an article in his blog? :P), but the basic
idea is that the main loop of any wxHaskell application is running in
C and the wxHaskell functions are only used as callbacks, so once the
control returns to the C loop it doesn't come back to Haskell world
until "something happens" (i.e. some event is triggered by the UI).
We worked around the issue by adding a "keep-alive" timer that ticks
every 50ms, but that's not the most elegant solution, isn't it?
Anyway, to prove our point I've developed a tiny example that I'm
attaching to this mail. To try it, once compiled and running, use the
"Actions" menu to start the logger and then start and stop the timer.
If you do nothing else in the application, you should see that it logs
only when the timer is ticking.
I hope this helps as it was really hard to understand and work
Get latest updates about Open Source Projects, Conferences and News.