Poste das doch bitte hier rein, dann können wir das besser sammeln: Sammelthread "AutoIt Interne Funktionen : Erwartetes Ergebnis -> Tatsächliches Ergebnis"
BugFix: Post hierhin verschoben.
Poste das doch bitte hier rein, dann können wir das besser sammeln: Sammelthread "AutoIt Interne Funktionen : Erwartetes Ergebnis -> Tatsächliches Ergebnis"
BugFix: Post hierhin verschoben.
#include <APIRegConstants.au3>
#include <WinAPIReg.au3>
#include <WinAPIShPath.au3>
; Beispiel aus der Hilfe zu 3.3.14.0 :
Local $sPath = _WinAPI_AssocQueryString('.txt', $ASSOCSTR_COMMAND)
ConsoleWrite('Command : ' & $sPath & @CRLF)
ConsoleWrite('Path : ' & _WinAPI_PathRemoveArgs($sPath) & @CRLF)
ConsoleWrite('Arguments: ' & _WinAPI_PathGetArgs($sPath) & @CRLF)
Hmm, bei mir ergibt das :
Command : "C:\Program Files (x86)\Notepad++\notepad++.exe" "%1"
Path : "C:\Program Files (x86)\Notepad++\notepad++.exe"
Arguments: "%1"
BugFix :
Zumindest bei .txt und in meiner Version (3.3.14.0) scheinen _WinAPI_PathRemoveArgs und _WinAPI_PathGetArgs nicht ausschließlich nach Leerzeichen zu splitten.
Gruß Musashi
Hmm, das Beispiel aus der Hilfe zur Version 3.3.14.0 ergibt bei mir :
Wenn der Pfad Leerzeichen enthält, muss er in Quote gesetzt werden, was bei deinem Bsp. ja auch der Fall ist.
Mit AutoIt 3.3.14.5 bekomme ich mit .profile folgendes Ergebnis:
$sCmd: C:\WINDOWS\system32\OpenWith.exe "%1"
$sPath: C:\WINDOWS\system32\OpenWith.exe
$sArgs: "%1"
Mit .au3 folgendes Ergebnis:
$sCmd: "C:\Program Files (x86)\AutoIt3\SciTE\SciTE.exe" "%1"
$sPath: "C:\Program Files (x86)\AutoIt3\SciTE\SciTE.exe"
$sArgs: "%1"
Local $sCmd = 'C:\Program Files\Intel\bin\iWrap.exe /CMD:7 %1'
ConsoleWrite('$sCmd: ' & $sCmd & @CRLF) ; RICHTIG --> C:\Program Files\Intel\bin\iWrap.exe /CMD:7 %1
$sCmd = _PathAddQuote($sCmd)
ConsoleWrite('$sCmd: ' & $sCmd & @CRLF) ; RICHTIG --> "C:\Program Files\Intel\bin\iWrap.exe" /CMD:7 %1
Local $sPath = _WinAPI_PathRemoveArgs($sCmd)
ConsoleWrite("$sPath: " & $sPath & @LF) ; RICHTIG --> "C:\Program Files\Intel\bin\iWrap.exe"
$sPath = _WinAPI_PathUnquoteSpaces($sPath)
ConsoleWrite("$sPath: " & $sPath & @LF) ; RICHTIG --> C:\Program Files\Intel\bin\iWrap.exe
Local $sArgs = _WinAPI_PathGetArgs($sCmd)
ConsoleWrite("$sArgs: " & $sArgs & @LF) ; RICHTIG --> /CMD:7 %1
Func _PathAddQuote($sPath)
Return StringLeft($sPath, 1) = '"' ? $sPath : StringRegExpReplace($sPath, '(?U)(.+\..+) (.+)', '"\1" \2')
EndFunc
Alles anzeigen
Ausgabe:
$sCmd: C:\Program Files\Intel\bin\iWrap.exe /CMD:7 %1
$sCmd: "C:\Program Files\Intel\bin\iWrap.exe" /CMD:7 %1
$sPath: "C:\Program Files\Intel\bin\iWrap.exe"
$sPath: C:\Program Files\Intel\bin\iWrap.exe
$sArgs: /CMD:7 %1
Das liegt vermutlich daran, dass deine Pfadargumente bereits in Gänsefüßchen gewrappt sind. Übergibst du sie ohne werden sie anders gesplittet.
$sCmd: "C:\Datei mit Leerzeichen.exe" Param1 Param2
$sPath: "C:\Datei mit Leerzeichen.exe"
$sArgs: Param1 Param2
$sCmd: C:\Datei mit Leerzeichen.exe Param1 Param2
$sPath: C:\Datei
$sArgs: mit Leerzeichen.exe Param1 Param2
Theoretisch ist das kein Bug, da der Pfad ja abgeschlossen sein muss. Wenn man Leerzeichen haben will muss man eben Gänsefüßchen setzen, das ist seit DOS-Zeiten glaube ich so.
Woher soll die PathFunktion denn wissen ob es sich bei dem übergebenen String um einen Ordner/Datei oder Parameter handelt? Der kann doch nicht die Platte dafür scannen.
mMn. arbeitet die Funktion schon richtig, könnte aber ruhig ein Hinweis in der Hilfe vertragen.
Wenn der Pfad Leerzeichen enthält, muss er in Quote gesetzt werden, was bei deinem Bsp. ja auch der Fall ist.
Das liegt vermutlich daran, dass deine Pfadargumente bereits in Gänsefüßchen gewrappt sind. Übergibst du sie ohne werden sie anders gesplittet.
Vorab :
Dass Pfadangaben mit Leerzeichen in Anführungsstriche (quotes) gesetzt werden müssen ist sicher allen Beteiligten klar .
In BugFix Beispiel Link (und auch im Skript aus der Hilfe) wird der Pfad aber nicht manuell besetzt, sondern ist der Return Value von _WinAPI_AssocQueryString.
Von daher ist BugFix Aussage :
ZitatFalls ihr _WinAPI_Path.. Funktionen verwendet, bitte sehr misstrauisch sein. Die folgenden beiden Funktionen (Anm. von mir -> gemeint sind : _WinAPI_PathRemoveArgs und _WinAPI_PathGetArgs ) funktionieren definitiv nicht. Dort wird ausschließlich nach Leerzeichen im Pfad gesucht und anhand dessen in Pfad und Argumente gesplittet
ggf. etwas missverständlich.
Das Problem entsteht dadurch, dass _WinAPI_AssocQueryString , abhängig vom ersten Parameter ($sAssoc), die Anführungsstriche nicht generell setzt. Dass _WinAPI_PathRemoveArgs und _WinAPI_PathGetArgs falsch splitten, ist dann eher eine Folgeerscheinung (fehlende "").
Ich sehe es daher so wie Bitnugger und alpines, d.h. kein Bug im eigentlichen Sinne !
mMn. arbeiten die Funktionen schon richtig, könnten aber einen Hinweis in der Hilfe vertragen.
Ja !
Mal sehen, wie BugFix die Sache sieht.
Gruß Musashi
Theoretisch ist das kein Bug, da der Pfad ja abgeschlossen sein muss. Wenn man Leerzeichen haben will muss man eben Gänsefüßchen setzen
Und das ist das Problem bei Windows - man macht sich durch Inkonsistenzen unendlich viele Probleme. Wie sinnvoll ist denn die Abfrage des Command Strings, wenn die Registry (aus der die Werte gelesen werden) mal Einträge mit und mal ohne Gänsefüßchen hat?!
Das Problem liegt aber m.M. nach hauptsächlich in den Hilfebeispielen für _WinAPI_PathGetArgs und _WinAPI_PathRemoveArgs, die sich ihre Werte unglücklicherweise aus _WinAPI_AssocQueryString holen, die eben auch nicht verwertbare Werte ausgibt. Da wäre ein String mit Pfad sinnvoller.
Dann sollte auf jeden Fall das Hilfebeispiel angepasst werden, erstell doch dazu am besten ein Ticket im Bugtracker, kann nicht schaden.
Und das ist das Problem bei Windows - man macht sich durch Inkonsistenzen unendlich viele Probleme.
Das ist nicht nur ein Windows-Problem sondern generell wenn man versucht Code zu supporten der vor mehreren Jahrzenten geschrieben ist.
AutoIt hat sich dadurch ja auch verrannt und ich glaube, dass in einigen Versionen ein kompletter Rewrite erforderlich sein wird, den die Devs vermutlich so lange wie möglich aufschieben möchten.
AutoIt hat sich dadurch ja auch verrannt und ich glaube, dass in einigen Versionen ein kompletter Rewrite erforderlich sein wird, den die Devs vermutlich so lange wie möglich aufschieben möchten.
Hoffentlich werden wir das noch miterleben, dass AutoIt weiterentwickelt wird.
Und das ist das Problem bei Windows - man macht sich durch Inkonsistenzen unendlich viele Probleme. Wie sinnvoll ist denn die Abfrage des Command Strings, wenn die Registry (aus der die Werte gelesen werden) mal Einträge mit und mal ohne Gänsefüßchen hat?!
Selten dämlich seitens MS - würde ich auch sagen .
Möchtest Du Deinen Beitrag im Sammelthread noch etwas modifizieren ?
Die Aussage "_WinAPI_PathRemoveArgs und _WinAPI_PathGetArgs funktionieren definitiv nicht" stimmt so ja nicht.
Es müsste eher vor dem inkonsistenten Verhalten von _WinAPI_AssocQueryString gewarnt werden.
Die Umstellung der Hilfebeispiele zu _WinAPI_PathGetArgs und _WinAPI_PathRemoveArgs auf Pfade (ohne Verwendung von _WinAPI_AssocQueryString ) wäre absolut sinnvoll.
Gruß Musashi
Ich habe mal ein Ticket erstellt.
Es müsste eher vor dem inkonsistenten Verhalten von _WinAPI_AssocQueryString gewarnt werden.
_WinAPI_AssocQueryString liest lediglich den zu dem Query korrespondierenden Registry-Schlüssel aus. Der Fehler liegt ergo beim Ersteller (User/Coder) des Registry-Schlüssels.
Zitat von Bitnugger_WinAPI_AssocQueryString liest lediglich den zu dem Query korrespondierenden Registry-Schlüssel aus.
Über den Parameter der Funktion kann ich den Rückgabewert festlegen. Ich kann also statt der Kommandozeile, die Exe abfragen. Klappt aber in meinem Bsp. (mit .profile als systemeigenem Eintrag!) auch nicht. Hab noch nicht nachgeschaut, aber vllt. wird intern _WinAPI_PathRemoveArgs aufgerufen.
Hallo BugFix !
Nur als kleine Ergänzung :
Ich bin mal alle _WinAPI_Path* Funktionen der akt. Hilfe durchgegangen.
Neben den Beispielskripten zu _WinAPI_PathGetArgs und _WinAPI_PathRemoveArgs gibt es noch zwei weitere Funktionen, die _WinAPI_AssocQueryString verwenden :
1. _WinAPI_PathParseIconLocation ( $sFilePath) :
Parses a file location string that contains a file location and icon index
Local $sData = _WinAPI_AssocQueryString('.txt', $ASSOCSTR_DEFAULTICON)
2. _WinAPI_PathUnquoteSpaces ( $sFilePath) :
Removes quotes from the beginning and end of a path
Local $sPath = _WinAPI_AssocQueryString('.txt', $ASSOCSTR_COMMAND)
Ob das Problem mit den Anführungsstrichen auch hier relevant ist, könntest Du anhand von .profile mal ausprobieren.
_WinAPI_AssocQueryString liest lediglich den zu dem Query korrespondierenden Registry-Schlüssel aus. Der Fehler liegt ergo beim Ersteller (User/Coder) des Registry-Schlüssels.
Ich wollte der armen Funktion _WinAPI_AssocQueryString auch kein Unrecht antun .
Gruß Musashi