When you change a setting, it's stored in the former location.
But every once in a while, my settings are lost. Does it mean they're reverted from the latter location?
Could it be whenever I run multiple instances of the app (e.g. when I scan multiple files using command line parameters)? If so, it could be solved by making each ClamWinPortable.exe wait in the background until it detects a previous instance was closed. But better yet, you can use
Settings:
IfFileExists `$PROGRAMDIRECTORY\ClamWin.conf` ComSpecCheck
(thus skipping UpdateSettings).
If you run multiple instances of ClamWin Portable it'll delete your settings. Your other post mentions the problematic code.
The first closed instance moves your settings to $SETTINGSDIRECTORY and the next closed instance deletes them.
I'll lock out multiple instances in the next release. Having it sitting around waiting for another to finish is a bit infeasible (and unexpected behavior from a user's point of view as no apps do that). And it'll collide with a possibly-running local version.
Sometimes, the impossible can become possible, if you're awesome!
It would mean not being to check more than 1 file at a time (when they don't take over an entire single folder).
Why not just using the aforementioned line? Especially due to your answer in the other topic.
Because it could exist there due to a crash, not due to already running. So we'd have to manage clamwin.exe itself running and waiting for that to close to properly move things back and forth. But, if we do that, it will NEVER close if a local copy of clamwin is running.
Sometimes, the impossible can become possible, if you're awesome!
Couldn't we rename clamwin.exe to clamwinPAc.exe and check whether this one is running or not?
It could still mean the program got crashed earlier on.
The right way is to detect the existence of a process called ClamWinPortable.exe.
Also see How to pass in multiple file/folder paths via a rigth-click event(verb) to an executable?, where they mention solutions such as DDE and IPC. I realize ClamWin Portable wasn't meant for right clicking, but I bet various advanced users still do so manually.
No, then the launcher would detect itself and would never finish.
Compare other official apps. There is one process AppnamePortable.exe running, but many processes Appname.exe. The launchers detect the existence of Appname.exe and close after the last.
Hi John, seems like you locked out multiple instances in version 0.96.5.
IMHO that's not a good fix for the bug above cause users need multiple instances. Otherwise it's not possible to check more than 1 file at a time (mentioned by lwc too). Say you have configured your Firefox Portable to automatically check every downloaded file with ClamWin Portable. Now it happends that we see the warning "Another instance of ClamWin is already running. Please close other instances of ClamWin before launching ClamWin Portable." and the file won't be checked.
Why not use the following?
The latest config would stay in the $PROGRAMDIRECTORY, but it does always a backup to the $SETTINGSDIRECTORY. And if there is no config inside the $PROGRAMDIRECTORY (due to an update or other reasons) the config from the $SETTINGSDIRECTORY will be used.
I think you can achieve the same effect by simply renaming the word "Rename" (no pun intended) into "CopyFiles".
But your last post made it seem other PortableApps already know how to handle this situation without file tricks.
BTW, I think John's approach is still better than the old approach:
ClamWin Portable bug fixed, but important feature lost
I enabled multiple instances in this release and it handles it gracefully. A local clamwin won't interfere unless it is running. The ClamWin tray icon running locally does not interfere.
Sometimes, the impossible can become possible, if you're awesome!
What did you change to bring back multiple instances without bringing back the old bug? I don't mean the actual lines, but the principle (because we discussed different ways to do it).