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.