Get filepath to the active document in a particular SumatraPDF window via SendMessage

[nod5]

Request: Add method for external programs to get the filepath to the active document in a particular SumatraPDF window via SendMessage.

Why: Makes it easier for external programs to interact with the document file and its related .smx annotations file.

What is already possible: If advanced setting FullPathInTitle = true is set then the active document's filepath can be parsed from the window title. Works, but at the cost of filename not visible to user in the window title if the path is very long.

Code for illustration/discussion: Below are my two hacky attempts to add this to SumatraPDF.

1. clipboard method: Makes SumatraPDF receptive to a new message and in reaction add the active document filepath to the clipboard.

Gist with code to add to two SumatraPDF source files.
https://gist.github.com/nod5/51c906f89f6a04995f5ced920e4c909d
Tested on SumatraPDF source from 2020-01-15.

This clipboard method works quickly and reliably so far. The external program can be made to backup/restore the previous clipboard data before/after the extraction. But still, it would be better to avoid using clipboard I think.

2. wm_copydata method: Makes SumatraPDF receptive to a new message and in reaction pass the active document filepath via WM_COPYDATA

Gist with code to add to two SumatraPDF source files.
https://gist.github.com/nod5/086cd1ebbe7ed94520abae1c17646e2b
Tested on SumatraPDF source from 2020-01-15.

The wm_copydata code is not yet working! I successfully receive a message back to the external program and get correct dwData from it. Looks like cbData is correct too. But lpData turns out garbled/"asian characters". Can you spot errors in my code? (Can also be errors in my receiver code, I'll keep troubleshooting that too.)

[kjk]

&myTest is an address of std::wstring class, not the string inside the class. You probably need to change &myTest to myTest.c_str().

Better yet, start with the simplest thing:

WCHAR* myTest = L"test";
DWORD myTestCbLen = (str::Len(myTest) + 1) * sizeof(WCHAR);
COPYDATASTRUCT cds = {0x44646557 , myTestCbLen, myTest};

When that works, this change would probably be enough:

WCHAR* myTest = srcFileName;

(you don't need std::wstring because srcFileName is already of type WCHAR*)

[nod5]

Thank you. After editing (snippet below) it works now with 32bit SumatraPDF compiles at least. Will read up more on SendMessage/WM_COPYDATA and bitness next.

    // Works  if SumatraPDF is compiled as 32-bit.
    // Both 32-bit and 64-bit AutoHotkey unicode scripts can then read lpData ok.
    // Does not work fully if SumatraPDF is compiled as 64-bit.
    // Both 32-bit and 64-bit AutoHotkey scripts will then get garbled lpData string.

    // Note: Must use const for lpData here, else compiler error
    // Note: Must use (PVOID) to cast lpData to pvoid, else compiler error

    const WCHAR * lpData = srcFileName;
    DWORD cbData = (str::Len(lpData) + 1) * sizeof(WCHAR);
    COPYDATASTRUCT cds = {0x44646557, cbData, (PVOID)lpData};
    LRESULT res = SendMessage(callerHwnd, WM_COPYDATA, 0, (LPARAM)&cds);

Also updated in gist.

[Mark-Joy]

Hello @kjk, @nod5
I second this feature. While the code is fairly easy to implement, the benefit is quite good enough.
It will provide an easy + reliable way for other developers to implement some experimental features where offcial SumatraPDF may/may not provide in the future.
Anyway, users will have more freedom and greatly benefit from SumatraPDF + Plugins hence increase Quality of life (QoL) of SumatraPDF itself.

[GitHubRulesOK]

@Mark-Joy the general point of SumatraPDF is a runtime.exe importing some control data not lib.dll exporting internal data that is what is supplied commercially by MuPDF and this project is heavily abused by commercial applications (reputedly selling millions of copies without SumatraPDF badging). Although I still use multi way commands together, it is via the built in internal calling methods. So although no longer using pipes with LaTeX the DDE methods they depended on have been greatly expanded since the discussion above.

[nod5]

@GitHubRulesOK

the DDE methods they depended on have been greatly expanded

Yet there is no DDE command at
https://www.sumatrapdfreader.org/docs/DDE-Commands
that gives external tools access to the active document's filepath

Perhaps a current, fragile workaround is to set up a custom external viewer and give it a custom shortcut, based on
https://www.sumatrapdfreader.org/docs/Customize-external-viewers
Set as path to the external viewer an external helper script that then gets the filepath from SumatraPDF as parameter and can clipboard it or makes it accessible to other tools via SendMessage, or whatever.

But the overarching problem here is that @kjk seem decided on not adding features to help external tools interact with SumatraPDF in ways that add enhanced features. Such as my now defunct HighlightJump (enhanced annotations and navigation), custom toolbars, custom search of annotated text, and much more. It seems kjk prefers to implement any and all features on his own (and as a result many features are not implemented). As long as that is the case any time spent on external tools through this or that fragile workaround risk being wasted by breaking changes in any future SumatraPDF release.

To change that situation there would need to be ways to output more state data (filepath, X Y position, array of annotations and their type, page and position, ...) and input more actions (navigate to a particular annotation, hide/show annotations by type, ...) and an official statement that those output/input features will persist.

[GitHubRulesOK]

@nod5 agreed the list shows you can call ANY named commands. by supply filename, that is a viewers user functionality, the reason for SumatraPDF, however ASK current file is a totally opposing function that allows much ab-use

I very much use external viewers to SEND current file to downstream but do not expect upstream to ask, only feed/supply filename

your past workaround to read current file data was brilliant thinking

[Mark-Joy]

@GitHubRulesOK your point is correctly applied to user's viewpoint, but not to a developer who want to extend the use of sumatraPDF to give more benefit to other users.
But who care about our points anyway. He is the repo owner and decided to shut the door for developers.
The door was ajar when there was no official highlight function. It was fun using smx, I like it alots!

[GitHubRulesOK]

@Mark-Joy
Developers can purchas MuPDF for their own use SumatraPDF can be abused freely see many millions of Chinese commercial copies.

[Mark-Joy]

@GitHubRulesOK
I have no idea what you are talking about. Are they commercializing a free software, sumatraPDF?
Or perhaps, are you going commercial in the future?

[GitHubRulesOK]

@Mark-Joy
They wrap doctored SumatraPDF in a dll with their commercial enhancements thus fully abusing the fact that SumatraPDF is a free license open viewing UI wrapper around MuPDF

is this familiar ? all yours for $159 discounted to only $119

they enhanced SumatraPDF newer code abilities greatly but have not open sourced those enhancements

[Mark-Joy]

OMG, what software is this?
Is there anything we can do to stop them? Is this legal?

[GitHubRulesOK]

@Mark-Joy
Is this legal?
I dont know Chinese Laws
but there are many many others, past and present
however this the bees knees and even I would pay $119 for all those fantastic benefits this is just the core settings changes without all the other add ons that make it an Adobe Pro killer

Verdict: S...... PDF is a Windows program that comes with an extensive set of features aimed at PDF file organization and manipulation. I like that it has everything you need for basic PDF work – splitting and merging, editing, as well as cutting and pasting text, and so on.

One of the main benefits of this service is its advanced functionality, which allows hassle-free file editing and conversion in a few clicks.

Pros, Intuitive UI with tabs .Extensive PDF processing tools, Cheap, Over 100 million users, Microsoft partnership
Cons, Compatible with Windows only

>The product has gained popularity due to its ease of use, intuitive interface, and robust functions for working with PDF. What’s more, it saves you time on routine tasks, working quickly and efficiently regardless of the number of pages.

Their difference from competitors is that the company is an official partner of Microsoft, which additionally guarantees the reliability and confidentiality of the product. To learn more about all the features, benefits, and product prices, please read my S......PDF Software review to the end.

With it, you can close all issues related to PDF documents. At the same time, the program is light enough not to overload the computer and works quickly and without quality losses.

User-Friendly Windows Interface
I would like to note that the developers have designed the S...... PDF Software to be as simple as possible but at the same time trendy, discreet, and consistent with the style of Microsoft office products. At the top of the window, you will see various tabs that group functions, and at the bottom, a toolbar that will change as soon as you click on one or another tab. On the left, you will find a panel with quick access to frequently used options.

...

All of these advanced features help you protect your copyright and the integrity and invariance of your document. You can do this in several ways, such as uploading an image of your signature to put where you want, or signing with your mouse and typing your name. Anyway, it will be easy and won’t take you more than a couple of minutes with this fully featured product.

...

Another indisputable advantage of S....... PDF is its speed. Just a couple of minutes – and all the necessary corrections and manipulations with your document are ready. Combined with a clear UI, this speed of operation will give you a pleasant user experience.

The pro version comes with three paid subscriptions:

Monthly costs $8 for 1 PC.

Annual costs $41.4 for 2 PCs.

The Perpetual License costs $119 for 2 PCs, free updates, and lifetime customer support.

[Mark-Joy]

@GitHubRulesOK
But then, if they already stole the software without caring about the legal issue, they can just modify sumatra's source code, add some functionalites they wanted. See:
(Use sumatra core + their enhancements ) without disclosing their source code -> illegal
(Use sumatra source code + add their funcs + their enhancements ) without disclosing their source code -> illegal

I believe it's easy for them to do both of the above, right? Codewise, they already made enhancements far more complex than our some petty functionalities here.
So the only way for us is to make our free software better by combining strength from (sumatra core + developer plugins). So that people will not care about their software anymore, because ours is FREE.

[GitHubRulesOK]

hmm google sells sun java based code applications and oracle owned sun java but google won ? much the same with most software it's the bigger cracked pots pays the lawyers.

If you can workout how the altered code enhancements can be applied without direct copy then SumatraPDF could only improve but i think that revenue must be paying a lot of salaries.

[Mark-Joy]

@GitHubRulesOK
I think you misunderstanding me.
What I meant was SumatraPDF tried to prevent stealing by discarding some useful functions for developers.
But stealers are stealers, they can easily add those functions back by directly modifying sumatra's source code. Hence your solution at first seems to be effective but actually useless at the end.
Sorry to see a good free software being stolen, but I think your viewpoint is not so convincing.
So if SumatraPDF wants to shut the door for developers, just admit that "Well, I just wanted to do so! That's it!"

[GitHubRulesOK]

@Mark-Joy
I am not the 0.1 fulltime developer there is only one sole part time developer, as collaborator I am just a lurcher

[GitHubRulesOK]

@kjk can this topic be closed as a result of DDE enhancements in 3.5 ?

[nod5]

@GitHubRulesOK from what I can see at
https://www.sumatrapdfreader.org/docs/Version-history
https://www.sumatrapdfreader.org/docs/DDE-Commands
https://www.sumatrapdfreader.org/docs/Commands
SumatraPDF still lacks a way to get filepath to the active document in a particular SumatraPDF window.
If correct then this feature request is not fulfilled and v3.5 is no reason to close it.

[GitHubRulesOK]

@nod5
thanks for the review I have not used DDE in a long time and thus not able to test its functions / functionality