I have now updated the module to use event-based notifications instead of polling: https://github.com/mmakowski/habaz/blob/master/src/Graphics/UI/WX/Async.hs. The original question still stands: is it worth exposing this sort of abstraction as a part of wxHaskell?
Regards, Maciek On Wed, Sep 26, 2012 at 9:43 PM, <maciek.makow...@gmail.com> wrote: > Thanks for this, and for responding to the SO question. I'll see if I > can rewrite the run async abstraction using your solution. > > Cheers, > Maciek > > On Wed, Sep 26, 2012 at 8:30 AM, Henning Thielemann > <lemm...@henning-thielemann.de> wrote: >> >> On Wed, 26 Sep 2012, Henning Thielemann wrote: >> >>> However, it seems to be essential what eventId you use. The value in the >>> above example (wxID_HIGHEST+1) was already used in my system and this lead >>> to strange behavior. I think wxhaskell should provide support for finding >>> free event ids. >> >> >> >> If you want to see this technique in action: >> http://code.haskell.org/alsa/gui/src/controller.hs >> http://code.haskell.org/alsa/gui/src/Common.hs >> >> I have implemented both the busy wait (reactOnEventTimer) and the >> event-driven method (reactOnEvent). ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
