Reputation: 3728
I have a Windows app printing PDF files by forwarding the file paths to ShellExecuteEx
and the verb print
. Adobe Reader is installed and registered for that verb. Reader by default creates a LNK shortcut file in the start menu:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Adobe Acrobat DC.lnk
By default, reader shows a GUI window when printing a PDF. Some customer doesn't want that window and simply tried to "hide" it by changing the LNK file content using Windows Explorer properties to at least minimize the windows by default. That customer didn't know if that works or not, one simply tried.
To my surprise this worked, changing the minimize vs. non-minimize/default setting of the LNK file made the reader windows being visible or minimized.
I've searched the registry for changed settings regarding the print
verb, but couldn't find any. The new setting really seemed to be only stored within the LNK file:
The registry contained references to the actual EXE only, not the LNK file. Pretty much like expected, I've never came across any shell verb registration using LNK files at all.
"C:\Program Files\Adobe\Acrobat DC\Acrobat\Acrobat.exe" /p /h "%1"
Though, all invocations of the verb print
seemed to recognize that setting, either manually using the context menu of some PDF in Windows Explorer or executing things on the shell:
powershell -Command "Start-Process -Verb print '\\?\C:\[...].pdf'"
Adobe Reader provides the command line argument /h
to minimize itself as well, but using that doesn't fully hide a window at all. Instead, a window is shown for a second or so and afterwards minimized, e.g. like Adobe is doing that itself. OTOH, with the changed LNK file things are different: Either really now window is shown at all or only some artifacts like the window title or alike for less than a second.
It really seems that the difference is between Adobe doing something on it own after it has loaded and stuff vs. Windows itself creating the minimized window already.
Additionally, if possible at all I would like to avoid customers needing to change the LNK file themself. The problem with that change is that it's not tied to the print
verb only, but whenever Adobe Reader gets opened. And sometimes customers really need to have a look at PDFs themself instead of automatic printing only.
Is Windows itself using the setting of that LNK file or is this something implemented by Adobe Reader?
Using ProcMon, I couldn't find any hint about that Adobe Reader itself reads the LNK file. As well, I couldn't find this behaviour documented in the topics about shell verbs, ShellExecuteEx
etc. It's totally unexpected to me, as the LNK file is some arbitrary file in theory, which might not exist at all, can be named as one likes, even multiple of those could exist in theory starting different apps of some package or the same app with different arguments etc.
Thanks for any insights.
Upvotes: 0
Views: 193