I have a Windows application application that is normally GUI-only and declares the WINDOWS subsystem. It doesn't open a console window when launched.
Alas, I would like to offer additional console output when the application happens to be started from console window (say, from interactive cmd.exe).
Is there a way of detecting if some process "up the chain" has an open console, and to attach to that console?
The closest I've found is a way to explicitly open a console for a gui application, but I don't want to open a console if there isn't one already there.
At first glance it seems like the AttachConsole() function will let you attach to the console of your parent process:
AttachConsole(ATTACH_PARENT_PROCESS);
If the process doesn't actually have a console the function will fail with ERROR_INVALID_HANDLE. The function will also fail if your parent process no longer exists. If it fails you can then call AllocConsole() to create your own.
I've never tried this so don't actually know if it will work or not :)
Related
My goal is to have it so when the executable is just double clicked no console spawns but also have it able to print to the console when the user launches it from the command line.
I have the following Windows-specific code set to not spawn a console:
#![windows_subsystem = "windows"]
fn main() {
println!("Hello world");
}
Unfortunately, it never hooks stdout/stderr to anything since its set to not create a console on startup. Is there any way to achieve my goal despite this?
This is not really specific to Rust, but instead is the way Windows works: you either write for the "console" subsystem and your program opens a console if it is started without one, or you write for the "windows" subsystem and your program detaches itself from the console if it is started from the command line.
The PATHEXT environment variable — which CLI shells use for the file extensions to add when searching PATH for a command — normally includes ".COM" before ".EXE", in which case one can create a console version of the application with a ".com" file extension (e.g. "app.com"). This can be a standalone version or just a launcher that spawns the main executable (e.g. "app.exe", a GUI app). A launcher can pass a command-line option that allows the main application to attach back to the console via AttachConsole.
Without a launcher, it's a bad idea to attach back to the console since the parent application (e.g. a CLI shell or a full TUI app) normally will not wait for a GUI application to exit, in which case the result is chaotic interleaved I/O with two applications competing for access.
My goal is to have it so when the executable is just double clicked no console spawns but also have it able to print to the console when the user launches it from the command line.
I have the following Windows-specific code set to not spawn a console:
#![windows_subsystem = "windows"]
fn main() {
println!("Hello world");
}
Unfortunately, it never hooks stdout/stderr to anything since its set to not create a console on startup. Is there any way to achieve my goal despite this?
This is not really specific to Rust, but instead is the way Windows works: you either write for the "console" subsystem and your program opens a console if it is started without one, or you write for the "windows" subsystem and your program detaches itself from the console if it is started from the command line.
The PATHEXT environment variable — which CLI shells use for the file extensions to add when searching PATH for a command — normally includes ".COM" before ".EXE", in which case one can create a console version of the application with a ".com" file extension (e.g. "app.com"). This can be a standalone version or just a launcher that spawns the main executable (e.g. "app.exe", a GUI app). A launcher can pass a command-line option that allows the main application to attach back to the console via AttachConsole.
Without a launcher, it's a bad idea to attach back to the console since the parent application (e.g. a CLI shell or a full TUI app) normally will not wait for a GUI application to exit, in which case the result is chaotic interleaved I/O with two applications competing for access.
When I have a Win32 non-console application (AFAIK, the console-ness of a Win32 app is linked into the exe), starting it from the console cmd.exe will return to the command prompt immediately, running the application "in the background" (o.c. it can have a GUI of sorts, or even open its own console window)
Is it possible in the non-console executable to detect that it was launched from cmd.exe and "attach" it to the launching cmd.exe?
And note that there are various questions/answers related to this, but it seems that this exact approach hasn't been investigated. (Maybe it's not possible like that.)
You can do this very easily. Simply pass ATTACH_PARENT_PROCESS to AttachConsole.
Whether or not the end result is sensible or practical is something I could not say. Both processes would read and write to the same console which could get pretty weird.
Say I have a standard Cocoa Application call Foo.app (like the one you get just by choosing New Project > Cocoa Application in Xcode), if I open the app via a terminal using:
open Foo.app/
Then I see Foo's name on the status bar up top and its window is in focus, in front of all other apps.
If instead I directly call from the terminal the executable buried in the .app folder, like:
Foo.app/Contents/MacOS/Foo
Nothing appears to happen. On inspection the app has indeed opened but it is not in focus (the terminal still is), I have to find it on the dock or find its window.
Is there any way for the Foo application to make sure its in focus when its run? Even if its run via its executable as described above?
Your app can "steal focus" by calling
[[NSApplication sharedApplication] activateIgnoringOtherApps:YES];
See the NSApplication docs for more info.
did you mean to type:
open -a /Applications/Foo.app/
note the -a option
If you're asking how to give your app (that you're writing) this behavior -- within applicationWillFinishLaunching: you could call [NSApp activateIgnoringOtherApps:YES].
perhaps AppleScript?
tell application "TextEdit"
activate
end tell
There are (at least) three different ways you open (and interact with) Applications from the Terminal.
you can launch any Application (that is registered in LaunchServices) from the Terminal by typing open -a ApplicationName (note that you do not need the trailing ".app" or give any path)
you can open an application giving its specific path by typing open /path/to/ApplicationName.app (you will rarely need that, given that the applications is likely already registered in LaunchServices)
you can open and interact with the executable if you type open /path/to/ApplicationName.app/Contents/MacOS/ApplicationName. The difference here is that for some Applications, you can pass arguments or interact with them afterwards on your command line. Go ahead and try open /Applications/Mail.app/Contents/MacOS/Mail for example - it will give you a debugging log in return.
you can interact with some applications even without using "open" by directly calling their executable; try /Applications/Firefox.app/Contents/MacOS/firefox-bin —help for example.
So if you do want to make sure the command-line-launched application is in focus, use either method 1 or 2.
The Qt documentation for QWidget::activateWindow() states:
On Windows, if you are calling this
when the application is not currently
the active one then it will not make
it the active window. It will change
the color of the taskbar entry to
indicate that the window has changed
in some way. This is because Microsoft
does not allow an application to
interrupt what the user is currently
doing in another application.
However, Skype appears to defy this rule. If Skype is running but is not the active application, I can launch it from the start menu and it brings the existing instance to the foreground, activates it and grabs input focus.
And how can I do this?
(NOTE: This is specific to how QtSingleApplication works)
The solution is stupidly simple for my issue. Simply call AllowSetForegroundWindow(ASF_ANY); at the beginning of the application, and the original process will thus be allowed to bring itself to the foreground by use of SetForegroundWindow(). No strange hacks, just one line of code to add and no need to modify QtSingleApplication either.
I don't think you can do it reliably with the Qt API alone.
There are multiple solutions for windows. E.g. here, and here, and here.
The method I've used before is to declare a shared memory section, and write the application's window handle there. Later, when a second instance of your program is started, you can find the window handle of the first and activate it.
I don't think you have the issue of windows preventing you from doing this in this case, because your second instance is the active application, so it is allowed to 'pass focus' to other windows.
Use Single Application in Qt Solutions
For some applications it is useful or
even critical that they are started
only once by any user. Future attempts
to start the application should
activate any already running instance,
and possibly perform requested
actions, e.g. loading a file, in that
instance.
you can set the setWindowOpacity from 0 to 1 .the only thing is you may open it all the time