ShellExecute: Fehler beim Öffnen einer PDF

mumpel

Hallo!

Ich lasse per ShellExecute eine PDF-Datei öffnen. Solange ich das Script in AutoIt laufen lasse funktioniert alles. Aber sobald ich das Script kompiliere und die EXE aufrufe wird die PDF-Datei nicht geöffnet. Adobe ist aber im Hintergrund geöffnet, aber dafür zwei Reader-Hintergrundprozesse. Dieses Problem scheint aber nur den Adobe-Reader zu betreffen. Lasse ich die PDF-Datei in Edge öffnen (Edge ist dabei als Standardprogramm zugeordnet) funktioniert es korrekt. In VBA funktioniert es mit ShellExecute dagegen. Lässt sich das Problem lösen? PDF-Datei soll mit dem Standard-PDF-Programm geöffnet werden. Danke!

Gruß, René

Windows 10 (1703, Build 15063.483)

olfibits

Poste doch bitte mal das Skript hier. Vielleicht t liegt es an Pfad- Angaben. Ach, dieses Handy...

mumpel

Am Pfad dürfte es nicht liegen.

So:

AutoIt

$sAnleitung = @ScriptDir & "\Anleitung\Deutsch.pdf"
ShellExecute($sAnleitung, "", @ScriptDir, "open")

Oder einfach:

AutoIt

$sAnleitung = @ScriptDir & "\Anleitung\Deutsch.pdf"
ShellExecute($sAnleitung)

Beides funktioniert kompiliert nicht.

**Musashi**

Hallo @mumpel !

Wie @olfibits bereits richtig angemerkt hat :
Poste bitte mal ein rudimentäres, aber lauffähiges Skript, welches den Fehler reproduzierbar erzeugt.

Gruß Musashi

mumpel

Ich habe den Code gepostet der den Fehler verursacht.

mumpel

Gerade mal schnell auf dem Surface (Windows 10 Insider Preview) getestet. Da läuft der Code. Es muss aber einen Grund geben weshalb es unter "Windows 10 Creator" nicht läuft?!

**Musashi**

@mumpel !

Test auf meinem Arbeitsrechner (OS = Win 7 Pro - 64-Bit) :
Hier verwende ich keinen AdobeReader, sondern Sumatra als Standardprogramm.
Ergebnis : Beide Varianten, sowohl aus AutoIt heraus und auch .exe funktionieren !

Test auf meinem alten Notebook (OS = Win XP Home) :
Hier ist ein alter AdobeReader drauf.
Ergebnis : .exe funktioniert !
Code :
$sAnleitung = @ScriptDir & "\Anleitung\Deutsch.pdf"
ShellExecute($sAnleitung, "", @ScriptDir, "open")

Gruß Musashi

Floops

Alternativ vielleicht so?

AutoIt

$sAnleitung = @ScriptDir & "\Anleitung\Deutsch.pdf"
Run(@ComSpec & ' /c ' & $sAnleitung, @ScriptDir, @SW_HIDE)

**autoiter**

@Floops
Das @SW_HIDE sollte er aber wohl weglassen, oder?

mumpel

Damit funktioniert es garnicht, weder in AutoIt noch kompiliert. Ich sehe nur dass da kurz ein kleines Fenster (das wird die Kommandokonsole, cmd, sein) aufgeht und gleich wieder verschwindet.

**BugFix**

Es gibt den Parameter "WorkingDir". Der ist bei solchen Problemen recht hilfreich. Dort setzt du das Programmverzeichnis deines Standard-PDF-Programms (kannst du aus der Registry auslesen) und dann sollte es auch klappen.

**AspirinJunkie**

Das lange rumeiern um das eigentliche Problem kommt davon dass du eben nicht alles postest was gefragt wurde.
Es wurde nach dem Code gefragt der dieses Verhalten hervorruft.
Mit sehr großer Wahrscheinlichkeit hast du den Leuten hier aber die Zeile "#RequireAdmin" vorenthalten.
Die ist aber wichtig!

Das Problem ist der geschützte Modus des Acrobat Reader.
Um das Problem zu lösen:

Im AR: "Bearbeiten"
"Voreinstellungen"
"Sicherheit (erweitert)"
Haken bei "Geschützten Modus beim Start aktivieren" raus machen.

mumpel

Zitat von AspirinJunkie

(...) Mit sehr großer Wahrscheinlichkeit hast du den Leuten hier aber die Zeile "#RequireAdmin" vorenthalten (...)

Hatte ich beim Test nicht drin. Es hat mit und ohne #RequireAdmin nicht funktioniert.

Zitat von AspirinJunkie

Das Problem ist der geschützte Modus des Acrobat Reader.

Danke! Und das soll einer wissen? Kann man den Status irgendwie auslesen, um dem Anwender eine alternative Anzeigemöglichkeit zu bieten? Ich könnte zwar darauf verzichten die Anleitung automatisch anzeigen zu lassen, aber dann liest sie wieder keiner und jeder beschwert sich nur.

**AspirinJunkie**

Zitat von mumpel

Hatte ich beim Test nicht drin. Es hat mit und ohne #RequireAdmin nicht funktioniert.

Äußerst unwahrscheinlich. Ohne Adminrechte sollte es keine Probleme geben.
Nur bei Vorliegen des Sonderfalles das vorher mit Adminrechten versucht wurde zu starten (die AcroRd32.exe also im Hintergrund läuft) und danach ohne Adminrechte gestartet wurde kommt es auch zu diesem Verhalten.
Existiert keine laufende AcroRd32.exe und wird das Skript ohne #RequireAdmin gestartet läuft es auch.

Zitat von mumpel

Kann man den Status irgendwie auslesen, um dem Anwender eine alternative Anzeigemöglichkeit zu bieten? Ich könnte zwar darauf verzichten die Anleitung automatisch anzeigen zu lassen, aber dann liest sie wieder keiner und jeder beschwert sich nur.

Anders gefragt: Warum braucht das Skript unbedingt Adminrechte?

Floops

Zitat von autoiter

@Floops
Das @SW_HIDE sollte er aber wohl weglassen, oder?

Das Macro hat (zumindest bei mir) keinerlei Einfluss auf den Adobe Reader, sondern nur auf das cmd-Fenster selbst.

Zitat von mumpel

Damit funktioniert es garnicht, weder in AutoIt noch kompiliert. Ich sehe nur dass da kurz ein kleines Fenster (das wird die Kommandokonsole, cmd, sein) aufgeht und gleich wieder verschwindet.

Schade, bei mir funktioniert es einwandfrei, benutze aber auch Windows 7.

mumpel

Zitat von AspirinJunkie

(...) Nur bei Vorliegen des Sonderfalles (...)

Dann lag gestern irgenwie dieser Sonderfall vor.

Zitat von AspirinJunkie

Anders gefragt: Warum braucht das Skript unbedingt Adminrechte?

Weil Excel mit Administratorrechten gestartet werden muss, denn nur dann hat Excel auch volle Zugriffsrechte auf die Registrierungsdatenbank. Ohne Admin-Rechte hat kein Programm vollen Zugriff, schon garnicht auf die Policies. Und wenn ein User keine Administratorrechte hat, das ist z.B. auf Intranet-Rechnern häufig der Fall (muss auch so sein), soll er das Tool erst garnicht starten dürfen.

mumpel

Kann man #RequireAdmin nicht killen, also auf "Nothing" setzen wenn es zur weiteren Scriptlaufzeit nicht mehr benötigt wird oder den weiteren Scriptablauf stört? Also anstatt es ganz zu Anfang zu setzen setz man #RequireAdmin nur zur Statusbfrage und nach der Statusabfrage "abschalten".

**AspirinJunkie**

Ok weil Excel Adminrechte braucht, braucht dein Skript auch welche.
Wenn du Excel nur darüber startest könnte man über Umwege auch dafür sorgen das lediglich Excel mit UAC-Prompt aufgerufen wird dein Skript jedoch ohne Admin-Rechte läuft.
Es gibt nämlich durchaus einen nachvollziehbaren Sinn hinter dem Verhalten vom Acrobat Reader:
In welcher Welt benötigt ein Dokumentenbetrachter Vollzugriff auf das System? - wofür?
Es bringt nichts könnte aber Schaden verursachen.

Am einfachsten wäre es daher für dich den umgekehrten Weg zu gehen.
Sprich: Dein Skript per #RequireAdmin aufrufen und den ShellExecute-Aufruf mit niedrigeren Rechten durchführen.
Sieht für deinen Fall dann z.B. so aus:

AutoIt

#RequireAdmin
$sAnleitung = @ScriptDir & "\Anleitung\Deutsch.pdf"
_ShellExecuteWithReducedPrivileges($sAnleitung)


; ===================================================================================================================
; Func _ShellExecuteWithReducedPrivileges($sPath,$sCmd='',$sFolder='',$sVerb='',$iShowFlag=@SW_SHOWNORMAL,$bWait=False)
;
; Function to ShellExecute() a program/command with reduced privileges.  This uses a COM method of finding
;	Windows explorer's SHELL object and using that to ShellExecute() a program/command so that the IL level of
;	Explorer is used. This is useful if there is a need to start a program/command with reduced privileges.
;	- A common problem this fixes is drag-and-drop not working, and misc functions (sendmessage, etc) not working.
;
; All of the following parameters work the same as for ShellExecute(), with $bWait being the exception.
;
; $sPath = Path to executable
; $sCmd = Command-line (optional)
; $sFolder = Folder to start in (optional)
; $sVerb = 'Verb' or operation to perform. Default of '' uses default in Registry, or 'open'.
; $iShowFlag = how the program should appear on startup. Default is @SW_SHOWNORMAL.
;	All the regular @SW_SHOW* macros should work here
; $bWait = This only applies if A.) The process is no running elevated or B.) This is a pre-Vista O/S
;	If either of those is true, AutoIt's built-in ShellExecute() is called.
;	Setting $bWait to True/non-zero will instead run ShellExecuteWait()
;
; Returns:
;	Success: If $bWait is True, and ShellExecuteWait() is called, the return is the exit code of the Process
;		used to open/run command. Otherwise, this returns 1
;	Failure: 0, with @error set:
;		@error = 1 = Error returned from AutoIt's built-in ShellExecute*() function
;		@error = 2 = Object creation failure for Shell object
;		@error = 3 = Object creation failure for InternetExplorer object
;		@error = 4 = Object creation failure for Explorer's Shell object
;
; Author: Ascend4nt, based on code by Brandon (of the 'BrandonLive' blog)
; ===================================================================================================================


Func _ShellExecuteWithReducedPrivileges($sPath,$sCmd='',$sFolder='',$sVerb='',$iShowFlag=@SW_SHOWNORMAL,$bWait=False)
	Local $oShell,$oWebBrowser,$oIShellDispatch


;	ShellExecute() normally if not in an elevated state, or if pre-Vista O/S.
	If Not IsAdmin() Or StringRegExp(@OSVersion,"_(XP|200(0|3))") Then
		Local $iRet
		If $bWait Then
			$iRet=ShellExecuteWait($sPath,$sCmd,$sFolder,$sVerb,$iShowFlag)
		Else
			$iRet=ShellExecute($sPath,$sCmd,$sFolder,$sVerb,$iShowFlag)
		EndIf
		Return SetError(@error,@extended,$iRet)
	EndIf


;	-- Vista/2008+ O/S. We're good to go! --


;	Shell Object (IShellDispatch5 on Vista+)
	$oShell=ObjCreate("Shell.Application")
	If Not IsObj($oShell) Then Return SetError(2,0,0)


;	IShellDispatch5->IShellWindows ('ShellWindows Collection') object->FindWindow
	; 	NULL, NULL, SWC_DESKTOP (0x08) [Vista+], Hwnd-Out (NULL), SWFO_NEEDDISPATCH (0x01)
	;  Returns IWebBrowser2 (InternetExplorer) object
	$oWebBrowser = $oShell.Windows.FindWindowSW(0,0,8,0,1)
	If Not IsObj($oWebBrowser) Then Return SetError(3,0,0)


;	IWebBrowser2->IShellFolderViewDual3 (ShellFolderView)->IShellDispatch5 (Explorer's Shell object)
	$oIShellDispatch= $oWebBrowser.Document.Application
	If Not IsObj($oIShellDispatch) Then Return SetError(4,0,0)


;	Call Shell->ShellExecute.  The return seems to always be a blank string, so nothing we can do about that
	$oIShellDispatch.ShellExecute($sPath,$sCmd,$sFolder,$sVerb,$iShowFlag)
	Return 1
EndFunc

Alles anzeigen

mumpel

Zitat von AspirinJunkie

(...) könnte aber Schaden verursachen. (...)

Das kann eine PDF-Datei auch auf eingeschränkten Konten....

Zitat von AspirinJunkie

(...) Sieht für deinen Fall dann z.B. so aus (...)

Danke! Funktioniert. Gibt es hier keine Danke-Schaltfläche?

**AspirinJunkie**

Zitat von mumpel

Das kann eine PDF-Datei auch auf eingeschränkten Konten....

Ja aber dort steht dem (deutlich geringeren) Gefahrenpotential ein Nutzen gegenüber (das Betrachten der PDF). Bei Adminrechten hingegen steht der deutlich vergrößerten Angriffsfläche kein nutzbarer Mehrwert entgegen.

Eine Begründung für den Aufruf als eingeschränkter User existiert daher während eine solche Begründung für den Aufruf mit Adminrechten nicht existiert.