I have an app that on Open check’s the database schema version, upgrades if necessary and continues on. This method also check’s if the db schema is greater than expected (i.e. the user has installed on old version of the app) & logs this to the event log before quitting.
However App.Quit does not quit the application - it is just ignored. In debug I can step right past the line and analyzing the project reports no issues.
Is there a way to force a Web app to quit? Or should I just raise an exception & not handle it (ugly)?
What is likely happening, Wayne, is you still have a reference open to an object somewhere. So even though you’ve run the quit event, the app truly won’t quit until that reference is removed. Make sure you close out everything, remove all handlers, etc.
Sorry, not to hijack this thread… but is this the case for threads too? Can you successfully kill and nullify a thread if something within it is still referenced? I’m thinking it’s the same as you stated; however, want to be for sure. I’m fairly new to operating things within individual threads with something as complicated as I’m working on right now, and it seems I have a slow memory leak… which I didn’t have before I added thread handling, so I’m pretty confident this is the issue. I use addHandler to reference worker threads, then once they’re done, I removeHandler on them; however, I dim a database and other objects within the threads that apparently aren’t getting destroyed properly… even though I properly kill and nullify the threads when I’m done with them.
Unless you have circular references killing the thread & niling it SHOULD result it and its properties being priorly disposed of
However IF there are circular references (say from a property to the thread & the thread to the property) then all you will have done is lose references to that thread & slowly leak them
From the documentation, it “appears” that the “ending” events that occur (i.e.: app quitting or a thread ending) are supposed to close all references. But I have found this not to be the case or that I am misunderstanding what is supposed to happen. I have found that I have needed to undo everything I have setup - handler references, closing out all objects, etc.
But I see normal just replied so maybe I have circular references going on somewhere.
As a matter of interest only. In the app.open event I call a method “init” which checks the schema (and where I called quit). I have now added a property to app and am setting that to true. The next line after init checks this property & if true executes quit. And it works.
So I’m thinking the reference was to the method called. I do use addhandler in a couple of places but not yet in execution. A simple way to force a quit would be useful I think.
Thing is Norman (hey I can spell), I was calling quit in a method called from Open, but now am calling quit from the Open event which works.
But I must admit I’m heavily using the ODBC plugin and to call that flaky would be very friendly indeed. I’ve had so many IDE & debug crashes in the last week you wouldn’t imagine (or maybe you would in your position).
Does this issue have something in common with the question how you deal with window objects in general?
Esp the way you show and close them? I have the feeling that by referencing a window e.g.
dim NewWindow as MyWindowObjectName
NewWindow.ShowModalWithin(self)
app.quit works far better than just calling
MyWindowObjectName.Show
And do not forget to explicit close your windows with:
[quote=137294:@Wayne Golding]
But I must admit I’m heavily using the ODBC plugin and to call that flaky would be very friendly indeed. I’ve had so many IDE & debug crashes in the last week you wouldn’t imagine (or maybe you would in your position).[/quote]
When debugging with a database, don’t attempt to step to the next item in code when viewing a recordset in the debugger. That will cause a crash of the IDE right away. So if you need to go in and look at a recordset in the debugger, view what you need to view then, back out to variables or globals or something like that.
[quote=137290:@Norman Palardy]I know desktop apps have some issues with quit in app.open <https://xojo.com/issue/23266>
Wonder if this is related[/quote]
So Norman,
This is a bug report from TWO years ago. All that’s ever been done is that it’s been “reviewed.” I know you guys have big fish to fry but big fish need to eat minnows to survive.
I think this is the sort of thing that gets people frustrated. A bug report from two years ago with an attached example, should certainly get more love than “reviewed” in a 24 month period…
This is a bug report from TWO years ago. All that’s ever been done is that it’s been “reviewed.” I know you guys have big fish to fry but big fish need to eat minnows to survive.
I think this is the sort of thing that gets people frustrated. A bug report from two years ago with an attached example, should certainly get more love than “reviewed” in a 24 month period…[/quote]
Jon, you could be a little harsh ; the bug does not appear in 2014R2.1 where the app quits just fine and the window does not appear…
Maybe all you can say is that the case should show “Fixed”
[quote=137434:@Michel Bujardet]Jon, you could be a little harsh ; the bug does not appear in 2014R2.1 where the app quits just fine and the window does not appear…
Maybe all you can say is that the case should show “Fixed” ;)[/quote]
No, no. Norman brought it up as a possible issue:
[quote]Norman Palardy 14 hours ago Xojo Inc, IOS Alpha Testers See you at XDC 2015 !
I know desktop apps have some issues with quit in app.open Feedback Case #23266
Wonder if this is related[/quote]
So he opened the door.
I’m not trying to be harsh. It’s an example of a bug that was filed with a project reproducing it and nothing has ever been done except “review.” I have some similar bugs open this way. One is what I would think would be a pretty significant bug in the keyup event in Cocoa text fields. It fires twice and still does in the latest versions.
I have a workaround for this but it requires me to use a special subclass of the textfield. This should be an easy fix for Xojo. And I included an example project to boot.
I have others as well.
So if a Xojo employee opens a door about a bug that’s not been touched in two years, I think it’s fair game to question why.
[quote=137438:@Jon Ogden]No, no. Norman brought it up as a possible issue:
So he opened the door.
f a Xojo employee opens a door about a bug that’s not been touched in two years, I think it’s fair game to question why.[/quote]
My point was just that the bug he was referring to has indeed been fixed.
Now the other bug you now posted may indeed be fair game as well.
[quote=137440:@Michel Bujardet]My point was just that the bug he was referring to has indeed been fixed.
Now the other bug you now posted may indeed be fair game as well.
Bugs are always a sensitive issue…[/quote]
I would not draw the conclusion that the bug Norman mentioned is fixed. To me, his words:
Indicate quite the opposite from you. Just because you don’t see the bug doesn’t mean the bug is not still there. And if it is fixed, Xojo should indeed close the bug.
