launchInDefaultBrowser returned -43


#1

Hi,

In that code:

int main (int argc, char* argv[])
{
    URL("http://www.juce.com").launchInDefaultBrowser( );
    return 0;
}

I get the following error (whereas the URL is properly launched):

JUCE v3.0.2 
2014-02-08 12:38:11.424 foo[1097:903] LSOpenFromURLSpec() returned -43 for application (null) path http://www.juce.com.

like there:

http://www.juce.com/forum/topic/problem-urllaunchindefaultbrowser

Is that a known issue?

( Latest JUCE / Mac OS X 10.6.8 / Xcode 3.2 / Base & Deployment 10.6 ).


#2

Don't know of any issues there, and it works just fine for me. Could be a 10.6 problem, I guess, since LSOpenFromURLSpec is an old API call, probably deprecated long ago.


#3

juce_mac_Files.mm / line: 416

return [workspace openFile: juceStringToNS (fileName)]
    || [workspace openURL: filenameAsURL];

The bug comes from the first expression (it launches also OK without):

return [workspace openFile: juceStringToNS (fileName)];

 I'll investigate a bit more (but my Obj-C is old). 


#4

Is that totally stupid?

return [workspace openFile: [filenameAsURL path]]
   || [workspace openURL: filenameAsURL];

 


#5

Ok.. but  hang on, if the openFile call fails, then it should call the openURL function, which you say works (?)


#6

Yes, that's it. With the code below, my example works fine without any error.

if (parameters.isEmpty())
   DBG("FOO");
   return [workspace openURL: filenameAsURL];

So the problem does NOT come from openURL (as at first impression) but from openFile (that fails -as it is expected to do- but reports also the "returned -43" error).


#7

That workaround doesn't look right to me.

Let me get this straight.. the real problem is that in 10.6 (but not later), the openFile method is incorrectly returning true when it actually failed? Because if it failed and returned false, everything would be ok, right?


#8

I'll make a more comprehensive example of what's happen as soon as i have more time.


#9
int main (int argc, char* argv[])
{
    URL("http://www.juce.com").launchInDefaultBrowser( );
    return 0;
}
if (parameters.isEmpty()) {

    if ([workspace openFile: juceStringToNS (fileName)] == YES) {
        DBG("openFile YES"); return YES;

    } else {
        DBG("openFile NO");
        if ([workspace openURL: filenameAsURL] == YES) {
            DBG("openURL YES"); return YES;
        }
    }

    return NO;

}
MacBook-de-nicolas:debug nicolas$ ./Foo
JUCE v3.0.2
2014-02-08 18:22:38.621 Foo[2130:903] LSOpenFromURLSpec() returned -43 for application (null) path http://www.juce.com.
openFile NO
openURL YES

"...the openFile method is incorrectly returning true when it actually failed?"

No, that what's hap:

1. openFile fails with a message error and returns NO.

2. openURL properly launches the URL in the browser.


#10

So in fact there's no problem at all?


#11

There's no problem at all if you consider that an error message is not a problem.

 


#12

It's only an internal debug message inside the OS, I don't think it really matters.


#13


You are certainly right. 

Test the existence of the file ( [NSFileManager defaultManager] fileExistsAtPath: ) is finally the only way i found to avoid the message in the console. But surely it's not worth the cost. 

Thanks anyway.