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.