Re: How to get around new limitations on SetForegroundWindow()?
From: Dean Roddey (droddey_at_charmedquark.com)
Date: 03/21/04
- Next message: Dean Roddey: "Re: How to get around new limitations on SetForegroundWindow()?"
- Previous message: Philippe: "Re: How to get around new limitations on SetForegroundWindow()?"
- In reply to: Alexander Grigoriev: "Re: How to get around new limitations on SetForegroundWindow()?"
- Next in thread: James Brown: "Re: How to get around new limitations on SetForegroundWindow()?"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 21 Mar 2004 12:41:16 -0800
"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:uQsPJkwDEHA.3064@tk2msftngp13.phx.gbl...
> I don't quite understand your problem. Do you need to make your app window
> foreground at some events? Is it user interface window?
>
> If I understand correctly, your apps interact by simulating user input? It
> is not the proper method for industrial grade app. Use other, more
reliable,
> IPC means, such as named pipes, DCOM, etc.
>
No, my system is a control and automation system. One of the things it needs
to control are applications which are, unfortunately, not designed for such.
So, the only way to control them is to simulate user input into them. Since
my system is network distributed, the 'device' driver that is controlling a
given application can be on one host while the app to be controlled is on
another, so there is a 'proxy' server program (which is a GUI program)
running on each host where my user wants to control applications. The driver
for a given application will connect to the proxy on the host it is told to,
and will pass through commands to the proxy server telling it to start,
stop, send keys to, etc... that particular application.
The problem is that the proxy server program is not being directly
interacted with by the user, it will just be his 'reprsentative' on that
host to start and manipulate the applications, and therefore won't be the
active application on that host. This raises the issue of how to make
another application come forward, so that it can be fed input via
SendInput(), given the limitations of SetForegroundWindow(), which requires
that only a current foreground app can bring other apps to the foreground.
It can delegate that authority in a one shot manner via the
AllowSetForegroundWindow() method, but that won't work here since the actual
foreground app that the user is interacting with is on one machine (in many
cases) while the proxy is running on another machine and doing things to the
controlled application via faked input.
Does that make more sense? I definitely use IPC for everything else, and I
have my own ORB actually, so the entire system is based on my own
distributed object technology. But in this case, it's one of those deals
where you just have to hold your nose against the stink and do what you ahve
to do, and users demand that I be able to control applications that were
never designed to be controlled.
- Next message: Dean Roddey: "Re: How to get around new limitations on SetForegroundWindow()?"
- Previous message: Philippe: "Re: How to get around new limitations on SetForegroundWindow()?"
- In reply to: Alexander Grigoriev: "Re: How to get around new limitations on SetForegroundWindow()?"
- Next in thread: James Brown: "Re: How to get around new limitations on SetForegroundWindow()?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
