Potential bug/undocumented feature?
-
Good day. I am seeing behaviour that causes me to perceive that there may be a bug, or an undocumented feature, as it relates to multi-instance settings:
It presents that any subsequent instance of NPP fails to load the snapshot backup settings and any edits being made to files in the subsequent instances are not benefited with snapshot backups.
As info: v7.8.5 32-bit on a Win10 64bit host configured to use appdata.
Sadly, this resulted in an hours-ish of work being vaporized this morning, as I was making edits, and stroked F12 by accident. This caused an abrupt crash on a multi-monitor setup (might be another issue, but I disabled the mapping for now). I did find a crash dump file, but am not figuring out how to use same to restore any of the file edits I had been making.
Can someone else see if their instance of NPP behaves similarly? TIA.
-t
-
@Tod-Wulff said in Potential bug/undocumented feature?:
any subsequent instance of NPP fails to load the snapshot backup settings and any edits being made to files in the subsequent instances are not benefited with snapshot backups.
I believe this is true.
I do not know if it is documented but you can check here if you’d like: https://npp-user-manual.org/this resulted in an hours-ish of work being vaporized this morning,
Here’s one more reason to use hard-named files. That is, don’t leave
new1,new3, etc sitting around too long; give them hard pathnames in the file system. -
@Alan-Kilborn Thanks for the time in responding and affirming this behaviour exists on your end. It is appreciated.
As an aside, I had my shortcuts setup to run as administrator (for editing stuff inside of prog files directories (namely .inis)). This behaviour is counter-intuitive in that when in admin mode, this setting isn’t honored when a new as-admin instance is instantiated. Turning that off and opening new instances (either from tab context, or via command line, or with the setting to always force new instance) seems to resolve the undesired behaviour.
