I’m just guessing here but most probably your helper is being relaunched
automatically by the OS itself by receiving a reopen command, because it was
running before the user logged out. I think you need to either prevent that or
handle that possibility in your code. I had a similar problem that this is only
seen upon a reopen event and not upon a launch invoked by the user. If you are
using objective C you could insert this in your NSApplication delegate:
- (BOOL)applicationShouldHandleReopen:(NSApplication *)theApplication
hasVisibleWindows:(BOOL)flag
{
return NO;
}
- (BOOL)applicationShouldOpenUntitledFile:(NSApplication *)sender
{
return NO;
}
If you are using plain C, then you really need to ignore such event or handle
such arguments in your code.
>
> If the helper tool gets bad arguments, it logs and displays to the user an
> error indication. During the last few months, possibly since Yosemite, this
> has occurred and been reported to me by users a half dozen times. The error
> in their logs indicates that the parent process invoking my helper is,
> unfortunately, launchd, so that doesn’t tell me much. It also says that it
> is receiving two arguments instead of five, and that these two arguments are
>
> 1. As expected, the path to the tool.
> 2. -psn_0_430185 (for example)
>
> Regarding the second argument, I’ve seen this before. I know it is a process
> serial number, but when I launch my *app* by doubleclicking in Finder, I
> don’t get a -psn argument. Does the presence of the -psn argument give me
> any clues as to how or why my helper is being invoked?
>
> A couple more clues, from one user…
>
> He told me that the error occurred during login after a restart. It is rare,
> but part of my design, that if my helper is in the middle of a job and gets
> terminated due to user logging out, a fail-safe “standby" launchd agent will
> remain and, the next time the user logs in, will relaunch my tool, properly,
> with five arguments. I’ve retested this mechanism recently and, for me, it
> works fine. The tool runs, re-does it work, and terminates itself.
>
> This user also sent a screenshot showing that, after he dismissed the error,
> a blue *folder* icon named “Helpers” showed up in his ⌘-tab application
> switcher! Believe it:
>
>
>
> Bigger: https://www.flickr.com/photos/113343850@N03/16143184547/
>
> I presume that this is related to my tool, because of my “Contents/Helpers”.
> “Helpers" is not a common folder name. How could OS X get the crazy idea
> that my app’s Contents/Helpers folder belongs in the application switcher?
> Has anyone ever seen a folder in there like that?
>
> Whenever a user reports something totally off the wall like this, I look in
> their logs for evidence of any code-injecting hacks, SIMBL in particular.
> (SIMBL is still around; just caught one last week!) But I’ve not seen any
> such hacks in logs from users with this issue.
>
> Jerry Krinock
>
>
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
