Chicken-and-egg problem with exec()
I have a non-Qt application, which utilizes a Qt app as a "plugin" of sorts: when a user hits a button in the main (non-Qt) app, it calls some code that creates a QMainWindow, then calls show() and exec():
static QApplication a(argc, argv);
static MainWindow editor;
Once the user hits OK or Cancel in this dialog-type MainWindow, the GUI goes away, and control returns to the main application. Works just fine on Snow Leopard. On Lion, however, the Qt "editor" window does not appear, until the user clicks the main (non Qt) app's icon in the Dock. Indeed, prior to clicking on said Dock icon, I can use Command-Tab, and see that the Finder is the current/active/front application (the main non-Qt program should be the active app, as it is on Snow Leopard). My idea for a workaround is to use SetFrontProcess() to again make the main app current, and this should make my Qt dialog appear.
However, doing so before calling "exec()" does not work, which is not surprising. I think I need to somehow call SetFrontProcess() after exec(). But of course exec() does not return until the dialog exits. So, my question is this: in my MainWindow "application", I would like to try calling SetFrontProcess() as soon as possible in the event-handling. Obviously the show() method is too early, but what can I hook into that happens right off once exec() launches the MainWindow?
You can use a QTimer::singleShot() with a timeout of 0 to invoke a slot as soon as event processing happens in your main loop.
Thanks - I'll give that a shot, so to speak :-)
Turns out the SetFrontProcess() doesn't actually work, even when calling it after the widget is "running". Ended up using AppleScript:
QString aScript =
QString osascript = "/usr/bin/osascript"; QStringList processArguments; processArguments << "-l" << "AppleScript"; QProcess p; p.start(osascript, processArguments); p.write(aScript.toUtf8()); p.closeWriteChannel(); p.waitForFinished();