AquaSnap complains every time it is started at PortableApps Platform startup to be not closed correctly and needs to be restarted.
I contacted the developer, which told me, that AquaSnap creates on WM_CLOSE to clean up and should not complain about being "dirty" at startup normally.
Using the "official" portable AquaSnap version without the PortableApps Platform, this problem isn't raised!
But using the "official" or the PortableApps version of AquaSnap within the PortableApps Platform causes troubles after rebooting or shutting down and restarting the computer.
How does the PortableApps Plattform care for shutting down all "known" portable applications?
Does it send WM_CLOSE messages or does it kill those applications?
How ever ... I'd be glad to see this fixed, so I can start AquaSnap from within the PortableApps Platform and do not have to start it always a second time after trying to start it from within the PortableApps Platform.
The PortableApps.com Platform will automatically shut down all your running portable apps. It will then warn you of any that can't be automatically closed so you can close them manually. This is why you should always use the platforms close feature in conjunction with your portable apps to ensure they are closed safely.
If you "minimize" an app to the system tray, it's not actually minimized and no longer has an available window. As such, Windows can't send it a WM_CLOSE message and it can't be automatically closed by the PortableApps.com Platform or by anything else.
If you shut down Windows with a portable app running, Windows will unceremoniously kill off the portable launcher without letting it clean up after the app. This could be as serious as leaving data behind locally or as innocuous as leaving the settings files for an app within the App directory as is the case with AquaSnap. The issue with the latter is that the files won't get backed up when you do an app data backup via the platform. And there is a chance for data loss if you upgrade after crashing the app if the app doesn't have a custom installer.ini to allow for preserving the errant data files in the App directory. This is why you're losing your license file and preferences on each upgrade, because the files are still in the App directory. This danger is why the app is warning you every time you inadvertently prevent it from properly closing.
We may provide an "advanced" close option that will kill the app process allowing the portable launcher to then properly clean up. This will have a note about possible data loss as anything left unsaved by the app will be lost when its process is killed.
Sometimes, the impossible can become possible, if you're awesome!
Thanks for this clear explanation of the problem, I better understand now why it's difficult for you to close applications that only have an icon in the tray notification area.
I think that there could be a solution: this kind of application often (if not always) has an invisible window to handle the interactions with the icon. In most case, this invisible window can be identified by its caption and class name.
For example, AquaSnap has an invisible window whose class name is "AquaSnapTrayWindow". If you send a WM_CLOSE to this window, AquaSnap will be closed gracefully.
Maybe you could add a parameter in your *.ini file to handle the case where the WM_CLOSE message needs to be sent to a specific window?
Thanks Grégory for this addition!
In my experience, many many systray applications have a invisible window, so an addition to the INI-specifications to allow the specification of a window title or a window class to find the invisible "message receiver" of systray applications would be good!
Martin Lemburg, Berlin / Germany
Works extremely well as well and less coding.......Just saying
“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss