Hello,
in the manual for the settings we have :
If true, we’ll always open files using existing SumatraPDF process
ReuseInstance = false
and
if true, documents are opened in tabs instead of new windows (introduced in version 3.0)
UseTabs = true
I don’t see a reason to not set :
ReuseInstance = true
What could be the issue?
What is the benefits? (I guess we safe ressource for the Pc or server…)
I wish you all a good day,
Eric
ReuseInstance was a legacy requirement prior to tabs.
Primarilly to allow DDE users whilst editing to constrain reopening the same file per compilation in one window rather than constantly opening sucessive windows. To open the same file in two windows it was usually set to false.
Tabs in version 3.0 changed that behaviour and effectively provided the same effect in the one tabbed window. Now the recent “new window” allows two tabbed windows like reuse instance false, but there may still be underlying issues when externally called as to which window is primary to be reused.
I always sugest when using as a LaTeX editor previewer, use with tabs on and reuse true as most similar to okular -unique or some other viewers preview modes.
So to answer the question when do we use ReuseInstance=True ?
We use it with tabs (but usually no difference) or without tabs (in this case its essential) whilst using a PDF builder / compiler / modifier / editor to ensure we only see one changing window, not one window per change.
Thank you,
for your reply, and the historical informations.
=> We are using a version higher or equal to 3.00.
If I understand properly :
if we use tabs, we can have the settings : ReuseInstance = true,
and from a server load perspective, I guess it’s better.
My concern is :
If several users call the same exe (with the same settings), I guess they will not have the document of someone else opened.
Example :
the USER 1 : call : SumatraPDF.exe pdfFileA.pdf
the USER 2 : call : SumatraPDF.exe pdfFileB.pdf
The user 1 have not close his sumatra window
Is it a risk the user 2 : get 2 files displayed : pdfFileA.pdf and pdfFileB.pdf ?
I wish you a good day,
Eric
Not entirely sure, as not recommended to use one exe between users.
If using a portable copy in program files on a single machine (not recommended, but a common scenario, I as admin user employ) where a common settings file would be shared, then sequental usage should not conflict unless both admin users are concurrently logged in.
Using one common installed exe in Program Files, each user should have their own appdata thus no conflict. (but admin need to control user rights etc.)
Using seperate installed exe in appdata each should not conflict. (prefered)
Using common -appdata folder then again there could be conflict. (not prefered for multiple users unless very well managed)
In summary the way you want it to work will of necessity dictate the optimum way to install and use. Hence the default since 3.2 is each user defaults to own exe and settings.
ok thank you,
today the exe is in a folder on a server.(no installation, just copied)
and the exe is called from an application publish with citrix.
So for now, we will keep the settings : ReuseInstance set to false.
Thank you again all the quick answer you have given.
Eric
If the exe is One common portable version but the users each have own different -appdata “path\SumatraPDF” user folder \sumatraPDF-settings.txt then there should be no conflict with any values.
//server/sumatrapdf.exe -appdata "//server/users folder" common.pdf
The problem is that the portable by design for one user would write to one common settings file in its own folder thus NOT recommended for multiple users.
Yes it is a common portable version.
We really appreciate the portable version to avoid the installation on all the servers.
For the settings :
I have added the file : sumatrapdfrestrict.ini ( SavePreferences = 0 )
To forbidden the changes of the settings, and not save the history of the files opened.
We want to have the exact same behavior for all the users.
Since several years now, we use sumatraPdf, to display quickly the pdf , to not set lock on the pdf and benefit of the reload the changes. We really appreciate it.
I recently work again on the topic, because for the first time the command line was not working in a very specific conditions, I have been not able to reproduced, and never happens again.
I didn’t had the idea to catch the error or message at this moment…(And not sure what is the best way to catch it)
With your configuration it is possible for one user to potentially interfere with another user experience, especially if viewing the same file, so avoid using pre-release where pressing A to highlight could certainly cause interference.
SumatraPDF is not intentionally designed for concurrent users, but as you point out has some benefits (perhaps with drawbacks too)
The other factor here is that there is a boundary for file locking which was 10 MB but more recently increased to 32 MB so that can throw up some odd responces when opened by a user and for example their editor.
ok, good to know.
We will see then if :
1/ we move from the version 3.00 to the version 3.2
2/ Redesign the way we use sumatra, to avoid potential issue.
I wish you a good day,
Eric