anotherInstanceStarted not getting called

If a Juce application goes into a modal state in its JUCEApplication::initialise() function, and another instance is started, anotherInstanceStarted() doesn’t get called. This happens regardless of the return value of moreThanOneInstanceAllowed().

I might guess the reason is that the message loop doesn’t deliver the ActionListener message while in the modal state but to be honest, it all looks complicated to me and I am unsure.

My goal is to display an AlertWindow indicating to the user that a second instance is not allowed, since I take over the audio hardware. During initialise() there could be a lengthy startup for which I want progress or something. It is also possible that initialise() will fail and I am in the middle of showing an AlertWindow indicating the reason.

I don’t know of any reason why the message wouldn’t be received just because it’s a modal loop… It sounds more likely to me that the OS thinks your app hasn’t finished initialising, and is maybe stopping messages from being sent to it, or something like that. Have you tried doing your initialisation in an async callback after the initialisation method has finished?

never a open windows in intialisation, use a async updater

[quote=“chkn”]never a open windows in intialisation, use a async updater[/quote]

Yeah but splash screens and progress screens need to be displayed and updated during initialization so that is not really an opton.

I have not tried that, and it appears I was confused about anotherInstanceStarted(). I thought it went to the newly launched app. I was not aware that it is instead sent to the app already running. I will rerun the scenario and try to see if there is still a problem.

Any news on this as I’ve encountered the same problem? I rely on anotherInstanceStarted being called (as it does nicely on Windows) in order to shut down the running instance.

Edit: And it doesn’t work postponing initialization after initialise has finished…


In :

void MessageManager::broadcastMessage(const String&)

Maybe that’s why it doesn’t work ? :wink:

The mac uses a different mechanism to tell the running process when you try to open a document that it can use, and that ends up getting delivered by anotherInstanceStarted()

Hmm, ok, then how do I do to get it to work ? If I do /pathToMyApp/ --myarg all I get in the terminal is:

JUCE v1.53.46 Another instance is running - quitting...
and my debug printout within anotherInstanceStarted shines with its absence…

And all that is called where the above is printed is MessageManager::broadcastMessage(…), and I am using the tip… :?

Edit: Ok, I don’t have any document associated with my application, and besides this works fine on windows…

[quote=“robiwan”]Hmm, ok, then how do I do to get it to work ? If I do /pathToMyApp/ --myarg all I get in the terminal is:

JUCE v1.53.46 Another instance is running - quitting...
and my debug printout within anotherInstanceStarted shines with its absence…[/quote]

Let me clarify, I run one instance in the debugger (in which anotherInstanceStarted does NOT get called), and start the other from a terminal…

does this help?

No, it does not! Check the implementation of JUCEApplication::initialiseApp(…) + MessageManager::broadcastMessage(…). The mechanism that works on Windows is simply not implemented on Mac !

Edit: Well if this is not going to be implemented on Mac, could I at least suggest the following:

  1. Add an overridable function to JUCEApplication called handleAnotherApplicationStartup(const String& cmdLine)
  2. Call that function in initialiseApp instead of MessageManager::broadcastMessage
  3. Call MessageManager::broadcastMessage in the default implementation of the new function

That way I can at least workaround the defunct Mac implementation.

Yes, you’re right - on the mac it’s not implemented except to handle a document being opened. I’ll look into sorting something out there.

Thnx Jules, much appreciated :slight_smile:

When you’re at it, can you fix so it is possible to set the return value of the “second” application ? With my solution it could be done as:

void MyApplication::handleAnotherInstanceStarted(const String& commandLine)

I don’t understand your request about the return value - that’s already done, isn’t it?

I don’t think so, since the second application won’t be called with initialise, so there’s nowhere for the application to set setApplicationReturnValue. Am I missing something ?

initialise will always be called.

I’ve just checked in a version which adds broadcast messages for the mac, so hopefully that’ll sort out your other problem.

Will initialise be called even for the second application when moreThanOneInstanceAllowed returns false and appLock->enter(0) also returns false (which
is the case I’m trying to get to work) ? The code in JUCEApplication::initialiseApp does not look that way ?

Thanks, I’ll get back with a report how it turns out.

Sorry, but it doesn’t seem to work. I trace the call to MessageManager::broadcastMessage, but the first instance never gets a call to anotherInstanceStarted. Jules, I really need this to work so while the bugs are ironed out, could you please endulge me and add a protected function in JUCEApplication called handleAnotherInstanceStarted(const String& cmdLine), in which the default implementation calls MessageManager::broadcastMessage ??

I’ve done this on my own machine and using my own IPC messaging system it works perfectly, however, since there are more people than me in the project I really don’t want to distribute a patch to everybody, let alone having a git repo of my own…