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!
Related
I have a c++ program compiled with MinGW which links to libmicrohttpd to run a webserver. It normally functions correctly, but I am trying to do some robustness testing and for my current test I have tried to disable the network interface. This results in the program crashing with the dialog box: "MyProgram.exe has stopped working - A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available."
Rather than debug the program and potentially its dependencies, for my purposes, it would be fine if it would just crash silently without making the dialog box (I have another component that is meant to restart it). Is this possible to do via some sort of manifest or Windows API call?
It turns out there is a Windows API function called SetErrorMode. Passing the parameter SEM_NOGPFAULTERRORBOX will prevent the error dialog from being displayed on a crash.
There is also the RegisterApplicationRestart function which can be used to have Windows restart an application in the event of a crash (or other configurable reasons).
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.
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'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.
So i have a setup where two imacs, imac_1 and imac_2, are connected through firewire. imac_1 sends some debugging information to imac_2 and on imac_2 i have a program in c++ that captures debugging information.(see illustration below)
Now the problem is that if i write the debugging info to the GUI (created using QT) directly its very slow, by slow i mean that the GUI takes time to load the data. So what i did was to write the debugging info to a buffer and then dump that buffer into the GUI but that was also slow because the GUI takes time to load the data.
I was thinking of writing the debugging info to a file and then loading that into the gui. So i would load the first 10,000 lines into the gui and then when the user scrolls down i would load next 10,000 lines.
imac_1(transmitter) --->FireWire (medium) --> imac_2 (receiver)
any ideas or suggestions????
i am using:
Mac OS X,
XCode,
imac
It sounds like your problem has nothing to do with the two computers communicating, but may instead be your GUI application.
I would suggest you try the file approach you mention, if only to isolate the network component from the discussion. Then work on making your GUI faster.
If you are adding the lines of text one at a time, that might account for some of the slowness, but 10,000 lines isn't really that many.
Other approaches might include turning off redrawing or something similar while you are loading in the text file.