Re: [wxhaskell-users] Fwd: UI updates from non-UI threads: an addition to wx?
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 > abstraction as a part of wxHaskell? Since no other one seems to answer ... I would like to see this functionality in a package, either a separate package or integrated in wx. In any case I think that the wx/wxcore package bundle must contain a function for providing us with free(!) event ids. This cannot be done reliably in a third party package. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Fwd: UI updates from non-UI threads: an addition to wx?
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, 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 > 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
Re: [wxhaskell-users] Fwd: UI updates from non-UI threads: an addition to wx?
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 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). -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Fwd: UI updates from non-UI threads: an addition to wx?
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). -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
Re: [wxhaskell-users] Fwd: UI updates from non-UI threads: an addition to wx?
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: http://snipplr.com/view/17538/ 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. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
[wxhaskell-users] Fwd: UI updates from non-UI threads: an addition to wx?
Including wxhaskell-users. Anyone interested in async UI update functionality? Cheers, Maciek -- Forwarded message -- From: Date: Fri, Aug 24, 2012 at 10:41 PM Subject: UI updates from non-UI threads: an addition to wx? To: wxhaskell-devel Getting wxHaskell to handle UI updates from non-UI threads was a frustrating experience; it's embarassing how long it took me to realise that the solution presented in this StackOverflow answer: http://stackoverflow.com/a/3182588/424978 is probably the only viable one. I've packaged it into a tiny module that provides Gtk2hs-style `postGUIAsync` function: https://github.com/mmakowski/habaz/blob/master/src/Graphics/UI/WX/Async.hs. Is there any interest in incorporating this into wxHaskell proper? It might save other users some head scratching. Regards, Maciek -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
