Mac: Apps launch in background when run from cmd line

[David Purton]

I know this is not a wxWidget issue specifically..., but I thought maybe
someone might have an idea.

I want to launch applications from links in pdf documents.

Everything is works using Apple's Preview, but Adobe Reader seems rather
broken at this point :(

The only way I can get applications to launch *with* command line
arguments is to write a posix wrapper application that calls system().

This, as well as running the command from the shell launches the
application ok with the specified cmd args, but launches it under the
current window. If this window happens to be a maximised adobe reader
window, you can't tell when my app starts.

I thought maybe wxFrame::Raise () might do the trick, but it doesn't make
any difference.

I'm not feelng really hopeful, since running
/Applications/Calculator.app/Contents/MacOS/Calculator from a terminal
window behaves exactly the same way :(

Does anyone have any thoughts?

[Christopher B Egner]

If you launch an executable or a .app without first having run it
through /Developer/Applications/Reztool, it will launch but won't
appear in the doc or any window menus. It will also always be below
other windows. Check out the Mac examples for the exact command you
need to run. It's a postprocessor for the executable image (in other
words, the final output from the linker).

I'm not sure if this is your problem, but it sounds about right. And
it's my only idea. ;o)

Chris Egner

[David Purton]

Post by Christopher B Egner
If you launch an executable or a .app without first having run it
through /Developer/Applications/Reztool, it will launch but won't
appear in the doc or any window menus. It will also always be below
other windows. Check out the Mac examples for the exact command you
need to run. It's a postprocessor for the executable image (in other
words, the final output from the linker).
I'm not sure if this is your problem, but it sounds about right. And
it's my only idea. ;o)

Thanks - this behaviour seems to occur with every app - apple ones,
wxMac samples correctly built and my apps which have all the appropriate
resource gunk - so I don't think it is related to resources.

I suspect that it is a "feature" of the chasm that apple seems to have
between their unix layer and their gui layer - can't be helped :(

dc

[Christopher B Egner]

Or perhaps I should read more carefully... Another reason to pack it
up for the night. Sorry for the extra traffic, folks.

I don't know Applescript that well, but I am almost certain that it
can bring an app to the fore. Since Applescript has a command line
interface (osascript), you could call it through system(). Not the
cleverest of ideas, but it should work.

Chris Egner

[David Purton]

Post by Christopher B Egner
Or perhaps I should read more carefully... Another reason to pack it
up for the night. Sorry for the extra traffic, folks.
I don't know Applescript that well, but I am almost certain that it
can bring an app to the fore. Since Applescript has a command line
interface (osascript), you could call it through system(). Not the
cleverest of ideas, but it should work.

mmm - good idea - it works for the apple calculator programme.

I'll see if I can make my apps respond to the activate apple script
event.

cheers

dc

[David Purton]

Post by Christopher B Egner
Or perhaps I should read more carefully... Another reason to pack it
up for the night. Sorry for the extra traffic, folks.
I don't know Applescript that well, but I am almost certain that it
can bring an app to the fore. Since Applescript has a command line
interface (osascript), you could call it through system(). Not the
cleverest of ideas, but it should work.

Ha! Thankyou very much - it works perfectly with the wxApps.


in case anyone is interested these are the commands:

chdir to executable directory obtained from argv[0]

system ("minimal.app/Contents/MacOS/minimal &");
system ("osascript -e \"tell application \\\"minimal\\\"\" -e \"activate\" -e \"end tell\"");


cheers

dc

[David Elliott]

Post by David Purton

Post by Christopher B Egner
Or perhaps I should read more carefully... Another reason to pack it
up for the night. Sorry for the extra traffic, folks.
I don't know Applescript that well, but I am almost certain that it
can bring an app to the fore. Since Applescript has a command line
interface (osascript), you could call it through system(). Not the
cleverest of ideas, but it should work.

Ha! Thankyou very much - it works perfectly with the wxApps.
chdir to executable directory obtained from argv[0]
system ("minimal.app/Contents/MacOS/minimal &");
system ("osascript -e \"tell application \\\"minimal\\\"\" -e
\"activate\" -e \"end tell\"");

Boy, that's going the long way around it.

/usr/bin/open -a ./minimal.app

Obviously you don't need to type /usr/bin but I put it there for
clarity. You can also use NSWorkspace from Cocoa to launch
applications. Cocoa calls can be made even from a Carbon application.

-Dave

[David Purton]

Post by David Elliott

Post by David Purton

Post by Christopher B Egner
Or perhaps I should read more carefully... Another reason to pack it
up for the night. Sorry for the extra traffic, folks.
I don't know Applescript that well, but I am almost certain that it
can bring an app to the fore. Since Applescript has a command line
interface (osascript), you could call it through system(). Not the
cleverest of ideas, but it should work.

Ha! Thankyou very much - it works perfectly with the wxApps.
chdir to executable directory obtained from argv[0]
system ("minimal.app/Contents/MacOS/minimal &");
system ("osascript -e \"tell application \\\"minimal\\\"\" -e
\"activate\" -e \"end tell\"");

Boy, that's going the long way around it.
/usr/bin/open -a ./minimal.app

my understanding is that you can't pass command line arguments this way
though or am I mistaken?

ie, in my first system command I can pass command line args to the
minimal application if I want.

dc

[David Elliott]

Post by David Purton

Post by David Elliott

Post by David Purton
chdir to executable directory obtained from argv[0]
system ("minimal.app/Contents/MacOS/minimal &");
system ("osascript -e \"tell application \\\"minimal\\\"\" -e
\"activate\" -e \"end tell\"");

Boy, that's going the long way around it.
/usr/bin/open -a ./minimal.app

my understanding is that you can't pass command line arguments this way
though or am I mistaken?
ie, in my first system command I can pass command line args to the
minimal application if I want.

That is true, but then you really aren't supposed to be passing
command-line arguments to Mac applications anyway. Mac provides other
mechanisms for starting an application with one or more document files.
Still, if you are just looking for something quick and dirty, your
solution does work. I might recommend a sleep or something in there
because it's quite possible that the app won't be loaded by the time
the AppleScript executes.

-Dave

[David Purton]

Post by David Elliott

Post by David Purton

Post by David Elliott

Post by David Purton
chdir to executable directory obtained from argv[0]
system ("minimal.app/Contents/MacOS/minimal &");
system ("osascript -e \"tell application \\\"minimal\\\"\" -e
\"activate\" -e \"end tell\"");

Boy, that's going the long way around it.
/usr/bin/open -a ./minimal.app

my understanding is that you can't pass command line arguments this way
though or am I mistaken?
ie, in my first system command I can pass command line args to the
minimal application if I want.

That is true, but then you really aren't supposed to be passing
command-line arguments to Mac applications anyway. Mac provides other
mechanisms for starting an application with one or more document files.
Still, if you are just looking for something quick and dirty, your
solution does work. I might recommend a sleep or something in there
because it's quite possible that the app won't be loaded by the time
the AppleScript executes.

Yeah - I gather cmd args are not really the Mac way of doing things...

But in terms of using a single code base it seems like a good idea - I
have to use a hack no matter what since even under windows I can't start
an app directly from acrobat with cmd args.

I'm not always using them for the names of files to open either -
sometimes it tells the app to behave in particular ways - I don't really
have enough time at this stage to investigate the proper way of achiving
this.

I will test and see if sleep necessary, though it seems like the apple
script has a reasonable length timeout itself from my testing so far, so
it may not be necessary.

cheers

dc

[rv2]

Hello All

I wonder if you anyone could confirm that ::wxGetNumberFromUser crashs on
OSX. I download source from CVS header last night.

I build it with the following cmdline

--disable-shared --disable-compat24

psksvp

[ABX]

Post by rv2
Hello All
I wonder if you anyone could confirm that ::wxGetNumberFromUser crashs on
OSX. I download source from CVS header last night.
I build it with the following cmdline
--disable-shared --disable-compat24

I do not know OSX but but there is one thing which is related to
wxGetNumberFromUser and 2.4 compatibility. I do not know if this is the case
here but the header where dialog is available in 2.4/2.5 is different. Perhaps
your application did not upgraded to it and/or use precompiled headers.

ABX

[Robin Dunn]

Post by David Purton
This, as well as running the command from the shell launches the
application ok with the specified cmd args, but launches it under the
current window. If this window happens to be a maximised adobe reader
window, you can't tell when my app starts.

wxPython apps call MacOS.WMAvailable() in the startup code. It checks
that the window manager is available to the current process and as a
side-effect will move the window to the foreground. Here is the C
source for that Python function:

static PyObject *
MacOS_WMAvailable(PyObject *self, PyObject *args)
{
static PyObject *rv = NULL;

if (!PyArg_ParseTuple(args, ""))
return NULL;
if (!rv) {
#if TARGET_API_MAC_OSX
ProcessSerialNumber psn;

/*
** This is a fairly innocuous call to make if we don't have a window
** manager, or if we have no permission to talk to it. It will print
** a message on stderr, but at least it won't abort the process.
** It appears the function caches the result itself, and it's cheap, so
** no need for us to cache.
*/
if (CGMainDisplayID() == 0) {
rv = Py_False;
} else {
if (GetCurrentProcess(&psn) < 0 ||
SetFrontProcess(&psn) < 0) {
rv = Py_False;
} else {
rv = Py_True;
}
}
#else
rv = Py_True;
#endif
}
Py_INCREF(rv);
return rv;
}