applicationShouldTerminate delegate does not work in Leopard

  • Hi all,

    I have implemented a Cocoa application in which I am hiding Dock icon by
    setting LSUIElement to 1 in info.plist. Now I run the application in *
    Panther* & *Tiger*. When I quit that application from Activity monitor, *
    applicationShouldTerminate* delegate method was get called.  But when I run
    that in *Leopard* & quit it from Activity Monitor,
    applicationShouldTerminate delegate method was not get called.

    In Leopard, *applicationShouldTerminate* delegate methods gets called only
    if application has Dock icon otherwise not.

    So is there any other way by which I can catch quitting an background
    application from Activity monitor in Leopard?

    Thanks,
    Palav

    --

    There are many things in your life that will catch your eye but only a few
    will catch your heart....pursue those'.
  • I tried to use it; but it(applicationWillTerminate) also does not get called
    if my application does not Dock icon.
    In console log, I get following prints for both(applicationWillTerminate &
    applicationShouldTerminate) the cases:

    17/01/08 12:07:25 PM com.apple.launchd[156]
    ([0x0-0x52052].com.yourcompany.test[374]) Exited abnormally: Interrupt

    Any other solution??

    Thanks,
    Palav

    On Jan 17, 2008 7:09 AM, Clint Shryock <cts3e1...> wrote:

    > could you use :
    > - (void)applicationWillTerminate:( NSNotification<https://developer.apple.com/leopard/devcenter/docs/documentation/Cocoa/Refe
    rence/Foundation/Classes/NSNotification_Class/Reference/Reference.html#//ap
    ple_ref/doc/c_ref/NSNotification
    >
    > *)*aNotification*
    > *
    > *
    > do do what you need to?
    >
    >

    --

    There are many things in your life that will catch your eye but only a few
    will catch your heart....pursue those'.
  • On 17.01.2008, at 07:41, parag vibhute wrote:

    > I tried to use it; but it(applicationWillTerminate) also does not
    > get called
    > if my application does not Dock icon.
    > In console log, I get following prints for
    > both(applicationWillTerminate &
    > applicationShouldTerminate) the cases:
    >
    > 17/01/08 12:07:25 PM com.apple.launchd[156]
    > ([0x0-0x52052].com.yourcompany.test[374]) Exited abnormally: Interrupt
    >
    > Any other solution??

    Did you try installing a signal handler for the SIGTERM signal? Not
    sure whether your application is sent a quit appleevent if you don't
    have a dock icon, but if not, the OS will probably signal your app to
    terminate it...
    (make sure to read about what you're allowed to do in your signal
    handler!)

    HTH,
    </jum>
  • I implemented SIGTERM, SIGINT, SIGQUIT handler in cocoa application in main
    function. They does not get called either my application has Dock icon or
    not i.e. in both cases thoes handler does not get called. I observed this in
    Tiger also.

    Thanks,
    Palav

    On Jan 17, 2008 1:20 PM, Jens Miltner <jum...> wrote:

    >
    > On 17.01.2008, at 07:41, parag vibhute wrote:
    >
    >> I tried to use it; but it(applicationWillTerminate) also does not
    >> get called
    >> if my application does not Dock icon.
    >> In console log, I get following prints for
    >> both(applicationWillTerminate &
    >> applicationShouldTerminate) the cases:
    >>
    >> 17/01/08 12:07:25 PM com.apple.launchd[156]
    >> ([0x0-0x52052].com.yourcompany.test[374]) Exited abnormally: Interrupt
    >>
    >> Any other solution??
    >
    > Did you try installing a signal handler for the SIGTERM signal? Not
    > sure whether your application is sent a quit appleevent if you don't
    > have a dock icon, but if not, the OS will probably signal your app to
    > terminate it...
    > (make sure to read about what you're allowed to do in your signal
    > handler!)
    >
    > HTH,
    > </jum>
    >
    >

    --

    There are many things in your life that will catch your eye but only a few
    will catch your heart....pursue those'.
  • I'have just try with a background cocoa application on Leopard, and
    the Activity Moniter call SIGINT. But you cannot do anything in a
    signal handler, so it will not be helpfull.

    static void sigtest(int arg) {
      printf("%s\n", __func__);
    }

    signal(SIGINT, sigtest);

    Le 17 janv. 08 à 12:40, parag vibhute a écrit :

    > I implemented SIGTERM, SIGINT, SIGQUIT handler in cocoa application
    > in main
    > function. They does not get called either my application has Dock
    > icon or
    > not i.e. in both cases thoes handler does not get called. I observed
    > this in
    > Tiger also.
    >
    > Thanks,
    > Palav
    >
    > On Jan 17, 2008 1:20 PM, Jens Miltner <jum...> wrote:
    >
    >>
    >> On 17.01.2008, at 07:41, parag vibhute wrote:
    >>
    >>> I tried to use it; but it(applicationWillTerminate) also does not
    >>> get called
    >>> if my application does not Dock icon.
    >>> In console log, I get following prints for
    >>> both(applicationWillTerminate &
    >>> applicationShouldTerminate) the cases:
    >>>
    >>> 17/01/08 12:07:25 PM com.apple.launchd[156]
    >>> ([0x0-0x52052].com.yourcompany.test[374]) Exited abnormally:
    >>> Interrupt
    >>>
    >>> Any other solution??
    >>
    >> Did you try installing a signal handler for the SIGTERM signal? Not
    >> sure whether your application is sent a quit appleevent if you don't
    >> have a dock icon, but if not, the OS will probably signal your app to
    >> terminate it...
    >> (make sure to read about what you're allowed to do in your signal
    >> handler!)
    >>
    >> HTH,
    >> </jum>
    >>
    >>
    >
    >
    > --
    >
    > There are many things in your life that will catch your eye but only
    > a few
    > will catch your heart....pursue those'.
    >
  • On 17.01.2008, at 12:54, Jean-Daniel Dupas wrote:

    >
    > I'have just try with a background cocoa application on Leopard, and
    > the Activity Moniter call SIGINT. But you cannot do anything in a
    > signal handler, so it will not be helpfull.
    >
    > static void sigtest(int arg) {
    > printf("%s\n", __func__);
    > }
    >
    > signal(SIGINT, sigtest);

    Well, you _can_ do some things in a signal handler (otherwise they
    would be uterless unuseful ;-).
    You could, e.g. set a flag or signal a semaphore - that's all within
    the allowed APIs, IIRC.

    You can't call any Cocoa functions directly, but you could have e.g. a
    background thread block on a semaphore or mutex and signal/unlock from
    the signal handler, then the background thread could perform a
    selector on the main thread, etc.
    Quite a bit jumping through hoops, but then again, if it's the only
    option...

    However, the OP meanwhile mentioned that no signals seem to be send to
    the process, which seems a bit strange, as in my experience an app is
    either send an appleevent or signalled...

    </jum>
  • Le 17 janv. 08 à 13:45, Jens Miltner a écrit :

    >
    > On 17.01.2008, at 12:54, Jean-Daniel Dupas wrote:
    >
    >>
    >> I'have just try with a background cocoa application on Leopard, and
    >> the Activity Moniter call SIGINT. But you cannot do anything in a
    >> signal handler, so it will not be helpfull.
    >>
    >> static void sigtest(int arg) {
    >> printf("%s\n", __func__);
    >> }
    >>
    >> signal(SIGINT, sigtest);
    >
    > Well, you _can_ do some things in a signal handler (otherwise they
    > would be uterless unuseful ;-).
    > You could, e.g. set a flag or signal a semaphore - that's all within
    > the allowed APIs, IIRC.
    >
    > You can't call any Cocoa functions directly, but you could have e.g.
    > a background thread block on a semaphore or mutex and signal/unlock
    > from the signal handler, then the background thread could perform a
    > selector on the main thread, etc.
    > Quite a bit jumping through hoops, but then again, if it's the only
    > option...
    >

    Yes, there is effectively many options, but they are rarely used
    correctly. Just have a look at all those "How to catch crash" articles
    on the web that extensively call Obj-C in signal handlers.

    > However, the OP meanwhile mentioned that no signals seem to be send
    > to the process, which seems a bit strange, as in my experience an
    > app is either send an appleevent or signalled...

    Yes, and I have an application that run as a background application
    (using plist keys, ...) and it effectively receives a SIGINT signal
    (I'm running 10.5.1). So the problem is probably in the signal handler
    installation, not in the OS.
  • Hi Jean,

    I tried signal handling on Panther, Tiger & Leopard. But found that on
    Panther & Tiger, it did not work & only worked on Leopard which is strange.
    Is that the only solution?

    Thanks,
    palav

    On Jan 17, 2008 6:33 PM, Jean-Daniel Dupas <devlists...> wrote:

    >
    > Le 17 janv. 08 à 13:45, Jens Miltner a écrit :
    >
    >>
    >> On 17.01.2008, at 12:54, Jean-Daniel Dupas wrote:
    >>
    >>>
    >>> I'have just try with a background cocoa application on Leopard, and
    >>> the Activity Moniter call SIGINT. But you cannot do anything in a
    >>> signal handler, so it will not be helpfull.
    >>>
    >>> static void sigtest(int arg) {
    >>> printf("%s\n", __func__);
    >>> }
    >>>
    >>> signal(SIGINT, sigtest);
    >>
    >> Well, you _can_ do some things in a signal handler (otherwise they
    >> would be uterless unuseful ;-).
    >> You could, e.g. set a flag or signal a semaphore - that's all within
    >> the allowed APIs, IIRC.
    >>
    >> You can't call any Cocoa functions directly, but you could have e.g.
    >> a background thread block on a semaphore or mutex and signal/unlock
    >> from the signal handler, then the background thread could perform a
    >> selector on the main thread, etc.
    >> Quite a bit jumping through hoops, but then again, if it's the only
    >> option...
    >>
    >
    > Yes, there is effectively many options, but they are rarely used
    > correctly. Just have a look at all those "How to catch crash" articles
    > on the web that extensively call Obj-C in signal handlers.
    >
    >> However, the OP meanwhile mentioned that no signals seem to be send
    >> to the process, which seems a bit strange, as in my experience an
    >> app is either send an appleevent or signalled...
    >
    > Yes, and I have an application that run as a background application
    > (using plist keys, ...) and it effectively receives a SIGINT signal
    > (I'm running 10.5.1). So the problem is probably in the signal handler
    > installation, not in the OS.
    >

    --

    There are many things in your life that will catch your eye but only a few
    will catch your heart....pursue those'.
  • This is to inform to those guys that who will/are struggle for this problem:

    1. On Panther & Leopard, when u quit background process from activity
    monitor, "applicationshouldterminate" delegate gets called.
    2. On Leopard, when u quit background process from activity monitor,
    "applicationshouldterminate" delegate does not get called but you can catch
    SIGINT singal. So write SIGINT handler.
    3. On Panther & Leopard, when u quit background process from activity
    monitor, you can not catch SIGINT signal. So only way to catch it is use
    "applicationshouldterminate" method.

    Now my next thing will be to find macros for each OS which will execute OS
    dependant code.

    Thanks,
    Palav

    On Jan 17, 2008 6:45 PM, parag vibhute <parag.vibhute...> wrote:

    > Hi Jean,
    >
    > I tried signal handling on Panther, Tiger & Leopard. But found that on
    > Panther & Tiger, it did not work & only worked on Leopard which is strange.
    > Is that the only solution?
    >
    > Thanks,
    > palav
    >
    >
    > On Jan 17, 2008 6:33 PM, Jean-Daniel Dupas <devlists...> wrote:
    >
    >>
    >> Le 17 janv. 08 à 13:45, Jens Miltner a écrit :
    >>
    >>>
    >>> On 17.01.2008, at 12:54, Jean-Daniel Dupas wrote:
    >>>
    >>>>
    >>>> I'have just try with a background cocoa application on Leopard, and
    >>>> the Activity Moniter call SIGINT. But you cannot do anything in a
    >>>> signal handler, so it will not be helpfull.
    >>>>
    >>>> static void sigtest(int arg) {
    >>>> printf("%s\n", __func__);
    >>>> }
    >>>>
    >>>> signal(SIGINT, sigtest);
    >>>
    >>> Well, you _can_ do some things in a signal handler (otherwise they
    >>> would be uterless unuseful ;-).
    >>> You could, e.g. set a flag or signal a semaphore - that's all within
    >>> the allowed APIs, IIRC.
    >>>
    >>> You can't call any Cocoa functions directly, but you could have e.g.
    >>> a background thread block on a semaphore or mutex and signal/unlock
    >>> from the signal handler, then the background thread could perform a
    >>> selector on the main thread, etc.
    >>> Quite a bit jumping through hoops, but then again, if it's the only
    >>> option...
    >>>
    >>
    >> Yes, there is effectively many options, but they are rarely used
    >> correctly. Just have a look at all those "How to catch crash" articles
    >> on the web that extensively call Obj-C in signal handlers.
    >>
    >>> However, the OP meanwhile mentioned that no signals seem to be send
    >>> to the process, which seems a bit strange, as in my experience an
    >>> app is either send an appleevent or signalled...
    >>
    >> Yes, and I have an application that run as a background application
    >> (using plist keys, ...) and it effectively receives a SIGINT signal
    >> (I'm running 10.5.1). So the problem is probably in the signal handler
    >> installation, not in the OS.
    >>
    >
    >
    >
    > --
    >
    > There are many things in your life that will catch your eye but only a few
    > will catch your heart....pursue those'.
    >

    --

    There are many things in your life that will catch your eye but only a few
    will catch your heart....pursue those'.
  • Sorry in third point, please Tiger instaead of Leopard.

    Sorry once again.

    palav

    On Jan 17, 2008 7:04 PM, parag vibhute <parag.vibhute...> wrote:

    > This is to inform to those guys that who will/are struggle for this
    > problem:
    >
    > 1. On Panther & Leopard, when u quit background process from activity
    > monitor, "applicationshouldterminate" delegate gets called.
    > 2. On Leopard, when u quit background process from activity monitor,
    > "applicationshouldterminate" delegate does not get called but you can catch
    > SIGINT singal. So write SIGINT handler.
    > 3. On Panther & Leopard, when u quit background process from activity
    > monitor, you can not catch SIGINT signal. So only way to catch it is use
    > "applicationshouldterminate" method.
    >
    > Now my next thing will be to find macros for each OS which will execute OS
    > dependant code.
    >
    > Thanks,
    > Palav
    >
    >
    >
    > On Jan 17, 2008 6:45 PM, parag vibhute < <parag.vibhute...> wrote:
    >
    >> Hi Jean,
    >>
    >> I tried signal handling on Panther, Tiger & Leopard. But found that on
    >> Panther & Tiger, it did not work & only worked on Leopard which is strange.
    >> Is that the only solution?
    >>
    >> Thanks,
    >> palav
    >>
    >>
    >> On Jan 17, 2008 6:33 PM, Jean-Daniel Dupas <devlists...>
    >> wrote:
    >>
    >>>
    >>> Le 17 janv. 08 à 13:45, Jens Miltner a écrit :
    >>>
    >>>>
    >>>> On 17.01.2008, at 12:54, Jean-Daniel Dupas wrote:
    >>>>
    >>>>>
    >>>>> I'have just try with a background cocoa application on Leopard, and
    >>>
    >>>>> the Activity Moniter call SIGINT. But you cannot do anything in a
    >>>>> signal handler, so it will not be helpfull.
    >>>>>
    >>>>> static void sigtest(int arg) {
    >>>>> printf("%s\n", __func__);
    >>>>> }
    >>>>>
    >>>>> signal(SIGINT, sigtest);
    >>>>
    >>>> Well, you _can_ do some things in a signal handler (otherwise they
    >>>> would be uterless unuseful ;-).
    >>>> You could, e.g. set a flag or signal a semaphore - that's all within
    >>>
    >>>> the allowed APIs, IIRC.
    >>>>
    >>>> You can't call any Cocoa functions directly, but you could have e.g.
    >>>> a background thread block on a semaphore or mutex and signal/unlock
    >>>> from the signal handler, then the background thread could perform a
    >>>> selector on the main thread, etc.
    >>>> Quite a bit jumping through hoops, but then again, if it's the only
    >>>> option...
    >>>>
    >>>
    >>> Yes, there is effectively many options, but they are rarely used
    >>> correctly. Just have a look at all those "How to catch crash" articles
    >>> on the web that extensively call Obj-C in signal handlers.
    >>>
    >>>> However, the OP meanwhile mentioned that no signals seem to be send
    >>>> to the process, which seems a bit strange, as in my experience an
    >>>> app is either send an appleevent or signalled...
    >>>
    >>> Yes, and I have an application that run as a background application
    >>> (using plist keys, ...) and it effectively receives a SIGINT signal
    >>> (I'm running 10.5.1). So the problem is probably in the signal handler
    >>> installation, not in the OS.
    >>>
    >>
    >>
    >>
    >> --
    >>
    >> There are many things in your life that will catch your eye but only a
    >> few will catch your heart....pursue those'.
    >>
    >
    >
    >
    > --
    >
    > There are many things in your life that will catch your eye but only a few
    > will catch your heart....pursue those'.
    >

    --

    There are many things in your life that will catch your eye but only a few
    will catch your heart....pursue those'.
  • Le 17 janv. 08 à 14:15, parag vibhute a écrit :

    > Hi Jean,
    >
    > I tried signal handling on Panther, Tiger & Leopard. But found that
    > on Panther & Tiger, it did not work & only worked on Leopard which
    > is strange. Is that the only solution?
    >
    > Thanks,
    > palav

    In pre-leopard versions, Activity Monitor was sending an AppleEvent to
    all graphical applications (even "background only"). But the apple
    event is handle only if the application call -[NSApp run] or if it
    installs a custom event handler.
    AFAR, Activity Monitor was not able to properly quit some background
    application on Tiger and Panther, so (I'm maybe wrong) I think they
    decide to change the "quit application" implementation to support a
    wider range of applications, but at some cost.

    IMHO, The simplest solution will be to add a SIGINT handler in
    Leopard, and find a safe way to call -[NSApp terminate:nil] when this
    handler is call.
  • On Jan 17, 2008 6:41 AM, parag vibhute <parag.vibhute...> wrote:

    > I tried to use it; but it(applicationWillTerminate) also does not get called
    > if my application does not Dock icon.
    > In console log, I get following prints for both(applicationWillTerminate &
    > applicationShouldTerminate) the cases:
    >
    > 17/01/08 12:07:25 PM com.apple.launchd[156]
    > ([0x0-0x52052].com.yourcompany.test[374]) Exited abnormally: Interrupt
    >
    > Any other solution??

    If you're using launchd, note that as of Leopard you'll probably have
    to use "-S Aqua" as an option to "launchctl load" in order to get the
    windowserver connections etc. set up properly.

    Hamish
  • No I am not using launchd, my application is simple cocoa application which
    does not have dock icon.

    Thanks,
    Palav

    On Jan 17, 2008 7:56 PM, Hamish Allan <hamish...> wrote:

    > On Jan 17, 2008 6:41 AM, parag vibhute <parag.vibhute...> wrote:
    >
    >> I tried to use it; but it(applicationWillTerminate) also does not get
    > called
    >> if my application does not Dock icon.
    >> In console log, I get following prints for both(applicationWillTerminate
    > &
    >> applicationShouldTerminate) the cases:
    >>
    >> 17/01/08 12:07:25 PM com.apple.launchd[156]
    >> ([0x0-0x52052].com.yourcompany.test[374]) Exited abnormally: Interrupt
    >>
    >> Any other solution??
    >
    > If you're using launchd, note that as of Leopard you'll probably have
    > to use "-S Aqua" as an option to "launchctl load" in order to get the
    > windowserver connections etc. set up properly.
    >
    > Hamish
    >

    --

    There are many things in your life that will catch your eye but only a few
    will catch your heart....pursue those'.
previous month january 2008 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today