Quit not quitting

I’m trying to use either Kem’s Kaju or MBS’s Updater routines, both of them issue a Quit to close the app before re-opening the new version.

However, the Quit command doesn’t quit the app - it just gives me a “beep” and no indication of where the problem occurs.
I’ve tried inserting an app.CancelClose event - but it doesn’t get that far - something else stops the quit.

I have one window with a cancelClose event, but it doesn’t reach that either.

If I use the File/Quit menu from the same location, that works fine.

What might be preventing the quit?

quit in the open event of the app maybe ?

Not quit sure what you mean Norman. If you mean is there a quit somewhere in the app.open event - then no, there isn’t.

do you have a catch of exceptions that is catching the end exception ?

Not by design. I’ve tried putting a catch in after the quit statement per:

Exception err
msgbox “error”

But it doesn’t catch anything when quit goes “beep”.

Further, if I force close any open windows first I get an EndException on quit, which I suppose I could ignore. But this seems a hard way to make the quit function do its job.

[code]//manually close all windows
while window(0) <> nil
'dim s as string = window(0).Title
window(0).close
wend

quit

Exception err
select case err
case isa EndException
MsgBox “EndException”
end select[/code]

Put a break point on the quit
Then when you hit the break point say where the quit is (ie/ the action event of a button on a modal dialog etc)
20 questions isn’t going to get an answer very quickly

Norman
The Quit is in a method called by the Updating routines - ultimately it is caused by pressing an “install update” button on a window.

Is the quit called from a thread? I remember I have a Feedback issue open that quit called from a thread only does a beep and nothing more.

Beatrix
No, the quit is in the main thread.

Norman
This does feel like 20 questions doesn’t it - but I’ve not yet hit on that elusive clue that will resolve the problem.

[quote=173644:@Norman Palardy]Put a break point on the quit
Then when you hit the break point say where the quit is (ie/ the action event of a button on a modal dialog etc)[/quote]

Tim
Er, thanks?

The quit is issued by a button.actio marked quit. There’s nought more complicated than that. The break point just shows the button.action as the calling item.

Am I missing something in this?

[code]Sub Action()

quit

End Sub
[/code]

If you have a Try/Catch that catches all exceptions, you should write it this way:

try
  // some code
catch err as RuntimeException
  if err IsA EndException or err IsA ThreadEndException then
    raise err
  else
    // Deal with your exception
  end if
end try

Of course, if you know the type of exception you are looking for, you should only catch it specifically.

We now know these things about your code:

  1. Your app is dying a premature death on quit, but
  2. Because it’s quitting, an exception isn’t being reported, and
  3. The IDE is not letting you properly trace the error either.

Since the problem is occurring in some object’s Destructor, I suggest you insert something like this at the top and bottom of each Destructor:

LogMyDeath( self, true )
// Code
LogMyDeath( self, false )

The global LogMyDeath method would look something like this:

Sub LogMyDeath (o As Object, topOfMethod As Boolean)
  const kDebug = true
  #if kDebug
  dim ti as Introspection.TypeInfo = Introspection.GetType( o )
  dim name as string = ti.FullName
  dim msg as string = "The object " + name + " " + _
    if( topOfMethod, "is about to die...", "has died" )
  System.DebugLog msg
  #else
  #pragma unused o
  #pragma unused topOfMethod
  #endif
End Sub

On quit, you can check the log to see which Destructor is not finishing. Once you’ve found the problem(s), you can switch off the constant so it won’t affect your final code.

gulp, OK, will try.

At a quick count I have about 200 objects defined, excluding all the objects in MacOSLib and other external pieces of software, so this might take a while.

Jim

Start with just your own objects. I’d be surprised if the problem was in something like MacOSLib.

Using a script:

[code] DoCommand (“NewMethod”)

// Add dev and error catch to current method
Dim header As String
Dim footer as string

header = “LogMyDeath( self, true )” + endofLine
footer = endofLine + “LogMyDeath( self, false )”

if instr(text, “LogMyDeath( self, true )” ) = 0 then
text = header +endofline+ text
end if

if instr(text, “LogMyDeath( self, false )” ) = 0 then
text = text + endofLine + footer
end if[/code]

Speeds it up a bit.

Nice.

Kem

Results of the first run - not so informative.

I get corresponding “about to die” “has died” for each of the objects. Shows that nothing is interrupting the destructors on my objects.

Last object to die is wLaunch - which is the launching window - then the app Ends.

I will now add your code to all destructors that contain any code - and report back.