I have an exe file. I want a seperate program to launch it, but keep it invisible.
Only the program that launches it should be visible to the user.
Background Tasks
Using background tasks you could launch the executable behind the scenes.
Note: If you do so, you still won't be able to prevent any indicators that that program normally sends to the user to alert them it's running (like a splash screen) from occurring.
If you wrote the code, or have access to the code, that became the executable, then you can use a background task in your program to run the code without having a separate executable.
It should be a simple matter to look up how to implement background tasks in the language you're writing in.
Related
I was wondering if there is a way to execute a c++ application in the mac terminal either: without the executable window gaining focus or, without the executable window at all?
The application in question does not have any graphics, merely runs through some code and writes data.
I am currently running the executable in MATLAB like this:
[status,out] = system('./vevpd-opt *.pro');
And here is the window (there is nothing graphically associated with this window) appearing in my dock (exec - vevpd-opt):
The executable is being run multiple times as part of an optimisation procedure so gains focus multiple times per second, rendering the rest of the computer unusable while the script is running. If there is a way to prevent this from occurring I would be very grateful!
I am writing a small application (.exe) that does some tasks and then returns an exit status. It is meant to be run regularly from another application (which I have no control over) that uses the status code to determine further action.
It works just fine if I compile and link it as a console app. However, that makes the console window flash briefly on the screen every time it is run, which is a little bit annoying. I tried to make it a Windows app, but the problem then is that Windows releases control to the calling application (or the OS) immediately after start. Thus, any exit status my application generates is returned too late and is never seen by the calling application.
Is there a way to force my app to stay in the foreground, so to speak, and not release control before it actually exits? I tried to force the entry point to be the "main" function instead of "WinMain", but that didn't help.
It isn't a question of whether the child "releases control" or not - Windows is a preemptive multitasking operating system, so all processes run at once. If the parent process waits for the child to exit, it is because the programmer told it to wait for the child to exit.
It isn't easy to make a program wait for console programs but not non-console programs. The command shell (cmd.exe) works this way when run interactively, but there isn't any API that does this as far as I know. Assuming that it isn't deliberate - which would be very strange in this context - the only explanation I can think of is that the program is running an interactive command shell and feeding in your command via standard input. That's the wrong thing to do, but I have seen people trying to do it that way before.
Presumably you can choose the command line that the parent executes. Try this:
start /wait myapp.exe
(That's how you would do it in an interactive command shell.)
If that doesn't work, you may have to consult the author of the parent process for advice.
Basically I want to write a script to be able to detect when the user launches programs (on windows 7) in order to use the applications' icons to make MegaMan style splash screens.
I'm not really sure where to start. Is this even possible?
You can hook CreateProcess
some details here, http://www.codeproject.com/Articles/11985/Hooking-the-native-API-and-controlling-process-cre
Or you could just keep watching all the processes and note the changes...
I know this method of setting console size :
system("mode 128,128");
But when program starts, system at first is trying to create console with standard size and when execution reaches mode command - only then the console window gets my desired size. The question is how to make console according to my needs right from the start.
I'm speaking here of running the program with double click from explorer, so the console belongs to the program.
You might have more luck linking your program as a GUI application rather than command-line, calling AllocConsole() to create a console, and then SetConsoleWindowInfo() to resize it. The console would still get created before the resizing, but because you are using the API calls directly, the delay may be small enough to not be noticeable.
If you do this, you may need to do some setup to connect the C and C++ standard input/output/error to the console you created. For that, take a look at _fdopen() and ios_base::sync_with_stdio().
I'm going through Qt tutorials on OSX. One thing I noticed is that when I launch the executable (e.g. the push button hello world example), the app will launch as a background window and I have to switch tasks to bring it into the foreground. How can I force the Qt application window to be the foreground window upon execution?
I'd like to do this since it's how most apps behave, not to mention that manually switching tasks slows down my edit-compile-run-debug cycle).
The behavior you observe is due to interaction with the debugger when you start the application under the debugger using ⌘-Y. If you simply run it using ⌘-R, it behaves as you expect. Your application itself is fine.
Starting OS X applications by directly firing up the executable from within the app bundle from the terminal will act similarly to running them using ⌘-Y -- they all start in the background. Qt is probably mimicking whatever magic Finder does when it starts the process via ⌘-R -- said magic may reduce to simply bringing the child app to the foreground. gdb on OS X is not so "clever", and probably for a good reason.
OS X approach is to try harder not to steal focus -- a good thing IMHO.
If you merely want to run the application, not debug it, then modify your launch command to look like open -a '/Users/daj/foo/bar/baz.app', where baz.app is the app bundle folder. Do not append a trailing slash.
If you can coax your debugger to follow through to child processes, then you can of course launch open itself under gdb, and it will work as expected -- with your child application on top.