On Thu, 2012-07-26 at 13:45 +0400, Gor Gyolchanyan wrote: > So the good way to do this will be to have a single thread, which pumps > messages and distributes the appropriate message handlers to worker > threads, right? > > My goal here is to have 100% working and responsive GUI no matter how bad > the application lags. If, for instance, The user would push a button, which > initiates a very expensive computation, I don't want the GUI to become > stuck. If the user doesn't wait and pushes the button again, it should > display a message, which says "The operation is already in progress" or > something like that.
Your goal is excellent. Throughout the early 2000s my staff had to suffer the stupidities of software development environments that failed to take this message on. The "standard model" for doing this is for user event callbacks to always act and if they need to do something that takes longer than a very few instructions and/or takes more that a fraction of second (NB user reaction time is around 0.2s, user boredom time is around 2s) spawn a thread to undertake the work. If that then involves interaction, the thread puts an event on the event queue and terminates. Separation of concerns is also important here: no business logic in the GUI code, no GUI code in the business logic. MVC (*), Mediator, Façade, are your friends. (*) Microsoft's MVP variant of MVC is probably very appropriate on Windows. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
