Quit not quitting

General
21

Same result, now with LogMyDeath on all destructors containing any code.

No evidence of anything starting but not finishing.

22

Try this small modification and see if you can spot a difference.

Sub LogMyDeath (o As Object, topOfMethod As Boolean)
  const kDebug = true
  #if kDebug
  static prefix as string

  if not topOfMethod then
    prefix = prefix.Left( prefix.Len - 1 )
  end if

  dim ti as Introspection.TypeInfo = Introspection.GetType( o )
  dim name as string = ti.FullName
  dim msg as string = prefix + "The object " + name + " " + _
    if( topOfMethod, "is about to die...", "has died" )
  System.DebugLog msg

  if topOfMethod then
    prefix = prefix + "•"
  end if
  #else
  #pragma unused o
  #pragma unused topOfMethod
  #endif
End Sub

If I did this right, you should get log entries that look something like:

The object blah is about to die…
The object blah has died
The object wha is about to die…
•The object nono is about to die…
•The object nono has died
The object wha has died
23

That works - and shows me those items that die in the middle of other deaths - but still getting a 1:1 correlation. Sent a screen shot via Messages.

I’ve noticed that in the startup routines I have 4 MBS plugins being initiated - let me disable those and see if anything changes.

WKUA

24

No impact on removing all MBS instances.

As before, app quits but the updateInitiator.destructor still doesn’t get called.

25

Is the issue a timing problem? Meaning that the app quits fine when you go through the debugger.

Have you tried to cheat by closing all windows first and then quitting with a timer?

26

Kem

This is the complete log from Console - launch to Update to Quit.

12/03/2015 13:01:15.262 Actio[93724]: The object wSplash.wSplash is about to die…
12/03/2015 13:01:15.263 Actio[93724]: •The object Cocoa.NSColor is about to die…
12/03/2015 13:01:15.263 Actio[93724]: •The object Cocoa.NSColor has died
12/03/2015 13:01:15.263 Actio[93724]: •The object Cocoa.NSColor is about to die…
12/03/2015 13:01:15.263 Actio[93724]: •The object Cocoa.NSColor has died
12/03/2015 13:01:15.264 Actio[93724]: The object wSplash.wSplash has died
12/03/2015 13:01:21.902 Actio[93724]: The object UndoItem is about to die…
12/03/2015 13:01:21.902 Actio[93724]: The object UndoItem has died
12/03/2015 13:01:26.970 Actio[93724]: The object wPrefs_Project._wrapper_ccOwnerDetails1 is about to die…
12/03/2015 13:01:26.970 Actio[93724]: The object wPrefs_Project._wrapper_ccOwnerDetails1 has died
12/03/2015 13:01:26.970 Actio[93724]: The object ComboBox_email is about to die…
12/03/2015 13:01:26.970 Actio[93724]: The object ComboBox_email has died
12/03/2015 13:01:26.972 Actio[93724]: The object wPrefs_Project._wrapper_ccHF_settings_Footers is about to die…
12/03/2015 13:01:26.972 Actio[93724]: The object wPrefs_Project._wrapper_ccHF_settings_Footers has died
12/03/2015 13:01:26.973 Actio[93724]: The object wPrefs_Project._wrapper_ccHF_settings_Headers is about to die…
12/03/2015 13:01:26.973 Actio[93724]: The object wPrefs_Project._wrapper_ccHF_settings_Headers has died
12/03/2015 13:01:40.658 Actio[93724]: The object wLaunch.wLaunch is about to die…
12/03/2015 13:01:40.658 Actio[93724]: The object wLaunch.wLaunch has died

27

Have you simply tried to place a break just before the quit, and proceed step by step to see where the program goes afterward ? That beep is so strange…

30

Beatrix
It doesn’t seem to be a timing issue - I get much the same result whether in debug or in runtime.

Michel
Yes, I’ve been doing that. The strange thing is that the app seems to quit prematurely and a number of events that you would expect to trigger (e.g. deconstructors for existing objects and even the app.close event are not firing).

Even with a lot of useful assistance from Kem we’ve been unable to get to the bottom of it. If @Joe Ranieri is listening I’d welcome his views as to where to look for this problem.

The strangest clue I’ve just uncovered is when putting an action into the app.close event and running it in the debugger, it brings up various Runtime error messages e.g.:

Location: Common/plugin.cpp:5785
Condition: False
Message: Could not open plugin
RBREALSQLDatabase.xojo_plugin:0

and

Location: Common/plugin.cpp:5785
Condition: False
Message: Could not open plugin
RBInternetEncodings.xojo_plugin:0

31

The Close “action” James means is setting a property (in this case, App.UpdateInitiater) to nil. This should be non-issue.

32

Hate to suggest it, but, corrupted project?

33

Tim

I’d hate to think so but I’ve often wondered what one was.

Isn’t the whole project just a set of text files? What else is saved that could become corrupted? Is there a way of just saving as text and reloading?

34

Save the project as XML, quit, open the XML project, re-save as binary (or text, whichever it is now).

35

Well the SaveAs XML trick didn’t work unfortunately.

But I did notice something else.

Issuing Quit within a button.action just results in beep and the app.close event doesn’t fire.

Whereas, using File/Quit does make the app.close event fire, and the app closes properly.

Clearly they are not the same thing.

36

Is this button on a modal dialog?

37

The first quote makes it sound like the plugin is calling back to one of your methods which has Quit in it. The second sounds like Quit is in a PushButtons Action. If it’s the former then the plugin may be using another thread and then the behavior sounds like what Beatrix mentioned.

38

[quote=174144:@James Pitchford]Well the SaveAs XML trick didn’t work unfortunately.

But I did notice something else.

Issuing Quit within a button.action just results in beep and the app.close event doesn’t fire.

Whereas, using File/Quit does make the app.close event fire, and the app closes properly.

Clearly they are not the same thing.[/quote]

I suppose you have made sure the Action event of the button actually fired. Is a system.debuglog after the quit executed in there ?

Have you tried calling Quit anywhere else besides the famous button action event and the menu handler ?

If the menu handler is on App, for instance, would it not be worth trying a myQuit method next to it containing the same code ?

I am myself battling a beeping gremlin in my last Windows program. I did not understand why under some circumstances the program became unresponsive and any click made a beep. In fact, there had been a nil object exception but the error dialog was displayed behind my program main window. Of course, as I clicked the close window box and Autoquit as true, everything disappeared when the program was dismissed. Only when I moved the main window did I discover the critter.

39

Will, Michel

Sorry if the dialog is causing confusion. I had added different buttons to help with distilling down the problem - so some of the earlier findings may not be consistent with the later findings.

Anyway, I do seem to have made some progress, it could have been the SaveAs XML trick that has partially solved it, though the underlying problem is still there. Let me try to summarise:

I have added a test simple button on a number of windows to simulate the issue. The button has the following code:

app.UpdateInitiater = new Kaju.UpdateInitiater quit

The first step of the code is simply to ensure that an UpdateInitiator is present, that should be deconstructed on Quit.

I am also monitoring app.cancelClose, app.close and app.updateInitiator.deconstructor on the Console.

For the button on a Modal window, the app just beeps at me and none of the events are fired. Apparently quit doesn’t work on a modal window, whereas File/Quit does.

For all other regular windows, the button fires both app.cancelClose and app.close. This is an improvement on yesterday where neither of these were firing on quit. For the moment I attribute that to the SaveAs XML trick. But in all those windows, the updateInitiator.deconstructor does not fire.

The above is the same whether the app is run in debug or runtime.

So, now that app.close is firing, I can apply the code suggested by Kem

updateInitiater = nil

This then forces the UpdateInitiater.destructor to fire, which runs the updating routines, and I get back on track again.

So whilst this solves my immediate problem, it doesn’t explain why objects are not being deconstructed on quit. The results above are suggestive of a corrupted file, but cannot be sure.