ShellExecute liefert ERROR_ACCESS_DENIED

[Amateurprofi]

Mit den unten stehenden Prozeduren will ich einen Beitrag aus Wikipedia anzeigen bzw. in GoogleMaps eine bestimmte Position.
Das funktioniert nur dann problemlos, wenn der Internet Explorer geöffnet ist.
Ist der IE nicht geöffnet gibt ShellExecute als Returncode 5 (ERROR_ACCESS_DENIED) zurück.
Weiß jemand was der Grund für dieses Verhalten, und ob und wie man das beheben kann.

Delphi-Quellcode:

type
   TGeoPos=packed Record
      Latitude:Extended;
      Longitude:Extended;
   end;

PROCEDURE ShowGoogleMaps(GP:TGeoPos);
var S,S1,S2:String;
begin
   S1:=Trim(FloatToStrF(GP.Latitude,ffFixed,6,6));
   S2:=Trim(FloatToStrF(-GP.Longitude,ffFixed,6,6));
   S:='http://maps.google.de/maps?q='+S1+','+S2+'&z=12';
   ShellExecute(0,'open',PWideChar(S),nil,nil,SW_SHOWNORMAL);
end;

PROCEDURE ShowWikipedia(const Term:String);
var S:String;
begin
   S:='https://de.wikipedia.org/wiki/'+Term;
   ShellExecute(0,'open',PWideChar(S),nil,nil,SW_SHOWNORMAL);
end;

[Delphi.Narium]

Schau mal bitte hier: https://www.codeproject.com/Question...efault-browser

Das hieße: Statt SW_SHOWNORMAL bitte SW_SHOWDEFAULT nehmen.

Literatur dazu: https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx

[himitsu]

Zitat:

Ist der IE nicht geöffnet gibt ShellExecute als Returncode 5 (ERROR_ACCESS_DENIED) zurück.

Ich hoffe das hier ist nur ein Beispielcode und im Programm ist am Ende doch eine Fehlerbehandlung verbaut.


Extended: Diesen Typen sollte man besser nicht verwenden und ihn nur für interne Berechnungen benutzen.
Und ich glaub kaum, dass die Position auf der Erde im Mikrometerbereich wirklich notwendig ist. :roll:
Double (12 Nachkommastellen) oder gar Single (5 Nachkommastellen)

Aber das Wichtigste: Immer RICHTIGE Typen verwenden? :!:

String > PChar > ShellExecute
ODER
WideString/UnicodeString > PWideChar > ShellExecuteW

Gut, ist kein wirklicher Fehler, aber wozu ist Trim da?
Da gibt es doch keine Ausführungszeichen.
Und statt der 3 Variablen und 3 Codezeilen hätte ich eher ein Format verwendet. :angle:

[Amateurprofi]

Zitat:

Zitat von Delphi.Narium (Beitrag 1389532)

Schau mal bitte hier: https://www.codeproject.com/Question...efault-browser

Das hieße: Statt SW_SHOWNORMAL bitte SW_SHOWDEFAULT nehmen.

Literatur dazu: https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx

Vielen Dank!
Problem gelöst.

[Amateurprofi]

Zitat:

Zitat von himitsu (Beitrag 1389533)

Ich hoffe das hier ist nur ein Beispielcode und im Programm ist am Ende doch eine Fehlerbehandlung verbaut.

Da trügt deine Hoffnung. Ich merke in diesen Fällen auch ohne Fehlermeldung, wenn da etwas nicht funktioniert.

Zitat:

Zitat von himitsu (Beitrag 1389533)

Extended: Diesen Typen sollte man besser nicht verwenden und ihn nur für interne Berechnungen benutzen.

Das mag sein dass "man" diesen Typ nicht benutzen sollte - aber ICH benutze ihn bevorzugt.

Zitat:

Zitat von himitsu (Beitrag 1389533)

Und ich glaub kaum, dass die Position auf der Erde im Mikrometerbereich wirklich notwendig ist. :roll:
Double (12 Nachkommastellen) oder gar Single (5 Nachkommastellen)

Das ganze ist Bestandteil eines Programms das sich mit astronomischen Daten befasst und alle Daten als Extended führt, u.a. auch Koordinaten.

Zitat:

Zitat von himitsu (Beitrag 1389533)

Aber das Wichtigste: Immer RICHTIGE Typen verwenden? :!:
String > PChar > ShellExecute
ODER
WideString/UnicodeString > PWideChar > ShellExecuteW

Wenn ich bei ShellExecute(... den Cursor hinter die ( stelle und Ctrl-Space drücke, wird in der Parameterliste "Filename : PWideChar" gezeigt. Hat ja auch funktioniert. Habs aber jetzt mit PChar versucht - geht auch.

Zitat:

Zitat von himitsu (Beitrag 1389533)

Gut, ist kein wirklicher Fehler, aber wozu ist Trim da?
Da gibt es doch keine Ausführungszeichen.

Das Trim soll führende Blanks entfernen. Ich vermute, dass ich früher die Floats mit einer Funktion in Strings gewandelt habe, die u.U. führende Blanks lieferte - kann ich heute nicht mehr nachvollziehen.

Zitat:

Zitat von himitsu (Beitrag 1389533)

Und statt der 3 Variablen und 3 Codezeilen hätte ich eher ein Format verwendet. :angle:

Format ist mir zu kompliziert zu unübersichtlich zu ach alles mögliche. Hab ich nie benutzt und werde ich nie benutzen.

So, ich glaube ich bin auf alles eingegangen.
Nun erzähl mir mal, was das mit dem in #1 geschilderten Problem zu tun hatte?

[himitsu]

Ja, bei dir ist "aktuell" PChar ein Alias für PWideChar und leider zeigt das CodeInsight den internen Typen an. (beim Compilieren wurde der Alias ersetzt)
Wenn du dir die Deklaration von ShellExecute ansiehst, siehst du den richtigen Typen.

In Bezug auf die WinAPI ist das Muster aber meistens recht leicht zu merken.
String > PChar > ShellExecute
AnsiString > PAnsiChar > ShellExecuteA
WideString/UnicodeString > PWideChar > ShellExecuteW

PS: Solches "Hat ja auch funktioniert" führte bei der Umstellung von ANSI zu Unicode zu problemen, da es danach plötzlich nicht mehr funktionierte. Das Selbe betrifft auch 32 und 64 Bit.
Hätte aber oft funktioniert, wenn die Typen wirklich gepasst hätten. :zwinker:

Vorallem Komplikationen beim Upgrade und für die Wiederverwendbarkeit der Codes, ist es immer Ratsam auf die Typen zu achten.
Meistens nimmt man den Typen der Eingangsparameter und wählt darauf die Casts und Funktionen,
oder ausgehend von der Funktion wird der Typ des Eingangsparameters ausgewählt.

[EdAdvokat]

Hallo Klaus (Amateurprofi), wie ruft Du ShowGoogleMaps auf? Ich wollte das Ganze mal ausprobieren mit einem Button und einem edit-Feld auf einer Form.
Die Geoposition wollte ich in das edit-Feld eintragen (welches Format haben diese?) und dann wollte ich per Button diese Pos. in GoogleMaps suchen lassen.
Irgendwie scheitere ich bei der Übergabe von (GP:TGeopos). Ich selle mich wohl zu blöd dazu an.

[Zacherl]

Zitat:

Zitat von Amateurprofi (Beitrag 1389535)

Zitat:

Zitat von himitsu (Beitrag 1389533)

Extended: Diesen Typen sollte man besser nicht verwenden und ihn nur für interne Berechnungen benutzen.

Das mag sein dass "man" diesen Typ nicht benutzen sollte - aber ICH benutze ihn bevorzugt.

Achtung. Die X86-64 FPU hat keine Unterstützung mehr für 80-Bit Floats (Extended). Entweder wird unter 64-Bit also emuliert, was fürchterlich langsam sein wird, oder deine Werte werden einfach truncated.

[himitsu]

Die Such-Syntax lautet
https://www.google.de/maps?q=suchbegriff&z=15

Er missbraucht das, da man auch nach Koordinaten suchen kann, anstatt sie anzugeben (zu beachten sind die Dezimaltrennzeichen in englischem Format)
http://maps.google.de/maps?q=51.0535283,13.7238866&z=15

Die korrekten URLs lauten z.B. wie folgt (mit @ wird die Angabe für Position und Zoom definiert)
https://www.google.de/maps/@51.0535283,13.7238866,15z
https://www.google.de/maps/search/suchbegriff/@51.0535283,13.7238866,15z
https://www.google.de/maps/place/Zwinger/@51.0535283,13.7238866,15z

[Delphi.Narium]

Eine Google-Maps-Urls sieht so aus:

Code:

https://www.google.de/maps/@53.5437308,9.9867191,15z

Allgemein:

Code:

http://maps.google.com/maps/@<lat>,<long>,<zoomfaktor>z

Delphi-Quellcode:

   sUrl := Format('https://www.google.de/maps/@%s,%s,%sz', [editLatitude.Text, editLongitude.Text, editZoomfaktor.Text]); 
   ShellExecute(0,'open',PWideChar(sUrl),nil,nil,SW_SHOWDEFAULT);

Hierbei gilt: Der Dezimalseparator in den Editfeldern ist der Punkt.

Zuerst aus den Zeichenfolgen der Editfelder Extended zu machen, um die dann in ShowGoogleMaps wieder in Zeichenfolgen zu verwandeln, halte ich für übertrieben.