The user wants to always extract ZIP files "here" whenever he double clicks onto a ZIP file, so we tried to set the double click event to "Copy EXTRACT=sub HERE", which works as long as DO is not restarted.
Unexpected:
Upon restart of DO, the event will be set back to the simple "go" command, but if you change the double click event to something that also makes use of the "go" command, the changed event will survive a restart of DO. If the command was changed to "go dummy" e.g., it will be there the next time you start DO (which is expected).
Workaround:
For now, the user makes use of the "double click + ALT" event entry, which does not reset itself.
There seems to be some unknown default / overriding logic for the regular double click event somewhere, not sure if it's meant to be like that?
Forgot to say:
I was able to reproduce on my own DO installation. We also tried around with running in admin mode and things, checked permissions etc., but it does not seem to be related to any of this, because the configuration file "CompressedFolder.oxr" will always reflect the initial change, but magically resets some of it's content after DO is restarted, if the actual command is different from anything "GO .." related.
If you uncheck Preferences / Zip & Other Archives / Zip Files / Enable internal Opus Zip support the entries will no longer be overwritten, but Copy EXTRACT=sub HERE won't work anymore, either.
You could use 7-Zip instead:
@nodeselect
"/programfiles\7-Zip\7z.exe" e {filepath} -o{filepath|noext}
If the internal Zip support is turned on, archive double-click events are "self-repairing" to ensure they match the chosen settings.
(It allows the events to be edited to add extra arguments to the Go command, e.g. so you can make archives open in a new tab instead, but if it's a completely different command it'll be replaced.)
It'll work again if you enable the alternative Zip handler in the Archives plugin (Preferences / Zip & Other Archives / Archive and VFS Plugins).
From a quick test, that lets you change the double-click event as well, surviving a restart.
Whoo, thank you, so it's even more complex than I thought.. o)
That self-healing aspect is kind of unexpected, maybe it would make sense to have a "Restore" button instead? Just a quick idea of course, since it's not clear such a self-healing operation happens here and there (and where else?!) and under what conditions, it took quite some time to figure out what's going on exactly! o)
But ok, so this works as designed right now, and we have the option to use the other ZIP plugin. I'm not sure what side effects / drawbacks this would have, but I will inform the user which had the problem, maybe he is eager to find out. o)
Another idea I get while writing this, what about adding the "ZIP files" settings page to a "ZIP-internal" entry in the list of the archives plugins? Having a "ZIP-internal" and "ZIP-external" entry could make very clear that there are multiple ways to handle the ZIP archives.
I'm actually surprised there is another way / plugin to handle ZIPs. Why is one "self healing" and the other is not? What about the other archive plugins, do they self-heal as well? I think I digress, sorry.. o)
I'm fine with the information you provided so far, thanks again! o)