I have now updated the module to use event-based notifications instead
of polling: 
The original question still stands: is it worth exposing this sort of
abstraction as a part of wxHaskell?


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:
wxhaskell-users mailing list

Reply via email to