Re: How to get around new limitations on SetForegroundWindow()?
From: James Brown (james.brown7_nosp_at_m_virgin.net)
Date: 03/21/04
- Next message: Feng Yuan [MSFT]: "Re: When can I free DEVMODE and DEVNAMES ?"
- Previous message: Alexander Grigoriev: "Re: How to get around new limitations on SetForegroundWindow()?"
- In reply to: Dean Roddey: "How to get around new limitations on SetForegroundWindow()?"
- Next in thread: Dean Roddey: "Re: How to get around new limitations on SetForegroundWindow()?"
- Reply: Dean Roddey: "Re: How to get around new limitations on SetForegroundWindow()?"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 21 Mar 2004 09:18:24 -0000
"Dean Roddey" <droddey@charmedquark.com> wrote in message
news:OBol8IvDEHA.3408@tk2msftngp13.phx.gbl...
> I have an issue that I'm not sure how to get around with setting the
> foreground window. My company is the vendor of a distributed control and
> automation product. It's concentrated on the more traditional aspects of
C&A
> so far, i.e. external device control. But I'm extending it for application
> control. But this raises a fundamental problem. The product is network
> distributed, so the bits are spread out, and among those pieces is an app
> control server programs, which is a GUI app that the user runs on any
> machines that he wants to control applications on. That server program is
a
> kind of proxy for the control system on that host, and it starts, stops,
> etc... applications based on remote commands from 'device' drivers loaded
> into various other hosts in the network (where device is an app in this
> case.)
>
> But, because of the distributed nature of the system, the user is not
> directly interacting with program that ultimately will control the app
(and
> try to feed it faked input and whatnot.) So, that server program will not
be
> the active application in most cases when commands come in. Because of the
> recent changes to foreground setting, it will not be able to bring up
> another app, that app will just blink it's task bar item and not come up.
>
> This is clearly not going to be acceptable to my users, so there has to be
a
> way around this. Clearly if a system is going to be remotely controlled,
it
> must be possible for a server program to start and stop apps and bring
them
> to the foreground as required, when that program wouldn't (under current
> rules) have the technical right to bring an app forward.
>
> So is there some way to get around this limitation? I don't see how I can
> create a useful app control system within the current limitations.
>
> ------------------------------------
> Dean Roddey
> The Charmed Quark Controller
> www.charmedquark.com
>
>
The key to solving this problem is the AttachThreadInput API call:
DWORD pid, tid;
HWND hwnd;
hwnd = GetForegroundWindow();
tid = GetWindowThreadProcessId(hwnd, &pid);
AttachThreadInput(GetCurrentThreadId(), tid, TRUE);
SetForegroundWindow(hwnd);
AttachThreadInput(GetCurrentThreadId(), tid, FALSE);
James
-- www.catch22.org.uk Free Win32 Software, Source Code and Tutorials
- Next message: Feng Yuan [MSFT]: "Re: When can I free DEVMODE and DEVNAMES ?"
- Previous message: Alexander Grigoriev: "Re: How to get around new limitations on SetForegroundWindow()?"
- In reply to: Dean Roddey: "How to get around new limitations on SetForegroundWindow()?"
- Next in thread: Dean Roddey: "Re: How to get around new limitations on SetForegroundWindow()?"
- Reply: Dean Roddey: "Re: How to get around new limitations on SetForegroundWindow()?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
