How do I make a process go the background programatically?
What I want is for the user to double-click the process executable, and it just goes into the background ... and does not open a window while executing.
Any code snippet in visual c++ would be very helpful
Have you considered creating a Windows Service instead? They're specifically designed to run in the background without showing a UI.
Otherwise, just create an application without a window.
I know this is old, but I thought I would post something for when people find this through search.
While I like Cody Gray's answer for design correctness, sometimes you don't have a choice.
If you want to launch a program without jumping to the new window (it appears in the background or minimized) or not create a window at all try looking at the ShellExecute and ShellExecuteEx functions. The argument nShowCmd (or nShow) gives you (among others) the options:
SW_HIDE
Hides the window and activates another window.
SW_SHOWMINNOACTIVE
Displays the window as a minimized window. The active window remains active.
As the documentation says, SW_HIDE creates a process running the executable you give it, but if this program would normally create a window, none appears.
This might help: http://ss64.com/nt/start.html
I tried this way and it worked fine:
Create a console application and write your codes in the sub main as any other console application.
Now change the application type in the project properties to windows Forms application from Console application
thats it
Related
I am trying to write a program what will manage few console windows, my program will be able to CreateProcess() for new console windows, get a window main handle and the use that handle to resize, close, hide, change title etc. But I cannot find a reliable way to get a main window handle. The purpose is to have a tab bar and switch between created console windows with the click on the tab.
I have tried few ways:
1) use windows "cmd.exe" ability to set window title, and then FindWindow("tmp_title"...)
This has a problem, I do not need cmd.exe running, and also I need a processID for the target program not the cmd.exe. Maybe I should use this way but check for children subprocesses?
2) EnumWindows() then CreateProcess() then wait 40 ms, then EnumWindows() again and find the new window.
This is unreliable! I got two new windows sometimes for weird reasons.
3) use GetWindowThreadProcessId() + EnumWindows(). This worked the best on XP, but on win7 the found window seems to be the wrong one, it's GetWindowText() returns "DefaultIME" and hide/show of this window does nothing. So it is obviously a wrong one.
So any idea how to do it reliably and if possible cross-platform (Cross-windows, XP,Vista,7)
I have three executables compiled from Visual C++ using OpenGL libraries. Though nothing is different between them in how the window is created, one of them automatically has focus when I run it and the other two require the user to click on the window before they are given focus.
I'm building a WIN32 application as a menu to run the different .exe files, and in here I'm using all the usual suggestions to attempt to focus the windows (SetFocus(hWnd) SetActiveWindow(hWnd)), but to no avail.
Any advice?
What you want is actually SetForegroundWindow (...), because in addition to setting the active window, this will bring your application into the foreground.
SetActiveWindow (hWnd) will only accomplish what you want if your application is in the foreground, it is useful if you have a multi-document application and want to switch between windows.
Here is a relevant selection of code that I use in my Win32 window management system when initializing / resizing a rendercontext:
ShowWindow (hWndRender, SW_SHOW);
SetForegroundWindow (hWndRender);
SetFocus (hWndRender);
Normally user is doing it by clicking right-mouse into console title bar then selecting "edit" and finally "mark". -> http://www.megaleecher.net/Copy_Paste_Text_Dos_Window
So is there a way of doing it from a console application either by sending a message/api call/keyboard sequence to its own window ?
If this is your own application and you want the richer behaviour and flexibility of a windows app rather than a console app, then use a windows app. Otherwise, you can try to automate the steps by simulating the input via SendInput. I would advise against doing this because it requires two steps (once for right-click, once to select 'Mark'). This means if someone clicks something else between these two events, your sequence will be broken. Furthermore you are really relying on the automation of an implementation detail which is prone to change at any point.
Looking through the Console Functions, it doesn't appear as though anything exists for setting the selection. The closest is going the other way with GetConsoleSelectionInfo.
If you want to process the information that is within a console application, a better alternative is to pipe it to your own process and deal with it there.
Found: PostMessage(GetConsoleWindow(), WM_COMMAND, 65522, 0);
I have a VB6 executable we use as a Starter executable for our real program.
The problem is that windows 7 shows a new icon in the taskbar for the new process, instead of the one i clicked on to start my program (of course, because the starter exe has already ended, and the new exe seems to be a new program).
Currently I use the Shell object to start the other exe. Is there a better way to do it from vb6, maybe by using a native C function with declare that does start an exe in the current process, without spawning a new process?
EDIT:
Thanks to atzz for the great information about Application Model IDs. I now have a shortcut to my app starter with a well defined id, and my app also sets the ID when started, and is now accesssible beautifully from the right icon in the toolbar. However, two problems persist:
The app is a Java App started with Exe4J, and I don't have any chance to set the AppID before Exe4J shows the splash screen, so while showing the splash screen there is a second icon in the taskbar.
If I don't manually drag my starter app icon from the Desktop to the toolbar, but instead use my apps icon and set it to be "sticky", the real app is sticked, and not the launcher.
Both problems would be beautifully solved if my launcher would start the app from within its own process. I heard something of using exec() instead of fork() for linux programs to achive this... is there something similar for windows?
I believe there is a way to accomplish what you need via Windows 7 taskbar API, though I never did it myself and thus don't remember clearly enough what I've read on the subject. Look around the Application ID concept.
Some links:
Developing for the Windows 7 Taskbar – Application ID
Inside Windows 7 - Introducing The Taskbar APIs
If the problem is the icon, why not give both programs the same icon (and the same App.Title). Then the user won't be able to tell the difference between the two taskbar entries. Presumably they aren't both visible at the same time.
Alternatively set your starter app not to appear in the taskbar (Form property ShowInTaskbar = False in the design view)
I have an application that manages patient demographic information. Along with this data a user can scan a picture of a patient and assign that picture to a patient. When the user clicks the scan button a separate application is opened as a dialog in order to scan the image. When running this on XP everything worked fine. The imaging application loaded up fine and gained focus. On Vista however occasionally the imaging application will not gain focus and will popup behind the main application. When running full screen or through 2008 Application Server you cannot see the application, you only get a locked screen and it appears nothing has happened. Is there any way to change the window focus management on Vista to work the way XP did? I'm looking for a way to solve this without making changes to the actual application if possible.
I think you will have to make changes to your application to allow the imaging application to take the focus. I'm going to assume that your application launches the imaging application through ShellExecute or CreateProcess. If so, you can get the process handle of the launched process either through SHELLEXECUTEINFO.hProcess (for ShellExecute) or PROCESS_INFORMATION.hProcess (for CreateProcess). Immediately after launching the imaging application call the AllowSetForegroundWindow API:
AllowSetForegroundWindow(GetProcessId(hProcess));
This will allow the imaging application to place its main window/dialog in the foreground when it's starting up.
You could try the following steps:
1. Right Click on the exe
2. Select Properties
3. Select the Compatibility Tab
4. Check the Run this program in campatibility mode for:
5. Select Windows XP (Service Pack 2)
You could iterate through all top level HWNDs and identify the scanning application via its window class, then send an appropriate message to raise the window.
I don't believe this is Vista vs XP related. I think that simply this imaging app takes longer to start on Vista.
Since Windows 2000, the window manager has prevented background applications stealing the foreground. When an application is launched, it has a window of opportunity to create and show a window that will take the foreground. If it takes too long, the window manager thinks that the current window should keep the foreground, and inhibits the other app taking the foreground when it does finally launch.
I can't think of any specific way to avoid this... other than using FindWindow to search for the other apps window after launching the app. When you eventually find it, call SetForegroundWindow on it to bring it to the foreground.