Xojo Conferences
MBSOct2019CologneDE

does quit ever call its menu handler? (Real Studio network user group Mailinglist archive)

Back to the thread list
Previous thread: Shorter Names in Dock?
Next thread: ODBC login question...


Re: Jaguar RB?   -   German Bauer
  does quit ever call its menu handler?   -   Roger Carlson
   Re: does quit ever call its menu handler?   -   Kevin Ballard
    Re: does quit ever call its menu handler?   -   Roger Carlson
     Re: does quit ever call its menu handler?   -   Kevin Ballard
      Re: does quit ever call its menu handler?   -   Joseph J. Strout
       Re: does quit ever call its menu handler?   -   Roger Carlson
       Re: does quit ever call its menu handler?   -   Kevin Ballard
       WebDAV   -   Kevin Wojniak
    Re: does quit ever call its menu handler?   -   Will Leshner
     Re: does quit ever call its menu handler?   -   Roger Carlson
      Re: does quit ever call its menu handler?   -   Will Leshner
       Re: does quit ever call its menu handler?   -   Roger Carlson
        Re: does quit ever call its menu handler?   -   Will Leshner

does quit ever call its menu handler?
Date: 07.05.02 20:15 (Tue, 7 May 2002 12:15:53 -0700)
From: Roger Carlson

I'm trying to give the user a chance to save changes or keep working
after he calls quit. I do this with a cancelclose event in my main
window.

The trouble is that one of my sub-windows keeps closing before the main
window, and it doesn't come back.

the obvious solution is to put something in the sub-windows cancel close
event - I want to be able to check and see if the user has hit quit, or
if the user is just trying to close the sub-window without quitting the
whole app.

so I put a bit of code in my app's fileQuit menu handler, and set the
global boolQuitMenuItemCalled = true.

the trouble is, it never changes value, it's like the quit menu item
never calls its handler. Does it? How can I intercept it? how can I tell
the difference between a quit and a close?


---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: does quit ever call its menu handler?
Date: 07.05.02 20:26 (Tue, 07 May 2002 15:26:28 -0400)
From: Kevin Ballard
On 5/7/02 3:15 PM, "Roger Carlson" <<email address removed>> wrote:

>
> I'm trying to give the user a chance to save changes or keep working
> after he calls quit. I do this with a cancelclose event in my main
> window.
>
> The trouble is that one of my sub-windows keeps closing before the main
> window, and it doesn't come back.
>
> the obvious solution is to put something in the sub-windows cancel close
> event - I want to be able to check and see if the user has hit quit, or
> if the user is just trying to close the sub-window without quitting the
> whole app.
>
> so I put a bit of code in my app's fileQuit menu handler, and set the
> global boolQuitMenuItemCalled = true.
>
> the trouble is, it never changes value, it's like the quit menu item
> never calls its handler. Does it? How can I intercept it? how can I tell
> the difference between a quit and a close?

Under OS 9 you could make the Quit menuitem a subclass of MenuItem instead
of QuitMenuItem, then deal with enabling it yourself and quitting the app
yourself. But under OS X, the QuitMenuItem goes in the application menu, and
it sends the app an AppleEvent (at least, I think it does) which means you
can't intercept it as RB would catch it first.

Re: does quit ever call its menu handler?
Date: 07.05.02 20:46 (Tue, 7 May 2002 12:46:20 -0700)
From: Roger Carlson

On Tuesday, May 7, 2002, at 12:26 PM, Kevin Ballard wrote:

> Under OS 9 you could make the Quit menuitem a subclass of MenuItem
> instead
> of QuitMenuItem, then deal with enabling it yourself and quitting the
> app
> yourself. But under OS X, the QuitMenuItem goes in the application
> menu, and
> it sends the app an AppleEvent (at least, I think it does) which means
> you
> can't intercept it as RB would catch it first.

that's right.

to be technical, if I make it a menuitem instead of quitmenuitem, I get
two of them - one under file that I can handle, and one under
application that I can't. It's a pain in the %^&*(.

I definitely think it's time to drop support for classic ; - )

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: does quit ever call its menu handler?
Date: 07.05.02 20:51 (Tue, 07 May 2002 15:51:18 -0400)
From: Kevin Ballard
On 5/7/02 3:46 PM, "Roger Carlson" <<email address removed>> wrote:

> to be technical, if I make it a menuitem instead of quitmenuitem, I get
> two of them - one under file that I can handle, and one under
> application that I can't. It's a pain in the %^&*(.

You could use declares to enable the one under the application menu, but
once again, it would send AppleEvents to your app which you can't see
because RB catches them for you.

Re: does quit ever call its menu handler?
Date: 07.05.02 20:59 (Tue, 7 May 2002 12:59:24 -0700)
From: Joseph J. Strout
At 3:51 PM -0400 5/7/02, Kevin Ballard wrote:

>You could use declares to enable the one under the application menu, but
>once again, it would send AppleEvents to your app which you can't see
>because RB catches them for you.

Are you sure? I think we pass the AppleEvent to your app before
handling it, so you have a chance to do so yourself first.

And then, when we do handle it, we do so by invoking the usual
CancelClose/Close stack, so ISTM that you could do whatever you need
to do there and have it work in a cross-platform way. But I missed
the start of this thread, so maybe there's some reason that won't
work in this case.

Cheers,
- Joe

Re: does quit ever call its menu handler?
Date: 07.05.02 21:17 (Tue, 7 May 2002 13:17:48 -0700)
From: Roger Carlson

On Tuesday, May 7, 2002, at 12:59 PM, Joseph J. Strout wrote:

> At 3:51 PM -0400 5/7/02, Kevin Ballard wrote:
>
>> You could use declares to enable the one under the application menu,
>> but
>> once again, it would send AppleEvents to your app which you can't see
>> because RB catches them for you.
>
> Are you sure? I think we pass the AppleEvent to your app before
> handling it, so you have a chance to do so yourself first.
>
> And then, when we do handle it, we do so by invoking the usual
> CancelClose/Close stack, so ISTM that you could do whatever you need to
> do there and have it work in a cross-platform way. But I missed the
> start of this thread, so maybe there's some reason that won't work in
> this case.

yeah, I don't think it's getting passed to my app, so in my
cancelclose/close stack, I can't tell if the user hit quit or if the
user hit the red button. The first thing that gets executed is the
cancelclose event, nothing else (I've put test code everywhere in my
app). Maybe I've screwed something up, but with a QuitMenuItem, I am not
getting a fileQuit menu handler or anything else.

rb 4.02 and 10.1.4

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: does quit ever call its menu handler?
Date: 07.05.02 21:26 (Tue, 07 May 2002 16:26:26 -0400)
From: Kevin Ballard
On 5/7/02 3:59 PM, "Joseph J. Strout" <<email address removed>> wrote:

> Are you sure? I think we pass the AppleEvent to your app before
> handling it, so you have a chance to do so yourself first.

Really? I thought RB just dealt with it invisibly.

> And then, when we do handle it, we do so by invoking the usual
> CancelClose/Close stack, so ISTM that you could do whatever you need
> to do there and have it work in a cross-platform way. But I missed
> the start of this thread, so maybe there's some reason that won't
> work in this case.

The point was the poster used CancelClose to put up a save changes dialog,
but the subwindow always closed before the main window's cancelclose stopped
the quit.

Re: does quit ever call its menu handler?
Date: 07.05.02 20:59 (Tue, 7 May 2002 12:59:01 -0700)
From: Will Leshner
I don't think this is true. I use the trick of setting isQuitting
boolean to true in one of my app's FileQuit menu handler and it works
just fine. This is a Carbon-only app, so maybe there is a problem with
doing this for a PPC app that I don't know about. But for a Carbon app,
that should work.

On Tuesday, May 7, 2002, at 12:26 PM, Kevin Ballard wrote:

> On 5/7/02 3:15 PM, "Roger Carlson" <<email address removed>> wrote:
>
>>
>> I'm trying to give the user a chance to save changes or keep working
>> after he calls quit. I do this with a cancelclose event in my main
>> window.
>>
>> The trouble is that one of my sub-windows keeps closing before the main
>> window, and it doesn't come back.
>>
>> the obvious solution is to put something in the sub-windows cancel
>> close
>> event - I want to be able to check and see if the user has hit quit, or
>> if the user is just trying to close the sub-window without quitting the
>> whole app.
>>
>> so I put a bit of code in my app's fileQuit menu handler, and set the
>> global boolQuitMenuItemCalled = true.
>>
>> the trouble is, it never changes value, it's like the quit menu item
>> never calls its handler. Does it? How can I intercept it? how can I
>> tell
>> the difference between a quit and a close?
>
> Under OS 9 you could make the Quit menuitem a subclass of MenuItem
> instead
> of QuitMenuItem, then deal with enabling it yourself and quitting the
> app
> yourself. But under OS X, the QuitMenuItem goes in the application
> menu, and
> it sends the app an AppleEvent (at least, I think it does) which means
> you
> can't intercept it as RB would catch it first.
>
> --
> Kevin Ballard
> kevin@sb.org
> Email from Korea or China must go to <kevin.nb@sb.org>
> http://kevin.sb.org/
>
> ---
> Subscribe to the digest:
> <mailto:<email address removed>>
> Unsubscribe:
> <mailto:<email address removed>>

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: does quit ever call its menu handler?
Date: 07.05.02 21:15 (Tue, 7 May 2002 13:15:30 -0700)
From: Roger Carlson

On Tuesday, May 7, 2002, at 12:59 PM, Will Leshner wrote:

> I don't think this is true. I use the trick of setting isQuitting
> boolean to true in one of my app's FileQuit menu handler and it works
> just fine. This is a Carbon-only app, so maybe there is a problem with
> doing this for a PPC app that I don't know about. But for a Carbon app,
> that should work.

are you sure your quit item is a QuitMenuItem and not just a menu item?
my fileQuit menu item handler has msgboxes and beeps in it, and it
never, never,never gets called under any condition. I wish it did.

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: does quit ever call its menu handler?
Date: 07.05.02 21:22 (Tue, 7 May 2002 13:22:35 -0700)
From: Will Leshner
If I start a new project, add an Application class, add a FileQuit menu
handler to the applicat class and put MsgBox "I'm Quitting" in the
FileQuit handler, when I run and quit a message box with "I'm Qutting"
pops up. Furthermore, if I build the app for Carbon and run the built
app on Mac OS X and quit, I get a message box with "I'm Quitting". I
just tried it and it works fine.

Perhaps your FileQuit handler isn't in your Application class?

The one problem I see with this is quitting from an AppleEvent. I
worried about this before but I haven't investigated.

On Tuesday, May 7, 2002, at 01:15 PM, Roger Carlson wrote:

>
> On Tuesday, May 7, 2002, at 12:59 PM, Will Leshner wrote:
>
>> I don't think this is true. I use the trick of setting isQuitting
>> boolean to true in one of my app's FileQuit menu handler and it works
>> just fine. This is a Carbon-only app, so maybe there is a problem with
>> doing this for a PPC app that I don't know about. But for a Carbon
>> app, that should work.
>
> are you sure your quit item is a QuitMenuItem and not just a menu item?
> my fileQuit menu item handler has msgboxes and beeps in it, and it
> never, never,never gets called under any condition. I wish it did.
>
> ---
> Subscribe to the digest: <mailto:realbasic-nug-
> <email address removed>>
> Unsubscribe:
> <mailto:<email address removed>>

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: does quit ever call its menu handler?
Date: 07.05.02 22:08 (Tue, 7 May 2002 14:08:26 -0700)
From: Roger Carlson

On Tuesday, May 7, 2002, at 01:22 PM, Will Leshner wrote:

> If I start a new project, add an Application class, add a FileQuit menu
> handler to the applicat class and put MsgBox "I'm Quitting" in the
> FileQuit handler, when I run and quit a message box with "I'm Qutting"
> pops up. Furthermore, if I build the app for Carbon and run the built
> app on Mac OS X and quit, I get a message box with "I'm Quitting". I
> just tried it and it works fine.

thanks, that was really helpful. I've got things narrowed down now.

take the sample project in the paragraph above, and verify that it
works. Now go to the menu and delete the quit item. Now put it back. It
won't call the menu handler again.

what you need to do is delete the menu item and the menu handler, then
create a new menu item, then a new menu handler, and that seems to work.
If the handler hangs around, things get messed up. Deleting the handler
after the fact doesn't seem to fix it, I think you have to delete the
handler while the menu item is gone.

Joe, if you are still reading this thread, is this a bug? should the
handler re-attach to the menu item, if you make a menu item the same
name as the handler, or should the handler go away when the menu item is
deleted? I can understand the behavior I have now, but I'm not sure it's
ideal.

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: does quit ever call its menu handler?
Date: 07.05.02 22:14 (Tue, 7 May 2002 14:14:04 -0700)
From: Will Leshner
It does sound like a bug. It sure wouldn't be what you want as it can be
very confusing. In fact, it was very confusing :)

On Tuesday, May 7, 2002, at 02:08 PM, Roger Carlson wrote:

>
> On Tuesday, May 7, 2002, at 01:22 PM, Will Leshner wrote:
>
>> If I start a new project, add an Application class, add a FileQuit
>> menu handler to the applicat class and put MsgBox "I'm Quitting" in
>> the FileQuit handler, when I run and quit a message box with "I'm
>> Qutting" pops up. Furthermore, if I build the app for Carbon and run
>> the built app on Mac OS X and quit, I get a message box with "I'm
>> Quitting". I just tried it and it works fine.
>
> thanks, that was really helpful. I've got things narrowed down now.
>
> take the sample project in the paragraph above, and verify that it
> works. Now go to the menu and delete the quit item. Now put it back. It
> won't call the menu handler again.
>
> what you need to do is delete the menu item and the menu handler, then
> create a new menu item, then a new menu handler, and that seems to
> work. If the handler hangs around, things get messed up. Deleting the
> handler after the fact doesn't seem to fix it, I think you have to
> delete the handler while the menu item is gone.
>
> Joe, if you are still reading this thread, is this a bug? should the
> handler re-attach to the menu item, if you make a menu item the same
> name as the handler, or should the handler go away when the menu item
> is deleted? I can understand the behavior I have now, but I'm not sure
> it's ideal.
>
> ---
> Subscribe to the digest: <mailto:realbasic-nug-
> <email address removed>>
> Unsubscribe:
> <mailto:<email address removed>>

---
Subscribe to the digest:
<mailto:<email address removed>>
Unsubscribe:
<mailto:<email address removed>>