ShellExecute liefert ERROR_ACCESS_DENIED

[HolgerX]

Hmm..

Da bei Delphi 7 PChar = PAnsiChar ist, kannst Du auch eigendlich konsequent immer PAnsiChar verwenden.
Jedoch dann am Besten auch ShellExecuteA und die Strings sollte dann fix AnsiString sein.

Alternativ konsequent PWideChar in Verbindung mit ShellExecuteW und WideString.

Dann ist es Type-Konform, egal welche Delphi Version.

[himitsu]

Eine nutzbare Funktion mit abgelaufenem Code neu zu verbreiten ist nicht wirklich ideal.
Am Ende kommt noch wer auf die Idee und baut es in ein neues Programm ein. :zwinker:


Wie gesagt, an der Stelle ist garkein IFDEF nötig.

ReadFile liefert OEM, also ANSI,
OemToChar will ANSI rein bekommen,
also braucht der Buffer immer nur ANSI zu sein und wird somit auch explizit als ANSI deklariert. (AnsiChar/PAnsiChar/AnsiString)



Da gibt es bei deinem Trainer schlimmere Problemstellen, wenn man mit Unicode kompilieren würde (ab Delphi 2009)
und Einiges (FixStr) ist in jeder Delphiversion potentiell gefährlich.

Hier

Delphi-Quellcode:

Function StatusText ( StatusID : myStatusIDs ) : pChar; stdcall;

klappt das mit dem Result, da es auf Konstanten zeigt, die bestehen bleiben.

Bei

Delphi-Quellcode:

Function FixStr ( Input : PChar ) : PChar; stdcall;

zeigt Result auf eine temporäre Variable, die beim Verlassen der Funktion freigegeben wird.
Wird der Speicher zwischenzeitlich mit irgendwas überschrieben, dann knallt es womöglich.
War die Variable der letzte genutzte Teil des Speicherblocks, dann wird der freigegeben und es knallt.
Mit etwas Glück passiert nichts und es wird anschließend auf den noch nicht freigegebenen/überschriebenen Speicherbereich zugegriffen.

Delphi-Quellcode:

MessageBox(Handle, PAnsiChar(...

: Wie schon gesagt, muß alles zusammenpassen.
String > PChar > MessageBox
AnsiString > PAnsiChar > MessageBoxA
WideString/UnicodeString > PWideChar > MessageBoxW

Mein Tipp wäre hier einfach immer nur mit String/AnsiString/WideString/... zu arbeiten, vorallem bezütlich String-Verarbeitung und Speichermanagement (speichern und weitergeben der Strings)
und nur bei übergabe an die WinAPI nach PChar zu casten.

[Fukiszo]

beim debuggen der shellexecute funktion ist mir folgendes aufgefallen,
wenn die datei die man mit shellexecute ausführen will,
die aber "locked" ist, wie zum beispiel "PageFile.sys"
dann gibt es leider auch den ERROR_ACCESS_DENIED.

[Luckie]

Das ist doch in Ordnung. Warum leider?

[Fukiszo]

mit leider mein ich die plumpe rückmeldung "Zugriff verweigert."
wenn du zum beispiel eine datei ausführen willst,
die physikalisch zwar vorhanden, im explorer auch angezeigt wird,
aber eine execution unmöglich ist mit obriger rückmeldung,
weisst du ja eigentlich immernoch nicht wieso weshalb warum.
stünde da ein ERROR_FILE_LOCKED zur verfügung,
hät man das schneller unter kontrolle.
ich hab zwar eine "IsFileInUse" funktion,
die fängt aber leider nicht solche locked files ab.
die sagt logischerweise, klar, file is in use, weil's ja locked ist und irgendein process XYZ der die datei offen hat.
ich such mal im DP ob es eine möglichkeit gibt den status zu prüfen (locked/unlocked)...