sumatrapdf
sumatrapdf copied to clipboard
sumatrapdfreader
Remember open tabs after sumatra update
@Xashyar The latest round of changes could have moved the settings file which would mean a new one without tab history was built. There is also the issue that [in earlier versions] if only one tab is stored as "open" it is NOT automatically opened on restart (there must be two or more). This is not allways the case in the most recent 3.5 or 3.6 versions I tried testing latest update and got the tabs I expected but have to wait for the next update to check that they are kept during the update cycle.
@GitHubRulesOK Just for the record I tried updating from 11501 to 11515 and none of the tabs got remembered after the update.
@Xashyar That is odd just to check I had waited for a similar update so I had kept two tabs acctive in version 11501 installed in its then current default location (localappdata) then I was told there was the update for 11521 so I downloaded the same bitness installer x64 11521 , it should have behaved roughly the same as 11515 ? Installed and all was well on startup those same two tabs were restored. The goal post are currently moving but the "rules" are still the same SumatraPDF installed to a different location will start a new history (x32 or x64, should not make a difference) Portable (in seperate folders) will ALWAYS start a fresh history
The KEY is that the installer should use the last default settings file (UNLESS the default location shifts, which it did prior to 11501)
@GitHubRulesOK Similar experience when updating 11515 to 11535 (updated while the app was running).
@kjk this seemed to be part of a random problem I had with settings file recently overwritten during an update although on other occasions it has not been. apart from changed settings directory (an explainable change) were there one or two recent updates where this did occur or if the settings file is held open during update can it cause such an issue?
OMG!!! I just lost all open documents when updating from 3.4x to 3.5.2. I had a collection of REALLY important to me files set to open every time, and Sumatra was autoopened on startup! Hmm, it seems that my ENTIRE SETTINGS FILE has been overwritten. I am just speechless.
- Why would this be done?
- Why not warn users? Warning users with a red-flag-bold-capital-lettered dialog box as soon as they ran the installation/update app is trivial to implement.
- or make a backup copy before installation?
- or implement this 4 year old request?
Hopefully I can pull out a backup, find whatever file this list is stored in, and replace it - without breaking something else.
Sigh...
the loss of volatile settings was always a problem when widows updated and destroyed the file in memory by rebooting. Mainly hitting Windows Home version !
Most of those problems dont happen so often now but exactly the same advice then as now, you should always backup any data you wish to preserve against losses. (of course I dont do that I just start afresh every few updates anyway.)
If the file was stable and in the same location it should have been absorbed by the update process, (I use that as a method to add my own preferences before first start.) but sadly there is no way to know if the file is valid so it can be fully renewed in the update process.
AS an example that SumatraPDF simply modifies the file on update I place a line Hello = World in the 3.4 version settings and update to 3.5.2 the file is parsed and the rogue entry moved to the end after the history which was retained
# Settings below are not recognized by the current version
Hello = World
I did update of pre-release and the tabs were properly restored. Would have to narrow down the conditions for loosing tabs.
