Re: How to get around new limitations on SetForegroundWindow()?

From: Dean Roddey (droddey_at_charmedquark.com)
Date: 03/23/04 

Date: Mon, 22 Mar 2004 20:01:13 -0800

"John Carson" <donaldquixote@datafast.net.au> wrote in message
news:eBq5dOHEEHA.684@tk2msftngp13.phx.gbl...

> I don't follow exactly what you are doing. MSDN has the following to say
> about message queues.
> "The system maintains a single system message queue and one
thread-specific
> message queue for each graphical user interface (GUI) thread. To avoid the
> overhead of creating a message queue for non–GUI threads, all threads are
> created initially without a message queue. The system creates a
> thread-specific message queue only when the thread makes its first call to
> one of the User or Windows Graphics Device Interface (GDI) functions."
>
> Since you say that you have a GUI running on the client desktop, I would
> arrange for the GUI to make the necessary function calls.
>
>

There is a server app, which is a GUI app, but it is (via an ORB) serving
many possible incoming clients. Each of those clients is controlling an
application indirectly via the server program. The ORB just has a thread
pool, so those incoming requests to do somethign to their controlled
applications will get served via whatever thread happens to pick up their
command packet from the ORB. But, I know that the message queue is getting
created because the Attach command won't work unless it has a message queue
and it is successful. So clearly they have the required message queue. Since
I have to call GetForegroundWindow() in the process of doing the
attach/detach stuff, that causes the message queue to get created, since
they are faulted as needed.

So I do have a GUI app running there, it's just that it is a server program
also and the real work is being done on background threads within that app.
If this scheme will only work within a thread that actually has a window,
that would mean that the main thread of the server would have to do the
commands. But having the main GUI thread issue these threads would be very
sub-optimal. It would require having to come up with a packet format to
package up all of the possible incoming commands so that they can be queued
to the main thread, and that would require lots of synchronization between
the background threads and the main thread since they would have to block on
an event in the queued commands in order to get the status back out of them,
etc... That would be pretty ridiculous to have to go through all that just
to get past this one problem.

Relevant Pages