Why does ShellExecuteEx with verb "print" take LNK file settings of Adobe Reader into account?

New Here ,
May 11, 2022 May 11, 2022

Copy link to clipboard

Copied

Context

 

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

 

Hide windows

 

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.

 

RxIMq

 

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.

 

No changes in registry

 

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:

 

5plmZ

 

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'"

 

Why is that important?

 

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.

 

So, how does that work?

 

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!

TOPICS
General troubleshooting , How to , Print and prepress , Standards and accessibility

Views

183

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
May 12, 2022 May 12, 2022

Copy link to clipboard

Copied

LATEST

Adobe people have stated (years ago, now lost) that they disabled silent printing deliberately.  So what you are seeing may be a bug or oversight. 

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines