I am installing my App with Innosetup. When I want to uninstall it, I notice that the App is still running in the background and I can not uninstall. Why this is happening ? When I quit the App, should not stop completely ? I have a thread in the App and a SQLiteDB.
It should but…
As a matter of practice (and good housekeeping) I recommend that, on program close, you check to see if the thread is still running and stop it if it is. Also, make sure the database is closed at the same time. I just don’t trust the operating system not to interfere with non-implicit cleanup.
Thank you Dale.
Windows 2015r2.3 : still having the problem that the application.exe is still shown in the Windows taskmanager after quiting it. I’ve made very sure to close every single connection, App.Autoquit = True , but did not manually set every single object to nil.
Does anybody recognize this issue ? and what can be done to solve it ?
Put some logging code in each of your Window Destructor events and verify all windows are not only closing, but being destroyed, too.
App.Autoquit = True closes the app when the last window is closed.
Perhaps you have a window instance still live?
Apologies for a simple question, but :
Do you have a quit menu item?
Does it execute the command Quit?
(I see Michael beat me to it)
I only have one Window in my application and I have the standard “File/Exit” and the CancelClose as shown here:
[code] Function CancelClose(appQuitting as Boolean) As Boolean
#Pragma Unused appQuitting
// no message in debug mode
#If DebugBuild Then
App.CloseConnections // just to be sure all database connections are closed properly before quiting
Quit
Return False
#Endif
// to be executed if not in debug mode
dim btnResponse as integer = _
msgbox (Lng("MSG_Quit") + " ?", 292, App.ExecutableFile.NameWithoutExtensionMBS)
if btnResponse = 6 then
App.CloseConnections
Return False // quit applicaion
else
Return True // cancel
end if
End Function[/code]
It turns out that the application doesn’t unload itself from memory at all. If I repeat launching and quiting I see the used memory going up. (windows taskmanager).
The windows/close event fires as soon as the windows is about to close.
Does that window have the implicitinstance property set to ‘true’?
yes it has.
I was testing another application I’ve build a few months ago, with just one window, and that one doesn’t show up this problem.
Turn it off and see what happens.
If the window is called Window1, any reference to Window1 will create an instance of the window, also called Window1
But if you also
dim w as Window1
w = new Window1
then you can easily end up with 2 windows
One called w
One called Window1 and probably never actually used…
For now I have added some logging:
#If DebugBuild Then
if not App.WriteMessageToDb("Open - Win_Disclaimer") then break
#endif
InstanceID, time, version, message
---------------------------------------
8 {6CA859EB-40BF-5C48-99B0-07CEC4F35AAD} 2015-09-25 17:42:08 1.0.0.68 Open - Win_Disclaimer
9 {6CA859EB-40BF-5C48-99B0-07CEC4F35AAD} 2015-09-25 17:42:12 1.0.0.68 Disclaimer accepted.
10 {6CA859EB-40BF-5C48-99B0-07CEC4F35AAD} 2015-09-25 17:42:12 1.0.0.68 Close - Win_Disclaimer
--------------------------------------- #If DebugBuild Then
if not App.WriteMessageToDb("Close - Win_Disclaimer") then break
#endif
A question, Joost. When you’re looking at the Task Manager as you’re closing the application, does your application disappear in the Applications and/or Processes tab? If it does, then the memory it used is possibly just cached and will free up the next time Windows does garbage collection. If the application remains in the Applications and/or Processes tab then it is not being completely closed.
Calling App.Quit within App.CancelClose (or App.Close, I think) can prevent your app from quitting, too. I’ve run into this before.
When I start my application and quit it once the main windows is painted, and repeat this multiple times, I keep seeing the exe-name and the 10 MB of memory it uses, multiple times too. So when I should start and quit a 100 times, I should see 1 GB ram in use and 100 processes running.
The logging I’ve added as shows me the expected results:
Open - Win_Disclaimer
Open - Win_Splash
Open - Win_Main
Close - Win_Splash
Open - Win_Preferences
Close - Win_Preferences
Close - Win_Main
Close - Win_Disclaimer
Close - App
I will start skipping things from being loaded and try to figure out why applications doesn’t really quit itself.
Thanks… think I have a look at that too.
Don’t do that in my app, so this is not the cause.
Just a hunch, but you may want to use a timer launched in Close to quit one or two seconds later.
Maybe your app needs to finish something, like writing to disk, or a socket, that prevents it from closing right away.
[quote=216270:@Michel Bujardet]Just a hunch, but you may want to use a timer launched in Close to quit one or two seconds later.
Maybe your app needs to finish something, like writing to disk, or a socket, that prevents it from closing right away.[/quote]
Exactly Michel, this was the fix for the problem.
What I did was closing the current window in an action event, one code line after opening the next one.
I changed that in a way that now the just opened window is responsible for closing the one that launched it. This is to make sure that the window that needs to be closed has finished all it’s events before being forced to close and there is nothing pending at the same time.
This solved my problem.
Thanks guys for being sparring partners.
That leads to a question in my mind. Is it common practice for a new window to close the one that launched it? Joost, I’m not criticizing your methods but I’ve always been of the mindset that if one window needs to launch a second window then the original window should be the one to close the new one. Either that or the application, on closing, should check to be sure all windows are closed. Something like:
// clean up any open windows
For i As Integer = WindowCount - 1 DownTo 0
If Window(i) <> Nil Then Window(i).close
Next
I’d like some opinions here, please.
- Dale
@Dale Arends : that’s actually what I am doing: except for dialogs, make the process that opened another one responsible for closing it.
Thing to be aware of is that it turned out that a window which is busy with another task via a plugin, and being closed by another process at the same time, not really closes. And this without giving notice.
I do agree with you that there need to be a sort of “garbadge collector” you have shown above, but expected that as a part of the quit-procedure of the framework.