Hi!

I'm trying to write a WinAPI example to have multi-threaded GUI. I wanna have a Window class, which creates a window and listens to its messages in a separate thread when constructed.  This will allow me to write a main function like this:

void main()
{
    Window w = new Window;
    w.move(100, 200);
    w.resize(800, 600);
    w.show();
}

The methods called for the window will send asynchronous messages, which will cause the window to change its position, size and visibility on-the-fly. This is convenient, because no message loop needs to be launched separately and every window will rocess its messages in a separate thread.

Can anyone please tell me how to achieve this?

-- 
Bye,
Gor Gyolchanyan.

On 25/07/2012 19:34, Gor Gyolchanyan wrote:
> Hi!
>
> I'm trying to write a WinAPI example to have multi-threaded GUI. I wanna
> have a Window class, which creates a window and listens to its messages
> in a separate thread when constructed.  This will allow me to write a
> main function like this:
>
> void main()
> {
>      Window w = new Window;
>      w.move(100, 200);
>      w.resize(800, 600);
>      w.show();
> }
>
> The methods called for the window will send asynchronous messages, which
> will cause the window to change its position, size and visibility
> on-the-fly. This is convenient, because no message loop needs to be
> launched separately and every window will rocess its messages in a
> separate thread.
>
> Can anyone please tell me how to achieve this?
>
> --
> Bye,
> Gor Gyolchanyan.

It depends exactly on what you are trying to do, but in general:

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.

Having completely separate top level windows each in it's own thread is ok, but if you want to have a parent/child relation between windows in different threads, then you can not use any thread synchronisation primitives all at other than MsgWaitForMultipleObjectsEx, otherwise you will have a guaranteed deadlock. In which case you'd have to do all of the threading your self and not use anything in phobos.

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

On Wed, Jul 25, 2012 at 10:50 PM, Simon <s.d.hammett@gmail.com> wrote:

> On 25/07/2012 19:34, Gor Gyolchanyan wrote:
>
>> Hi!
>>
>> I'm trying to write a WinAPI example to have multi-threaded GUI. I wanna have a Window class, which creates a window and listens to its messages in a separate thread when constructed.  This will allow me to write a main function like this:
>>
>> void main()
>> {
>>      Window w = new Window;
>>      w.move(100, 200);
>>      w.resize(800, 600);
>>      w.show();
>> }
>>
>> The methods called for the window will send asynchronous messages, which will cause the window to change its position, size and visibility on-the-fly. This is convenient, because no message loop needs to be launched separately and every window will rocess its messages in a separate thread.
>>
>> Can anyone please tell me how to achieve this?
>>
>> --
>> Bye,
>> Gor Gyolchanyan.
>>
>
> It depends exactly on what you are trying to do, but in general:
>
> 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.
>
> Having completely separate top level windows each in it's own thread is ok, but if you want to have a parent/child relation between windows in different threads, then you can not use any thread synchronisation primitives all at other than MsgWaitForMultipleObjectsEx, otherwise you will have a guaranteed deadlock. In which case you'd have to do all of the threading your self and not use anything in phobos.
>
> --
> My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
>
>
>
I see. Thanks for the reply. Somehow I suspected this to be the case.

-- 
Bye,
Gor Gyolchanyan.

On 25-Jul-12 22:34, Gor Gyolchanyan wrote:
> Hi!
>
> I'm trying to write a WinAPI example to have multi-threaded GUI. I wanna
> have a Window class, which creates a window and listens to its messages
> in a separate thread when constructed.  This will allow me to write a
> main function like this:
>
> void main()
> {
>      Window w = new Window;
>      w.move(100, 200);
>      w.resize(800, 600);
>      w.show();
> }
>
> The methods called for the window will send asynchronous messages, which
> will cause the window to change its position, size and visibility
> on-the-fly.

Use plain WinAPI SendMessage in all threads and one separate thread for GUI message pump.
In fact you can change shape and visibility of any window in a system. And you do not need to be superuser. Hence proliferation of locker type Trojans. Who told Windows is boring? ;)

>This is convenient, because no message loop needs to be
> launched separately and every window will rocess its messages in a
> separate thread.
>
> Can anyone please tell me how to achieve this?
>
The problem is that WinAPI event loop was created with single message pump per application. Hence problematic separation of window per thread.

Again that most straightforward (and effective) design is to use 1 thread for all UI and a bunch of workers for other stuff and you are good to go.

Or, in your model, it looks like GUI is a background process, and workers rule it, interesting view esp w.r.t. user perspective :)

-- 
Dmitry Olshansky

On Wed, Jul 25, 2012 at 11:18 PM, Dmitry Olshansky <dmitry.olsh@gmail.com>wrote:

> On 25-Jul-12 22:34, Gor Gyolchanyan wrote:
>
>> Hi!
>>
>> I'm trying to write a WinAPI example to have multi-threaded GUI. I wanna have a Window class, which creates a window and listens to its messages in a separate thread when constructed.  This will allow me to write a main function like this:
>>
>> void main()
>> {
>>      Window w = new Window;
>>      w.move(100, 200);
>>      w.resize(800, 600);
>>      w.show();
>> }
>>
>> The methods called for the window will send asynchronous messages, which will cause the window to change its position, size and visibility on-the-fly.
>>
>
> Use plain WinAPI SendMessage in all threads and one separate thread for
> GUI message pump.
> In fact you can change shape and visibility of any window in a system. And
> you do not need to be superuser. Hence proliferation of locker type
> Trojans. Who told Windows is boring? ;)
>
>
>  This is convenient, because no message loop needs to be
>> launched separately and every window will rocess its messages in a separate thread.
>>
>> Can anyone please tell me how to achieve this?
>>
>>  The problem is that WinAPI event loop was created with single message
> pump per application. Hence problematic separation of window per thread.
>
> Again that most straightforward (and effective) design is to use 1 thread for all UI and a bunch of workers for other stuff and you are good to go.
>
> Or, in your model, it looks like GUI is a background process, and workers rule it, interesting view esp w.r.t. user perspective :)
>
> --
> Dmitry Olshansky
>

Yes. The idea was to programmatically operate on UI objects declaratively. For instance, create a window, change its size, show it, draw on it and never worry about "applying" (in the form of pumping the messages).

I guess the same effect can be achieved by having all windows created in a separate thread and the message ump called in static ~this();

-- 
Bye,
Gor Gyolchanyan.

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.

Hmm... AFAIK it's quite opposite: windows UI is the only UI that works in multithreaded environment, it's just recommended to not do it, because this feature is inconsistent with other UI frameworks, so that you don't get used to wrong programming technique.

On Wednesday, 25 July 2012 at 19:25:09 UTC, Gor Gyolchanyan wrote:
> Yes. The idea was to programmatically operate on UI objects declaratively.
> For instance, create a window, change its size, show it, draw on it and
> never worry about "applying" (in the form of pumping the messages).

Haha, show window and return from main.

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.
> 
> Hmm... AFAIK it's quite opposite: windows UI is the only UI that works in multithreaded environment, it's just recommended to not do it, because this feature is inconsistent with other UI frameworks, so that you don't get used to wrong programming technique.

I know essentially nothing of Windows, but quite a lot about AWT/Swing/JavaFX/GroovyFX, GTK+2, GTK+3, PyGTK, PyGObject, PySide, PyQt4, wxPython, and tkInter. As you say all of these use an single-threaded event loop to manage all widgets. Fundamentally this is because there is only one screen and one window manager, and all widgets need to be manipulated relative to that. Using a single-threaded event loop is the easiest way of avoid deadlock and livelock given that there is a shared resource.

The same message has been learnt in Web servers where the multi-threaded approach has given way to a single-threaded event loop approach.

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.

As Simon mention, just because the UI is single-threaded doesn't mean the application is. Exactly the opposite, good UI-based applications are generally multi-threaded, it is just that there is only one thread running the UI, all the others handle business logic.
-- 
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 Thu, Jul 26, 2012 at 12:16 PM, Russel Winder <russel@winder.org.uk>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.
> >
> > Hmm... AFAIK it's quite opposite: windows UI is the only UI that works in multithreaded environment, it's just recommended to not do it, because this feature is inconsistent with other UI frameworks, so that you don't get used to wrong programming technique.
>
> I know essentially nothing of Windows, but quite a lot about AWT/Swing/JavaFX/GroovyFX, GTK+2, GTK+3, PyGTK, PyGObject, PySide, PyQt4, wxPython, and tkInter. As you say all of these use an single-threaded event loop to manage all widgets. Fundamentally this is because there is only one screen and one window manager, and all widgets need to be manipulated relative to that. Using a single-threaded event loop is the easiest way of avoid deadlock and livelock given that there is a shared resource.
>
> The same message has been learnt in Web servers where the multi-threaded approach has given way to a single-threaded event loop approach.
>
> 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.
>
> As Simon mention, just because the UI is single-threaded doesn't mean the application is. Exactly the opposite, good UI-based applications are generally multi-threaded, it is just that there is only one thread running the UI, all the others handle business logic.
> --
> 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
>

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.

-- 
Bye,
Gor Gyolchanyan.

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