www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Multi-threaded GUI

reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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.
Jul 25 2012
next sibling parent reply Simon <s.d.hammett gmail.com> writes:
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
Jul 25 2012
next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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.
Jul 25 2012
prev sibling parent reply "Kagamin" <spam here.lot> writes:
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.
Jul 25 2012
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
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=20
 threading w/ windoze windows. Try doing a google search on it,=20
 and the advice is invariably: don't do multi threaded windows.=20
 Everybody including people famous for their in-depth window=20
 knowledge recommends a single thread UI with non-UI worker=20
 threads.


=20
 Hmm... AFAIK it's quite opposite: windows UI is the only UI that=20
 works in multithreaded environment, it's just recommended to not=20
 do it, because this feature is inconsistent with other UI=20
 frameworks, so that you don't get used to wrong programming=20
 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.
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jul 26 2012
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
"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
Jul 26 2012
prev sibling parent reply Simon <s.d.hammett gmail.com> writes:
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
Jul 26 2012
next sibling parent KlausO <oberhofer users.sf.net> writes:
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
Jul 27 2012
prev sibling parent "Kagamin" <spam here.lot> writes:
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.
Jul 27 2012
prev sibling next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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.
Jul 26 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
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
Jul 26 2012
prev sibling parent "Kagamin" <spam here.lot> writes:
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.
Jul 26 2012
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
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?
=20
 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, whi=


ch

 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=C3=A7ade=
,
are your friends.

(*) Microsoft's MVP variant of MVC is probably very appropriate on
Windows.
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jul 26 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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 b=




ad

 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=C3=A7a=


de,

 are your friends.

 (*) Microsoft's MVP variant of MVC is probably very appropriate on
 Windows.
 --
 Russel.

 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D

 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?

--=20
Bye,
Gor Gyolchanyan.
Jul 26 2012
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2012-07-26 at 14:33 +0400, Gor Gyolchanyan wrote:
[=E2=80=A6]

 I totally agree with separation of GUI and logic. The problem is, that th=


e

 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-th=
e-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 :-(

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Jul 26 2012
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Jul 25 2012
parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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.
Jul 25 2012
parent "Kagamin" <spam here.lot> writes:
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.
Jul 25 2012