On Sun, 30 Sep 2012, maciek.makow...@gmail.com wrote:
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
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
On Wed, 26 Sep 2012, maciek.makow...@gmail.com wrote:
Including wxhaskell-users. Anyone interested in async UI update functionality?
Am I right that the solution on StackOverflow uses a busy-wait using the
Wx Timer? I think this is a bad idea and I found a better solution at:
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
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
Including wxhaskell-users. Anyone interested in async UI update functionality?
Cheers,
Maciek
-- Forwarded message --
From: maciek.makow...@gmail.com
Date: Fri, Aug 24, 2012 at 10:41 PM
Subject: UI updates from non-UI threads: an addition to wx?
To: wxhaskell-devel