On Thu, Jul 26, 2012 at 2:15 PM, Russel Winder <russel@winder.org.uk> wrote:

> 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.winder@ekiga.net
> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>

I totally agree with separation of GUI and logic. The problem is, that the engine should be generic, so there's no way of determining whether the incoming handler is big enough for a thread or not.

What is Microsoft's MVP variant of MVC?

-- 
Bye,
Gor Gyolchanyan.

On Thu, 2012-07-26 at 14:33 +0400, Gor Gyolchanyan wrote: […]
> I totally agree with separation of GUI and logic. The problem is, that the engine should be generic, so there's no way of determining whether the incoming handler is big enough for a thread or not.

But the engine should not be making those decisions, they have to be made by the callback.

> What is Microsoft's MVP variant of MVC?

Google is your friend ;-)

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter http://www.codeproject.com/Articles/288928/Differences-between-MVC-and-MVP-for-Beginners http://stackoverflow.com/questions/2056/what-are-mvp-and-mvc-and-what-is-the-difference

Sadly there is also a lot of real rubbish on the Web purporting to be quality information, as is highlighted in one or two of the answers on StackOverflow :-(

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 2012-07-26 11:45, 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?

It should be possible to have other threads interacting with the GUI as long as they do that by sending messages to the thread responsible to for GUI. Here's an example of an SWT snippet that does GUI manipulation from a different thread:

http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet130.java

On line 42 a new thread is created. On line 48 the GUI is changed, by adding a string to some text widget. But this happens using the "display.syncExec" method. This force the code to be executed on the GUI thread instead of the current thread.

-- 
/Jacob Carlborg

On Thursday, 26 July 2012 at 09:46:26 UTC, 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.

Are you sure you can create a complex window fast enough when every operation is asynchronous? I usually find applications built with complex ui frameworks start slow. Isn't it because it takes long to create a window going through all the framework infrastructure?

About separation of ui logic and business logic I suggest to look at MVVM pattern (or PresentationModel according to Fowler's terminology). Well, it doesn't allow ad-hoc code and implies extensive design work for every View, but by ensuring that the ViewModel contains only plain data, you're guaranteed that business logic is separated from ui logic.

>"Russel Winder"  wrote in message news:mailman.675.1343290603.31962.digitalmars-d@puremagic.com...
> So if Windows is really doing multi-threaded widget management, this
>would be very interesting.  Where is the material that I can look at
>that leads you to say that Windows is a multi-threaded UI.

At the moment I can only post this, as I am at work and don't have much time to search for info.

[quote]The system maintains a single system message queue and one thread-specific message queue for each GUI thread.[/quote]
http://msdn.microsoft.com/en-us/library/windows/desktop/ms644927%28v=vs.85%29.aspx

--
Paulo

On 26/07/2012 09:16, Russel Winder wrote:
> On Wed, 2012-07-25 at 23:17 +0200, Kagamin wrote:
>> On Wednesday, 25 July 2012 at 18:50:51 UTC, Simon wrote:
>>> You have to be very, very careful with trying to do multi
>>> threading w/ windoze windows. Try doing a google search on it,
>>> and the advice is invariably: don't do multi threaded windows.
>>> Everybody including people famous for their in-depth window
>>> knowledge recommends a single thread UI with non-UI worker
>>> threads.
>>
> So if Windows is really doing multi-threaded widget management, this
> would be very interesting.  Where is the material that I can look at
> that leads you to say that Windows is a multi-threaded UI.

On 'doze every thread can have it's own message pump and therefore it's own UI, but if you have an ancestor/descent relation between 2 windows they must belong to the same thread.

Otherwise you are pretty much guaranteed a deadlock, unless you only ever use MsgWaitForMultipleObjectsEx to synchronise. But that's kinda of unachievable unless you have written every single line of code yourself.

So you can have threads with separate UIs as long as you don't make the windows of one thread the child of another.

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

Am 26.07.2012 19:15, schrieb Simon:
> On 26/07/2012 09:16, Russel Winder wrote:
>> On Wed, 2012-07-25 at 23:17 +0200, Kagamin wrote:
>>> On Wednesday, 25 July 2012 at 18:50:51 UTC, Simon wrote:
>>>> You have to be very, very careful with trying to do multi
>>>> threading w/ windoze windows. Try doing a google search on it,
>>>> and the advice is invariably: don't do multi threaded windows.
>>>> Everybody including people famous for their in-depth window
>>>> knowledge recommends a single thread UI with non-UI worker
>>>> threads.
>>>
>> So if Windows is really doing multi-threaded widget management, this
>> would be very interesting.  Where is the material that I can look at
>> that leads you to say that Windows is a multi-threaded UI.
>
> On 'doze every thread can have it's own message pump and therefore it's
> own UI, but if you have an ancestor/descent relation between 2 windows
> they must belong to the same thread.
>
> Otherwise you are pretty much guaranteed a deadlock, unless you only
> ever use MsgWaitForMultipleObjectsEx to synchronise. But that's kinda of
> unachievable unless you have written every single line of code yourself.
>
> So you can have threads with separate UIs as long as you don't make the
> windows of one thread the child of another.
>

Every thread that creates a window will get a message queue created and assigned (It's then called a GUI thread).
Under normal circumstances your thread will enter an event loop where you call the GetMessage/DispatchMessage function pair. GetMessage gets only messages from the threads message queue and DispatchMessage dispatches only to the windows owned by the thread.

You can get into troubles when you send a message via SendMessage from thread A to a window owned by thread B and the event loop of thread B does not handle this message (e.g. by having a modal dialog opened in thread B). In this case thread A is blocked until the message is processed by B's event loop.

SendMessage is often used in code dealing with Parent/Child window relations, so the warning above is justified. But as long as your child window event loop is not blocked (or some other access to a shared resource creates a deadlock) it works.

There is a technical article about multithreaded GUI and Win32 on MSDN. See
http://msdn.microsoft.com/en-us/library/ms810439.aspx

On Thursday, 26 July 2012 at 17:15:23 UTC, Simon wrote:
> On 'doze every thread can have it's own message pump and therefore it's own UI, but if you have an ancestor/descent relation between 2 windows they must belong to the same thread.

I meant, you can, say, set window text from non-ui thread directly and it will probably succeed, while normally the control should check and throw if current thread doesn't match ui thread.