Do not block external editing (II) — looking for a *workaround*

Forum for the PDF-XChange Editor - Free and Licensed Versions

Moderators: TrackerSupp-Daniel, Tracker Support, Paul - Tracker Supp, Vasyl-Tracker Dev Team, Chris - Tracker Supp, Sean - Tracker, Ivan - Tracker Software, Tracker Supp-Stefan

Post Reply
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

Do not block external editing (II) — looking for a *workaround*

Post by DIV »

I wanted to reply to this locked post
https://forum.pdf-xchange.com/viewtopic.php?f=62&t=28037 : Do not block external editing

Let me say frankly up front that although I understand the interest of LaTeX users (inter alia) to be able to refresh a displayed PDF file when external changes are made, it's not something that I currently have any need for myself. I also note & repeat the very clear and conclusive message from the Tracker Software support staff that while the request has been considered, it is difficult to implement as a built-in feature of their current application, and therefore implementation as a built-in feature could not be expected in the near or medium term.


So, with that preamble, I thought it is better to focus attention on usable workarounds. Indeed, it sounds like some of the previous correspondents may be competent programmers, so can some JavaScript capabilities of Editor be harnessed to create a workaround?

The workflow I have in mind is like this.
  1. There's an existing PDF file called "C:\myFile.pdf".
  2. The user has a JavaScript 'macro' which takes as input the relevant PDF file name — in this instance "C:\myFile.pdf".
  3. The macro immediately makes a copy of this as, say, "C:\myFile.COPY.pdf" or C:\tmp\PDF_copies\myFile.pdf". [Don't care too much about issues of write access: assume the user has write access.]
  4. The macro opens the copy in Editor. So the copy is locked by Editor, but the original is able to be freely changed by LaTeX-lovers.
  5. The user changes the original file (externally from Editor).
  6. The user then switches back to Editor and runs a second JavaScript macro. [The user knows they should run the macro, because they just changed the original.] The macro could take a file name as an input, but more convenient is probably just to set it to that of the active tab.
  7. The macro takes the filename of the open/active document and infers the name of the original file; it then checks that the original file exists, and finally checks whether it's different from the (opened) copy.
  8. If the answers to the last two questions are both "yes", then the second macro immediately closes the open (copied) file, overwrites the old copy with a new copy in the file system, and then opens the new copy in Editor.
  9. With default settings, Editor will think that it is reopening the same file (same file name & path), so if changes are minor it would probably open to the same page as had just been displayed. [I don't know what would happen in the case of major changes.] Obviously there could be some delays if the file in question is huge — but that would likely still be the case even with built-in functionality.
So, feel free to constructively criticise the specific details of the above suggestion, but more importantly I suggest that those with short-term needs/wishes focus on devising a practical workaround.

—DIV
User avatar
TrackerSupp-Daniel
Site Admin
Posts: 8438
Joined: Wed Jan 03, 2018 6:52 pm

Re: Do not block external editing (II) — looking for a *workaround*

Post by TrackerSupp-Daniel »

Hello, DIV

Thank you for starting this topic, Looking over your suggestion, I think that may be possible, though I cannot offer much help with it. I hope this starts a constructive discussion with some JS experts on the forums here.

Kind regards,
Dan McIntyre - Support Technician
Tracker Software Products (Canada) LTD

+++++++++++++++++++++++++++++++++++
Our Web site domain and email address has changed as of 26/10/2023.
https://www.pdf-xchange.com
Support@pdf-xchange.com
Post Reply