You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
Announcement
Collapse
No announcement yet.
I have an app rattling around in the background...
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!
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.
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:
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).
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
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
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.
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.
The SetForegroundWindow API works as I remembered. Unless an application already has the foreground, all SetForegroundWindow does is make the task bar button blink.
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.
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".
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.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Comment