Clean up computation of preprocessed_command passed to ShellExecuteExW

* In the URIS_ONLY case (which is intended to open documents etc.), set
preprocessed_command to the filesystem pathname the first time that is
computed (and which will no longer fail for file URLs with fragment since
14b36a16b225bf7c988f118d499a7287c47cd83e "Remove a fragment from a file URL
early on").

* In the !URIS_ONLY case (which is intended to run other programs), we will
generally be called with aCommand already being a filesystem pathname.  But
even if it should be a file URL, it appears to be OK to pass that as-is to
ShellExecuteExW:  At least on Windows 8, passing
"file:///C:/Windows/System32/notepad.exe" does start it.

* The code for <https://bz.apache.org/ooo/show_bug.cgi?id=4789> "Hyperlinks
doesnt works" should no longer be relevant:  In the URIS_ONLY case, any
fragment (called a "jump mark" in that code) has already been removed from the
incoming URL now.  In the !URIS_ONLY case, we should generally not be called
with a URL with a fragment, but even if we are, it should be OK to pass that
as-is to ShellExecuteExW and let it handle that (see above).

* Similarly, the code for
<https://bugs.documentfoundation.org/show_bug.cgi?id=54204> "Hyperlinks
between documents not works if link contains anchor at the end" is no longer
relevant for the same reason.

Change-Id: Ia6ec80a30f6d0603bccc87b9d6dd93ca6a84c370
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86975
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

0 files changed, 0 insertions, 0 deletions