sumatrapdfreader
Add DDE Requests for some basic info
https://learn.microsoft.com/en-us/windows/win32/dataxchg/wm-dde-request
Currently I have to use QPDF to get the number of pages and this requires using execute in lua which causes a console window to pop up briefly.
It would be very nice if we could use DDE to request some info from SumatraPDF such as the total number of pages, the open files(list of full paths), the currently open file, the current page, etc.
This likely would be relatively easy to implement and provide some way to communicate with SumatraPDF.
Is it possible to get someone to look into this? I'm not sure exactly how hard it is to implement but since SumatraPDF already handles receiving commands it would be nice if it could handle sending some info.
For example, to check if a PDF was actually loading I'm having to use winapi's FindWindow on SUMATRA_PDF_FRAME GetWindowText.
It would be much nicer if all this stuff was more unified behind a common protocol like DDE.
This has been asked several times long ago and thus unlikely to be easy to implement as not needed for driving SumatraPDF.
SumatraPDF is a DDE serving receiver it takes and uses DDE CONTROL for functions but is not a transmitter of such (it can CLI export filename, current page and in some cases selected text).
Thus a whole new "client" methodology would be needed to allow for "topic" and "item" export all aspects like current "view zoom" = "100%" etc. so not really a SMOP but a whole maintenance commitment.
Acrobat have a team of thousands and years of related code if you need to leverage PDF DDE export.
P.S. number of pages always looks like it should be "simple" as is in the window controls but actually for a PDF that "N+1"can sometimes not be "true value" of the containing document. I have examples where ask pages and GhostScript says = 1 but there are internally over 1000 nested viper pages. PDF is a beast of a format with many contradictions.
As far as pdf page counting, something is better than nothing. In my cases qpdf seems to always return the correct number for the pdfs I have. Since the whatever sumatrapdf decides what a page is it must have some count of them and snice I'm trying to control sumatrapdf in regards to what it displays it doesn't really matter about pathological cases.
As far as DDE, if it is such a pain then what about implemented basic WM_COPYDATA:
https://learn.microsoft.com/en-us/windows/win32/dataxchg/using-data-copy https://learn.microsoft.com/en-us/windows/win32/dataxchg/wm-copydata https://stackoverflow.com/questions/16307338/sending-a-custom-windows-message-custom-data-marshalling
As the example shows, the hardest part will simply be coming up with a specification for how to specify the information. You could design it simply so that a chunk of information is send for a basic pdf information such as filesize, file location, num pages, etc. Then another data type for sumatraPDF info such as view settings, etc.
You could then also extend it for commands rather than use DDE since DDE is depreciated. Again, most of the work is just coming up with a specification. That is, since the client will have to send a message to request the data in the first place you'll have to parse WM_ commands from a client so adding transferring DDE to it would just be a load of boilerplate... probably something an LLM could do 95% of the work.
I don't understand why exporting basic information would be difficult. It's just filling out a struct and passing that info to a client. That info surely is easily accessed by the app itself in some app state.
None of the info I'm talking about is anything that isn't already available to the user interacting with SumatraPDF through the GUI. I'm only asking that it be packaged up through a programmatical interface so that automation is more functional. Essentially one is flying blind without some feedback. Previously I have hacked up some "spying code" which isn't robust. This was back around 2.1-2.5 and I think it broke or was having some issues and I later learned DDE was available for a lot of what I was trying to do so I moved to a different solution. If I could get get the pdf pages programmatically then I could do away with QPDF entirely and it would simplify things a bit(less dependencies). E.g., a simple SendMessage request for # of pdf pages could be passed with another SendMessage that has them in a wparam.
AFAIK AHK can read the page readout CTRL as was shown by NOD5 in his old request for more info like cursor position https://github.com/sumatrapdfreader/sumatrapdf/issues/1411
you can see the fairly similar ref is also still open https://github.com/sumatrapdfreader/sumatrapdf/issues/483
That adds another dependency and doesn't simplify things since I have to use lua and so have to interface AHK with lua.
Most methods will be much similar to the one NOD5 found effective which is to command SumatraPDF to export to clipboard or the metafile and here is a modern windows 10/11 twist on that method https://github.com/GitHubRulesOK/MyNotes/blob/master/C%23/SumatraPDFgetMetadata.cmd you can run the cmd to write an exe that lua can run to read current interface content via clipboard and is written in simple text for make own adjustments