I have an app rattling around in the background...

[Mel Bishop]

...minimized and purring along quite nicely.

What I need is a way of, when an evaluation ='s true, bring it up to the foreground and have it grab the focus.

Can do?

[Michael Mattias]

Sounds like a tray application? User can bring up when needed?

Or did you mean some kind of evaluation which is performed in another process?

If that's the case, a named event could be quite useful.

Terminate Worker Threads Using Windows Events (and Using Thread Local Storage) Demo Dec 23 2005

This shows using a named event within a single process; but any process can obtain a handle to a named event and signal it.

For that matter, if the 'background process' is a child process of your 'main' process you would have even more options, eg sending a windows' message to a hidden window (the 'message only' window would be perfect).

[added]

If it's a child process you can use SetActiveWindow() on it, no need to mess about with events!




MCM

[Kev Peel]

If (Activate) Then
   ShowWindow CONSHNDL, %SW_RESTORE
   SetForegroundWindow CONSHNDL
End If

[Eric Pearson]

The SetForegroundWindow API was "neutered" a couple of versions (of Windows) ago. It no longer has the ability to, well, set the foreground window. At least not unless your application already has the foreground, in which case the API can be used to specify which window gets the focus.

I think the basic answer to Mel's question is No, at least not on modern versions of Windows. The most you will be able to do is make the task bar button blink, in hopes of getting the user to click on it, thereby giving your program the focus.

-- Eric

[David Roberts]

Heven't given this much thought but instead of considering ShowWindow commands how about the app sending itself the system menu command SC_RESTORE.

[Michael Mattias]

The SetForegroundWindow API was "neutered" a couple of versions (of Windows) ago

Maybe, maybe not?

Windows 98/Me: The system restricts which processes can set the foreground window. A process can set the foreground window only if one of the following conditions is true:
* The process is the foreground process.
* The process was started by the foreground process. [italics mine]
.....

To have SetForegroundWindow behave the same as it did on Windows 95 and Microsoft Windows NT® 4.0, change the foreground lock timeout value when the application is installed. This can be done from the setup or installation application with the following function call:

SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, (LPVOID)0, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE);

This method allows SetForegroundWindow on Windows 98/Windows Me and Windows 2000/Windows XP to behave the same as Windows 95 and Windows NT 4.0, respectively, for all applications.

Or maybe AttachThreadInput() + SetActiveWindow()?

Then again, maybe events IS the way to go. When the event is signalled, the application should be able to set itself up as the 'focus' window and SetWindowPos itself to %HWND_TOP.

Might be fun to try this.

Then again, we are in the Console Compiler forum. If this magic background process is a console application, all bets may be off because console programs act weird. ("No doubt 'Console Tools' can help?" he asked, lobbing a softball right down Broadway).



MCM

[David Roberts]

Before reinventing the wheel I always look in Poffs. Searched the Console Compiler forum for sc_close and up came one entry - yep, just one.

It was enough - a post by Pierre Bellisle does the trick.

Very slight changes to code

#Compile Exe
#Dim All
#Tools Off
#Register None

#Include "WIN32API.INC"

Function PBMain() As Long
Local Hndl As Dword

 CONSOLE SCREEN 26, 80
 Hndl = GetForegroundWindow

 Sleep 1000
 SendMessage Hndl, %WM_SYSCOMMAND, %SC_MINIMIZE, 0
 Sleep 1500
 SendMessage Hndl, %WM_SYSCOMMAND, %SC_RESTORE , 0
 Print "Window is Restored"
 Sleep 1500

 WAITKEY$

End Function

SendMessage Hndl, %WM_SYSCOMMAND, %SC_RESTORE , 0 "when an evaluation ='s true"

[Kev Peel]

Why would you need to do that? ShowWindow is the correct way to restore a window

[David Roberts]

I got led away reading Eric's and Mr Mattias' exchange.

Just replaced 'SendMessage Hndl, %WM_SYSCOMMAND, %SC_RESTORE , 0' with 'ShowWindow CONSHNDL, %SW_RESTORE' and, yes, it was fine.

You are spoilt for choice now, Mel.

You can put your tongue back in now, Kev.

[Mel Bishop]

Well, it just go to show that, when faced with choices, there is no one "correct" way of doing anything.

Your first example works fantastically and I see no reason to fix something that ain't broke.

Much obligated.

[Eric Pearson]

Mel --

You're saying that the code above will give the Windows foreground to a program that doesn't already have it? I'd be very surprised! For example, if your program is running in the background and you have a program like Notepad in the foreground, that code will "steal" the foreground? Microsoft made a big deal about disallowing that a few years ago. There are ways around the restriction, but it's not easy (see below).

Michael --

> ("No doubt 'Console Tools' can help?" he asked, lobbing a softball right down Broadway).

Well, yes, actually. But believe me, it has to jump through a lot of hoops to give the console window the foreground under all circumstances (like those described above). The technique is Windows-version-specific; 98, ME, NT, 2000, and XP all require different -- in some cases vastly different -- tricks.

-- Eric

[Michael Mattias]

>different -- in some cases vastly different -- tricks.

They are "tricks" only when someone else does it.

When you do it yourself it's a technique.

[Mel Bishop]

...the code above will give the Windows foreground to a program that doesn't already have it?...

Well, yea. Apparently. I incorporated it into my "Who's on my network" program. Works as advertised.

Go ahead and give the example a try. See what shakes loose yourself.

[David Roberts]

Notepad gets pushed aside with me, Eric.

This is one of the rare occasions where a PB handle is in synch with the API.

'SendMessage CONSHNDL, %WM_SYSCOMMAND, %SC_RESTORE , 0' works as well - not surprising since it works with ShowWindow.

[Chris Holbrook]

...98, ME, NT, 2000, and XP all require different -- in some cases vastly different -- tricks.

could it be that the tricks have changed?

[Eric Pearson]

I spent some time experimenting with this, and here's what I found.

The SetForegroundWindow API works as I remembered. Unless an application already has the foreground, all SetForegroundWindow does is make the task bar button blink.

I was surprised to find, however, that the ShowWindow minimize/restore technique does work on my Windows XP system. The minimize step is necessary; if all you do is restore, nothing happens.

Interesting! When I get some time I'll fire up my other test systems and see if it works the same on all versions of Windows.

-- Eric

[Knuth Konrad]

The SetForegroundWindow API works as I remembered. Unless an application already has the foreground, all SetForegroundWindow does is make the task bar button blink.

There's a registry setting for W2K and XP that controls that behavior: http://www.microsoft.com/mspress/boo.../6232.aspx#102

[Eric Pearson]

Knuth --

Right, and there is the SystemParametersInfo technique that Michael mentioned, among others, but those techniques affect the entire computer. All programs. If you are dealing with only your own computer those methods are fine, but it's not always acceptable for a program to change global settings. I, for one, hate it when another person's program changes my default Windows settings.

And to be honest, I have grown to like the fact that it is difficult for a program to steal the foreground. In the olden days of Windows it was common for me to be typing away at something, only to find that my editor was no longer seeing the keystrokes. Worst case, I would type Enter or Space at the wrong moment, and unintentionally dismiss a message box that was trying to tell me something.

-- Eric

[Knuth Konrad]

Right, and there is the SystemParametersInfo technique that Michael mentioned, among others, but those techniques affect the entire computer. All programs. If you are dealing with only your own computer those methods are fine, but it's not always acceptable for a program to change global settings. I, for one, hate it when another person's program changes my default Windows settings.

Uhh, yes, of course. Changing any system wide settings without asking the user is a big, big no-no! I've stated this on quite some occasions here before.

I didn't post that info for incorporating it into one's application, but for using it at your own machine. Some prefer the blinking, some prefer the old "steal focus".

Sorry, if my previous message was misleading.

[Michael Mattias]

In this case you might get away with...

  GetSystemParameter of interest, save
  SetSystemParamater of interest to value wanted 
  Make Call requiring systemparameter of interest to be value wanted 
  Put SystemParameter back to what it was and hope no one noticed.

???