Hi all, 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 around :) |
Main.hs
Description: Binary data
------------------------------------------------------------------------------
_______________________________________________ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users