Fehler in der deutschen Hilfe bitte hier melden (Hilfedatei 3.3.14.5 2019.03.24)

  • Hi,

    falls ihr beim benutzen der deutschen Hilfe Rechtschreibfehler, Formatfehler und inhaltliche Fehler findet, wäre es nett dass ihr diesen dann auch hier meldet.

    Dann können wir diese korrigieren.

    Bitte nur Fehler der Hilfedatei 3.3.14.5 2019.03.24 melden

  • _GUICtrlListView_SimpleSort()

    So viele Fehler bei so wenig Text - das ist schon hohe Kunst! 8o

    So würde ich es übersetzen:

    Einmal editiert, zuletzt von Bitnugger (16. April 2019 um 21:11)

    • Offizieller Beitrag

    _WinAPI_RedrawWindow()

    Die Erklärung zu den $iFlags könnte m. E. etwas konkreter sein (mehr an den Inhalt von MSDN angelehnt), dann sind die Verwendungsmöglichkeiten etwas eindeutiger.

    Vor allem fehlen mir in der AutoIt-Hilfe (sowohl deutsch als auch englisch) die Gruppierungen der Flags und deren Beschreibung. Hier mal meine direkte Übersetzung aus MSDN. Evtl. ist es ja sinnvoll etwas zu übernehmen:

  • Kein Fehler im eigentlichen Sinn :

    Ich habe gerade auf eine Userfrage geantwortet. Bei der Schnelldurchsicht des Beispiels zur Hilfe von _FTP_FileGet ist mir folgendes aufgefallen :

    Code
    ...
    If _FTP_FileGet($l_FTPSession, $s_RemoteFile, $s_LocalFile) Then
        ShellExecute($s_LocalFile)
        ConsoleWrite("Download: erfolgreich" & @CRLF)
    Else
        ConsoleWrite("Download: fehlgeschlagen " & " " & @error & @CRLF)
    EndIf
    ...

    Der möglicherweise problematische Teil ist : ShellExecute($s_LocalFile)

    Im Beispiel wird eine Textdatei heruntergeladen und soll damit angezeigt werden.

    Bei ausführbaren Dateien (.exe, .cmd usw.) ist das meiner Ansicht nach aber gefährlich, oder interpretiere ich da etwas falsch ?

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Der möglicherweise problematische Teil ist : ShellExecute($s_LocalFile)

    Im Beispiel wird eine Textdatei heruntergeladen und soll damit angezeigt werden.

    Bei ausführbaren Dateien (.exe, .cmd usw.) ist das meiner Ansicht nach aber gefährlich, oder interpretiere ich da etwas falsch ?

    Es wird in der Hilfe nur eine README gezogen welche als .txt abgespeichert wird. Also wird im schlimmsten Fall, wenn eine Exe gezogen wird, sie im Editor geöffnet und ist unlesbar.

    Ich schätze das ShellExecute steht dort um zu zeigen, dass der Download erfolgreich war indem man sich die Datei anschauen kann.

    Wenn jemand nicht die Datei öffnen möchte, dann wird er das sicherlich von selbst entfernen.

  • Also wird im schlimmsten Fall, wenn eine Exe gezogen wird, sie im Editor geöffnet und ist unlesbar.

    Das stellt sich mir aber anders dar !

    Beispiel : ich habe eine Test.exe erzeugt (zeigt nur ein MsgBox)

    Code
    Local $sFilename = @ScriptDir & "\Test.exe"
    Local $iPID      = ShellExecute($sFilename)
    MsgBox(0, "", "PID: " & $iPID)

    Die Test.exe wird mit ShellExecute ausgeführt, nicht im Editor geöffnet !

    EDIT :

    Wenn jemand nicht die Datei öffnen möchte, dann wird er das sicherlich von selbst entfernen.

    So sollte es sein ;), aber die Beispiele der Hilfe werden von Einsteigern häufig als Vorlage genutzt, ohne groß darüber nachzudenken (speziell bei einem Thema wie FTP).

    Grundsätzlich hast Du aber recht - wer nicht weiß was er macht sollte die Finger davon lassen oder fragen :).

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

    2 Mal editiert, zuletzt von Musashi (5. Juni 2019 um 09:01)

  • Das stellt sich mir aber anders dar !

    Beispiel : ich habe eine Test.exe erzeugt (zeigt nur ein MsgBox)

    Die Text.exe wird mit ShellExecute ausgeführt, nicht im Editor geöffnet !

    Momomomomo-moment, du vermischt da was.

    Es wird in der Hilfe nur eine README gezogen welche als .txt abgespeichert wird. Also wird im schlimmsten Fall, wenn eine Exe gezogen wird, sie im Editor geöffnet und ist unlesbar.

    Sollte der in der Hilfe hinterlegte FTP-Server in irgendeiner weise korrumpiert sein ist das kein Problem, denn es wird als .txt abgespeichert.

    Das selbe würde mit einer Exe-Datei passieren, die würde dann als .txt gespeichert werden wenn man nicht explizit den Dateitypen ändert.

    Ich habe nur von dem Hilfebeispiel gesprochen, nicht wenn man das Hilfebeispiel anpasst. Da wird man (nehme ich mal an) in allen Fällen das Shellexecute entfernen wenn man das nicht ausführen möchte.

    So sollte es sein ;) , aber die Beispiele der Hilfe werden von Einsteigern häufig als Vorlage genutzt, ohne groß darüber nachzudenken (speziell bei einem Thema wie FTP).

    Grundsätzlich hast Du aber recht - wer nicht weiß was er macht sollte die Finger davon lassen oder fragen :) .

    Gut, stimmt auch wieder. Aber hier sollte man abwägen inwiefern das sinnvoll ist um nicht jede Funktion mit einer Warnung zu versehen wenn man mal nicht hinsieht.

    Das bläht ja die Hilfe nur auf und macht sie unlesbarer. Meiner Meinung nach wäre ein Kommentar über der _FTP_FileGet Zeile im Beispiel noch OK.

    Im Sinne von Downloade die Datei und führe sie bei erfolgreichem Download aus. (Öffnet in diesem Beispiel den Editor mit der heruntergeladenen README)

  • Sollte der in der Hilfe hinterlegte FTP-Server in irgendeiner weise korrumpiert sein ist das kein Problem, denn es wird als .txt abgespeichert. Das selbe würde mit einer Exe-Datei passieren, die würde dann als .txt gespeichert werden, wenn man nicht explizit den Dateitypen ändert.

    Ich habe nur von dem Hilfebeispiel gesprochen, nicht wenn man das Hilfebeispiel anpasst.

    Stimmt, im Kontext des Hilfebeispiels, und nur darum ging es Dir, hast Du natürlich völlig recht. Durch Local $s_LocalFile = @TempDir & "\tmp.txt" würde jede Datei (auch eine .exe) als tmp.txt gespeichert und mittels ShellExecute im Editor geöffnet werden.

    Ich hatte schon die Userfrage aus H&U im Kopf, wo eine .exe auch als .exe gespeichert wurde :whistling:.

    Gut, stimmt auch wieder. Aber hier sollte man abwägen inwiefern das sinnvoll ist um nicht jede Funktion mit einer Warnung zu versehen wenn man mal nicht hinsieht.

    Das wäre in der Tat unsinnig - dann würde die Hilfe nur noch aus Warnungen bestehen ^^.

    Ob der FTP-Download generell erfolgreich war, wird ja bereits über das Error-Flag ermittelt.

    Wie gesagt, werden sich User das Beispiel aber vermutlich auch als Vorlage nehmen, um ausführbare Dateien herunterzuladen und zu speichern. Da könnte die Brisanz von ShellExecute ggf. übersehen werden.

    Meiner Meinung nach wäre ein Kommentar über der _FTP_FileGet Zeile im Beispiel noch OK.

    Im Sinne von Downloade die Datei und führe sie bei erfolgreichem Download aus. (Öffnet in diesem Beispiel den Editor mit der heruntergeladenen README)

    Das wäre ein guter Kompromiss. Soll Tweaky entscheiden, ob er es einfügen möchte.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Hallo, folgendes hätte ich anzubieten. :)

    Beim Durchlesen der Hilfe zu "Func" ist mir folgendes aufgefallen:

    Nach dem Wort "Remarks" der dritte Abschnitt.

    EN: Declaring parameters as both ByRef and Const is useful when the large original variable must remain unchanged as AutoIt will return an error if the function attempts to alter it inadvertantly.

    DE: Das Deklarieren von Parametern als ByRef und Const ist nützlich, wenn die große ursprüngliche Variable unverändert bleiben muss, da AutoIt einen Fehler zurückgibt, wenn die Funktion versucht, sie versehentlich zu ändern.

    Die einfache Formulierung "ByRef und Const" ist nicht stark genug, um zu zeigen, dass damit eine Kombination gemeint ist. Der englische Begriff "both" ist darin nicht berücksichtigt. Meine Vorschläge wäre:

    Das Deklarieren von Parametern mit der Kombination von ByRef und Const ist nützlich,

    Das Deklarieren von Parametern mit beiden Schlüsselwörtern ByRef und Const zusammen ist nützlich,

    Beim Deklarieren von Parametern ist die Kombination von ByRef und Const nützlich,

    Das Deklarieren eines Parameters mit beidem (Const ByRef) ist nützlich,


    Desweiteren fände ich eine Umstellung der Wörter im Schlussbereich verständlicher. Mein Vorschlag:

    wenn die Funktion versehentlich versucht, sie zu ändern.  (siehe Nachtrag)

    wenn die Funktion unabsichtlich versucht, sie zu ändern.

    Oder "versehentlich" ganz weg lassen.

    wenn die Funktion versucht, sie zu ändern.

    [Sarkassmus] 

    Ehrlich gesagt, weiß ich nicht, wie eine Funktion etwas "versehentlich" versucht. Aber man lernt nie aus. 8o

    [/Sarkassmus]

    Nachtrag

    Bei meinen Recherchen hat sich folgendes gezeigt:

    In der englischen Hilfe ist vermutlich folgender Fehler:

    inadvertantly - Richtig wäre wohl:

    inadvertently

    Der Begriff lässt sich auch mit "unbeabsichtigt, unabsichtlich" übersetzen, was dann mehr Sinn ergibt. Habe es oben geändert.


    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

    Einmal editiert, zuletzt von Professor Bernd (27. Juni 2019 um 13:45)

  • Hallo.

    Kleinigkeiten in der Funktion FileRead, Abschnitt Rückgabewert

    EN: Success: the binary/string read. @extended is set to the number of bytes/characters returned.

    DE: Erfolg: Die eingelesenen Zeichen. @extended wird auf die zurückgegebenen Bytes/Zeichen gesetzt.

    Vorschlag: Erfolg: Die eingelesenen Zeichen. @extended wird auf die Anzahl der zurückgegebenen Bytes/Zeichen gesetzt.

    EN: @error: 1 = if file not opened in read mode or other error

    DE: @error: 1 = Die Datei wurde nicht im Lesemodus geöffnet.

    Vorschlag: @error: 1 = Die Datei wurde nicht im Lesemodus geöffnet, oder anderer Fehler.

    Gruß,

    Bernd.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Hi Tweaky !

    Auslöser für diesen Beitrag ist der Thread : dListview

    Beschreibung :

    Kernproblem ist, dass nicht (mehr) alle von SQLite benötigten Komponenten von AutoIt mitgeliefert werden. Stattdessen versucht die Funktion _SQLite_Startup() fehlende Komponenten nachzuladen, sofern sie nicht bereits auf dem eigenen Rechner vorhanden sind.

    siehe : Func __SQLite_Download_SQLite3File aus der SQLite.au3

    -> [..] Local $sURL = "http://www.autoitscript.com/autoit3/files/beta/autoit/archive/sqlite/" [..]

    Dieser Link ist aber nicht mehr gültig -> The requested URL ... was not found on this server.

    Der korrekte Downloadlink wird nur in den Bemerkungen zur Funktion _SQLite_Startup() angegeben !

    Dies führt m.M.n. dazu, dass insbesondere Einsteiger beim Ausführen der diversen Hilfebeispiele vor unnötige Schwierigkeiten gestellt werden.

    In den Code-Beispielen zu den _SQLite* Funktionen gibt es zwei Varianten des Aufrufs von _SQLite_Startup() :

    Variante 1 : Aufruf von_SQLite_Startup() ohne @error-Handling :

    Code
    [..]
    _SQLite_Startup()
    ConsoleWrite("_SQLite_LibVersion=" & _SQLite_LibVersion() & @CRLF)
    [..]

    -> Das Ausführen des Beispiels schlägt fehl :

    ---> In SciTE (F5) : Konsolenausgabe (hier am Beispiel von _SQLite_QuerySingleRow)

    @@ Debug(257) : __SQLite_Download_SQLite3File : $URL = http://www.autoitscript.com/autoit3/files/…ite/sqlite3.dll  

    $sTempfile = C:\Users\XX\AppData\Local\Temp\~hdchbbb.dll  

    >Error: 13  

    _SQLite_LibVersion=0  

    "... [Pfad] ... ==> Subscript used on non-accessible variable.:  

    MsgBox($MB_SYSTEMMODAL, "2. Einstellung:", $aRow[0])  

    MsgBox($MB_SYSTEMMODAL, "2. Einstellung:", $aRow^ ERROR

    ---> Als .exe gestartet :



    Variante 2 : Aufruf von_SQLite_Startup() mit @error-Handling (etwas besser) :

    Code
    [..]
    _SQLite_Startup()
    If @error Then
        MsgBox($MB_SYSTEMMODAL, "SQLite Fehler", "SQLite.dll konnte nicht geladen werden!")
        Exit -1
    EndIf
    [..]

    -> Ausführen des Beispiels mit F5 oder als .exe terminiert mit der MsgBox :

    "SQLite.dll konnte nicht geladen werden!"

    (müsste korrekterweise eigentlich auch lauten : "sqlite3.dll konnte nicht geladen werden!" )

    Allgemein :

    Betroffen sind die _SQLite* Funktionen, die _SQLite_Startup() aufrufen d.h. quasi alle :

    Spoiler anzeigen

    _SQLite_Changes

    _SQLite_Close

    _SQLite_Display2DResult

    _SQLite_Encode

    _SQLite_ErrCode

    _SQLite_ErrMsg

    _SQLite_Escape

    _SQLite_Exec

    _SQLite_FastEncode

    _SQLite_FastEscape

    _SQLite_FetchData

    _SQLite_FetchNames

    _SQLite_GetTable

    _SQLite_GetTable2d

    _SQLite_LastInsertRowID

    _SQLite_LibVersion

    _SQLite_Open

    _SQLite_Query

    _SQLite_QueryFinalize

    _SQLite_QueryReset

    _SQLite_QuerySingleRow

    _SQLite_SafeMode

    _SQLite_SetTimeout

    _SQLite_Shutdown

    _SQLite_SQLiteExe

    _SQLite_Startup

    _SQLite_TotalChanges

    Mein Lösungsvorschlag :

    Die SQLite.au3 zu modifizieren ist, schon allein aus organisatorischen Gründen, keine Option.

    (zumindest den fehlerhaften Downloadlink könnten die Developer aber ggf. mal fixen)

    Sämtliche Codebeispiele mit einem @error-Handling auszustatten wäre aufwendig und würde dem Einsteiger auch nicht vollständig weiterhelfen.

    Einfacher und besser wäre es, die Bemerkung aus _SQLite_Startup() bei allen _SQLite* Funktionen einzubauen, also :

    "Die SQLite-Dateien können von https://www.autoitscript.com/autoit3/pkgmgr/sqlite heruntergeladen werden. Abgespeichert werden können diese in @ScriptDir, @SystemDir, @WindowsDir oder @WorkingDir."

    Ggf. könnte man in diesem Text auch noch genauer auf die o.a. Problematik eingehen.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • (zumindest den fehlerhaften Downloadlink könnten die Developer aber ggf. mal fixen)

    Stattdessen versucht die Funktion _SQLite_Startup() fehlende Komponenten nachzuladen, sofern sie nicht bereits auf dem eigenen Rechner vorhanden sind.

    Falsch, seit 3.3.14.3 wird die SQLite DLL nicht mehr automatisch heruntergeladen.

    https://www.autoitscript.com/autoit3/docs/history.htm

    Du geisterst ja noch auf der 3.3.14.0 herum und hast es vermutlich nicht mitbekommen ;)

    Zitat

    Der Downloadlink in der Hilfe sollte aber angepasst werden.

  • Falsch, seit 3.3.14.3 wird die SQLite DLL nicht mehr automatisch heruntergeladen.

    Da hast Du recht !

    I.d.R. schaue ich in die History, habe ich aber ausgerechnet dieses Mal nicht gemacht (typisch) :Face:.

    Der automatische Download wurde sogar schon bei der AutoIt 3.3.14.2 gefixt :

    "Changed: _SQLite_Startup() no longer automatically downloads DLL files. THIS IS A SCRIPT BREAKING CHANGE"  

    Für User mit AutoIt < 3.3.14.2 mag dieser Teil meines Beitrages zwar von Interesse sein, die Hilfe kann aber natürlich nur die jeweils aktuelle Version behandeln.

    Wichtiger war mir eigentlich folgender Punkt :

    Auch in der 3.3.15.0 ist es so, dass der Aufruf von _SQLite_Startup() in den diversen Codebeispielen :

    ohne @error-Handling :

    --> Subscript used on non-accessible variable.

    mit @error-Handling :

    --> die Meldung, dass sqlite3.dll nicht geladen werden konnte

    --> (in der deutschen Hilfe noch : 'sqlite.dll konnte nicht geladen werden')

    anzeigt.

    Der Hinweis, dass und wo man eine fehlende sqlite3.dll herunterladen kann steht nur in der Bemerkung zur Funktion _SQLite_Startup(). Den Vorschlag, diese Bemerkung auch in die Hilfe der anderen _SQLite* Funktionen einzubauen, halte ich daher immer noch für überdenkenswert.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."