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

  • Ich habe mir Dein Beispiel angesehen. Danke für Deine Zeit dafür.

    Kannst Du mir bitte kurz erläutern,

    • wo der konkrete Unterschied zwischen den beiden Versionen liegt?
    • wo der konkrete Unterschied zwischen BGR1/BGR2 und RGB1/RGB2 liegt? Der angezeigte Output ist ident.

    Beispiele in der Hilfe sollten jeweils sehr unterschiedliche Aspekte einer Funktion beleuchten.
    Derzeit habe ich den Eindruck, dass es nur marginale Unterschiede zwischen dem bestehenden und Deinem neuen Beispiel gibt.
    Oder sehe ich das falsch?

  • Kannst Du mir bitte kurz erläutern,

    wo der konkrete Unterschied zwischen den beiden Versionen liegt?

    Gerne. :) (OK, "kurz" hat nicht hingehauen, ist ein wenig länger geworden.) ;)

    • Für viele Profis ist die Hilfe überflüssig und dieses Beispiel ist aus der Sicht geschrieben, von jemandem der die Hilfe braucht und regelmäßig benutzt.
    • In der Hilfe geht es hier um die Funktion "_ChooseColor()". Im ersten (vorhandenen) Beispiel wird auf eine UDF mit mehreren Parametern verzweigt => das hat mir mehr Rätsel aufgegeben als geholfen.

    Offen gesagt, hatte ich am Anfang die Wahl, die Augen zu verschließen und bei der Anwendung zu hoffen, dass es auch klappt, wenn ich es nicht verstehe - oder mich ausgiebiger zu informieren. Das ist mir in der Hilfe nicht gelungen und ich musste Zeit im Internet aufwenden. Das war jedoch auch verwirrend, weil Microsoft schrieb: "The COLORREF value is used to specify an RGB color." Denn der 8-stellige Hex-Wert für COLORREF ist eher mit BGR verwand, als mit RGB.

    Wenn man Hilfe sucht, versucht man sich zu orientieren. Zum Beispiel hatte ich am Anfang Probleme zu verstehen, was die _ChooseColor Parameter "$iReturnType, $iColorRef und $iRefType" bedeuten. Die Erläuterung in der Parameter-Legende hat mir auch nicht viel Erleuchtung gebracht, z.B.: "Determines return type, valid values: 0 - COLORREF rgbcolor, 1 - BGR hex, 2 - RGB hex".

    RGB war mir bekannt und BGR war nachvollziehbar. Aber unter COLORREF konnte ich mir nichts vorstellen, die wenigen Infos die ich fand, waren verwirrend. Deshalb finde ich es noch mehr verwirrend, wenn eine UDF hinzukommt und beide Funktionen für ihre Parameter die gleichen magic numbers (0, 1 und 2) verwenden, die jedoch eine ganz andere Bedeutung haben.

    Der konkrete Unterschied zwischen den beiden Beispielen ist, dass meines hoffentlich für weniger Durcheinander sorgt.

    Ich habe das so gut erklärt, wie ich kann. Ich hoffe, es ist zu verstehen.

    wo der konkrete Unterschied zwischen BGR1/BGR2 und RGB1/RGB2 liegt? Der angezeigte Output ist ident.

    RGB2 gibt es nicht. Es gibt COLORREF_1/COLORREF_2 und BGR_1/BGR_2. Der konkrete Unterschied zwischen der jeweiligen Funktion 1 und 2 liegt in der Rückgabe, also $iReturnType.

    • In der jeweils ersten Version zeigt das Beispiel die Rückgabe in der gleichen Form wie in der Eingabe. Die Rückgabe kann direkt im Edit verwendet werden, muss aber gewandelt werden für das Setzen der GUI Hintergrundfarbe.
    • In der jeweils zweiten Version ist die Rückgabe RGB. Hier ist es dann umgekehrt: Die Rückgabe kann direkt zum Setzen der GUI Hintergrundfarbe verwendet werden, muss aber gewandelt werden für das Anzeigen im Edit.
    • "Der angezeigt Output ist identisch." - Die beiden vorgenannte Punkte zeigen, wie man auf unterschiedliche Weise ein identisches (gewünschtes) Ergebnis bekommt.

    Beispiele in der Hilfe sollten jeweils sehr unterschiedliche Aspekte einer Funktion beleuchten.

    Mein Beispiel zeigt vielleicht nicht sehr unterschiedliche Aspekte, aber unterschiedliche. Dabei habe ich einen Kompromiss gemacht, zwischen den unterschiedlichen Rückgaben und nicht zuvielen Funktionen. Man könnte leicht noch etliche Variationen einbauen, die aber dann doch wohl eher zu viel des Guten wären.

    Derzeit habe ich den Eindruck, dass es nur marginale Unterschiede zwischen dem bestehenden und Deinem neuen Beispiel gibt.
    Oder sehe ich das falsch?

    Ich denke, das siehst du richtig. Zu den marginalen Unterschieden zählen

    • Die minimalistische Erklärung bei der Deklaration der Variablen "$sCOLORREF, $sBGR, $sRGB". Damit User wie ich, die sich nicht so viel mit Farbräumen beschäftigen, eine kleine Grundinformation bekommen, habe ich die Hex-Formen aufgezeigt (laut MS-Docs) und die COLORREF Auswertung per high-order byte bis low-order byte.
    • Bei "COLORREF_1/COLORREF_2" habe ich als Farbvorwahl "rot" in der (hoffentlich) korrekten 8-stelligen Hex-Form für COLORREF benutzt.
    • Bei "BGR_1/BGR_2" habe ich ebenfalls als Farbvorwahl "rot" in der 6-stellige Hex-Form für BGR benutzt, um zu zeigen, dass COLORREF eher mit BGR "verwand" ist, als mit RGB.
    • Anstelle von magic numbers habe ich sprechende Enum Konstanten benutzt.

    Wie du siehst, habe ich mich mich um unterschiedliche Aspekte bemüht und dabei versucht, das Beispiel übersichtlich zu halten.

    Edit: Punkt "Enum statt magic numbers" hinzugefügt.

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

    Einmal editiert, zuletzt von Professor Bernd (19. April 2021 um 20:48)

  • Ich habe das Beispiel nun etwas einfacher gestaltet. Es gibt nur einen Button, der alle Werte (COLORREF, RGB, BGR) ausgibt.

    Den Code habe ich möglichst einfach gestaltet.

    Was hältst Du davon?

  • Heißt das, dass dir mein Beispiel nicht gefällt? Und dass es nicht als Beispiel 2 aufgenommen wird? ;(

    Zu deinem Beispiel: Das finde ich um einiges besser, als das vorhandene! :)

    Richtig super finde ich die Kurz-Info zu COLORREF, BGR und RGB am Anfang des Codes, vorallem den Link zur MS-Docs-Seite! :thumbup:Ebenfalls gut gefällt mir die _ShowChoice UDF. Sie ist einfacher gestaltet und kommt ohne den Param $Type aus, der für Verwirrung gesorgt hat.

    Verbesserungsvorschläge:

    • Vielleicht die magic numbers in _ChooseColor(2, 255, 0, $hGUI) durch sprechende Konstanten ersetzen und die Farbvorwahl als Hex.
    • $idMemo durch $idEdit ersetzen. Das ist aber eigentlich egal.
    • Formatierung von $sMessage überarbeiten, z.B.:
    Code
        $sMessage = "COLORREF color of your choice - hex: " & $sCOLORREF & ", dec: " & Dec(Hex($sCOLORREF, 8)) & @CRLF & _
            "BGR      color of your choice - hex: 0x" & $sBGR & ",   dec: " & Dec($sBGR) & @CRLF & _
            "RGB      color of your choice - hex: 0x" & $sRGB & ",   dec: " & Dec($sRGB) & @CRLF

    Was haltet ihr davon? Bist du noch bei uns, Tweaky ? 8o

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

  • Danke für Deine Verbesserungsvorschläge :)

    Habe ich wie folgt umgesetzt:

    • Für die magic numbers bestehen noch keine Konstanten - ich habe sie daher belassen, aber vor den Funktionsaufruf entsprechende Kommentare eingefügt
    • $idMemo habe ich durch $idEdit ersetzt
    • Die von Dir vorgeschlagene Formatierung habe ich übernommen
    • Zusätzlich habe ich noch einen Exit Button eingefügt
  • Für die magic numbers bestehen noch keine Konstanten - ich habe sie daher belassen, aber vor den Funktionsaufruf entsprechende Kommentare eingefügt

    Finde ich ok und die Kommentare klasse! :thumbup:Zuerst dachte ich, man könnte zur besseren Veranschaulichung eigene, sprechende Konstanten benutzen, wie $eCOLORREF. Aber dann dachte ich, vielleicht ist das zuviel des Guten und die (magischen) Zahlen bringen mehr Übersicht.

    Beim Programmieren habe ich einfach die Erfahrung gemacht, dass man im ersten Moment versucht ist zu denken: "Was solls? Ist doch alles klar!" Aber nach drei, vier Monaten ist einem nicht mehr so klar, was man damals gedacht hat. Dann freut man sich, wenn man Kommentare dazu geschrieben hat. (Und pssst! Nur unter uns: In meinem Pau3 Projekt, das mittlerweile für mich recht große Ausmaße angenommen hat und über mehrere Programmiersprachen geht, bin ich über Kommentare richtig oft froh!) :)

    Die von Dir vorgeschlagene Formatierung habe ich übernommen

    Die ist scheinbar zwischendurch wieder verloren gegangen. 8o

    Da im Edit eine Monospace-Font benutzt wird, sollte man das zum Formatieren ausnutzen und die Werte im Edit schön untereinander ausrichten. Im Code unten habe ich das wieder hergestellt. Ich würde mich freuen, wenn es dir gefällt.

    Die meisten anderen Änderungsvorschläge sind Formatierungen. Den Code habe ich mit reichlich Kommentaren versehen, so sollte es verständlich sein. Meine Frage zu Param 2 soll weder Kritik, noch Aufforderung zur Änderung sein, sie ist rein informativer Natur.

    Vielen Dank für deine Mühe! :thumbup:

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

  • Wie ist denn der Status? Ist das neue erste Beispiel soweit in Ordnung? Wird es übernommen? Wie sieht es mit meinem Vorschlag für ein zweites Beispiel aus, wird das übernommen? Und zum Schluß: Die Funktion _ColorGetCOLORREF nicht vergessen, siehe Posting #4.

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

  • Ich fasse meine Vorstellungen zum Beispiel-Skript wie folgt zusammen:

    • Beispiele in AutoIt sollen die Basis-Einsatzmöglichkeiten der entsprechenden Funktion darstellen. D.h. es werden nicht alle möglichen Varianten per Beispiel dargestellt, sondern nur die häufigst verwendeten.
    • Es wird daher für _ChooseColor nur ein Beispiel geben
    • Bei den Beispielen kommt es nicht auf die Schönheit (z.B. Formatierung der Ausgabe etc.) an sondern auf die Darstellung der Funktion. Daher genügt mMn eine einfache Ausgabe ohne zusätzlichen Code für die Formatierung. Das lenkt nur von der Hauptaufgabe - der Darstellung der Anwendung der Funktion - ab.
    • Das mit Parameter 2 schaue ich mir noch an.

    Diese Überlegungen werde ich in das Beispielskript einfliessen lassen.

    So viel zum aktuellen Stand. Kann noch nicht genau sagen, bis wann ich die Anpassungen umgesetzt habe - bin demnächst wieder voll eingeteilt.

  • Da es in diesem Thread um einen meinungsbildenden Prozess geht, nicht um elementare Fragen von "Richtig" oder "Falsch", hier meine 2 Cent :

    Ich halte das Beispiel von water aus Beitrag #25 für mehr als ausreichend. Seiner Begründung aus Beitrag #28 kann ich weitestgehend folgen. ( Tweaky : So würde ich es übernehmen)

    water

    Wie das hier abgelaufen ist, gefällt mir nicht und ich gönne meiner Hilfe zur DE Hilfe vorerst mal eine Pause. Tweaky und alle anderen : Tut mir leid.

    Das klingt sehr nach : "Wenn es nicht genau so gemacht wird wie ich es will, dann bin ich raus"

    Larmoyanz ist gemeinhin kein sonderlich geschätzter Wesenszug.

    Zuweilen kann die Suche nach Perfektion auch zum Feind "des Guten" werden. Es steht ja jedem frei, erweiterte Beispiele im Forum zu posten (siehe Bitnugger ).

    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."

  • Professor Bernd

    Ganz ehrlich, ich habe den Thread nur überflogen.

    Deshalb kann und werde ich nichts dazu schreiben welches Beispiel nun wie gut ist.

  • Hallo,

    ich weiß nicht ob das irgendwer schon gemeldet hat, aber zumindest die Hilfeseite Autoit - Sprachreferenz - Variablen ist komplett in englisch. Ist das Absicht?

  • ich weiß nicht ob das irgendwer schon gemeldet hat, aber zumindest die Hilfeseite Autoit - Sprachreferenz - Variablen ist komplett in englisch. Ist das Absicht?

    Du meinst wohl : https://autoit.de/onlinehilfe/on…g_variables.htm

    "Absicht" ist das nicht, es hat sich schlicht und ergreifend noch niemand gefunden, der diese Seite übersetzt.

    Falls Du also auf der Suche nach einer Aufgabe bist ... ;)

    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."

  • Tweaky :

    (kurzer Hinweis, damit sich am Ende nicht andere doppelte Arbeit machen)

    Die o.a. Sprachreferenz für Variablen im Tutorial ist, insbesondere für Einsteiger, doch recht wichtig.

    Ich habe bereits mit der Übersetzung begonnen (zu ca. 30 % fertig).

    Anmerkung zur Grammatik :

    Der Plural von Variable lautet gemäß DUDEN Variable, also : "Eine Variable, zwei Variable ...".

    Andere Quellen lassen auch Variablen zu. Ich habe mich für Variablen entschieden, da das umgangssprachlich gebräuchlicher sein dürfte.

    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."

    Einmal editiert, zuletzt von Musashi (14. Mai 2021 um 10:20)

  • Hi Tweaky

    Hier die Übersetzung der Sprachreferenz für Variablen als .htm-Datei !

    EDIT : neue Version, siehe Beitrag #41

    Anmerkungen :

    Soweit ich sehe, wird in anderen Texten die Anrede z.B. "Du solltest..." / "Sie sollten..." weitgehend vermieden. Ich habe daher auch überall das neutrale "Man sollte/könnte ... usw." verwendet.

    Bei ausgesuchten Begriffen wie z.B. Gültigkeitsbereich habe ich das englische Scope in Klammern hinzugefügt, da dieser Begriff auch häufig im Deutschen verwendet wird .

    @@SyntaxHighlighting@@ ... @@End@@ sind vermutlich Anweisungen zur Formatierung, die in meinem Browser aber nichts bewirken (analog zum englischen Original).

    Ich habe den Text korrekturgelesen, aber eine weitere Prüfung kann sicher nicht schaden (er ist doch recht umfangreich) ;).

    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."

    Einmal editiert, zuletzt von Musashi (14. Mai 2021 um 06:58) aus folgendem Grund: älteren Anhang gelöscht

  • Hallo Musashi,

    Deine Übersetzung sieht sehr gut aus :thumbup:

    Ein paar kleine Anmerkungen habe ich doch:

    Statt "Briefkasten" würde ich "Postfach" verwenden. In einen Briefkasten kann ich was reinwerfen aber nichts mehr herausnehmen.

    Wird (und weiterer Beispielcode)

    @@SyntaxHighlighting@@ Enum $eConst1 = 1, $eConst2, $eConst3 ; 1, 2, 3 Enum Step 2 $eIncr0, $eIncr2, $eIncr4 ; 0, 2, 4 Enum Step *2 $eMult1, $eMult2, $eMult4 ; 1, 2, 4 @@End@@

    dann später als mehrzeiliges Beispiel dargestellt?

    " ... diese Schlüssel können mit der Funktion TableKeys iteriert werden." Müsste das nicht MapKeys heissen? Die Funktion TableKeys finde ich nicht. Ist dann auch im engl. Original falsch.

    ; Some time later:

    $vUndefined = 0xB0AD1CEA ; Bei Bedarf einen geeigneten Wert zuweisen

    Hier könnte man den Kommentar noch übersetzen

    Das war's auch schon.

  • Du meinst wohl : https://autoit.de/onlinehilfe/on…g_variables.htm

    "Absicht" ist das nicht, es hat sich schlicht und ergreifend noch niemand gefunden, der diese Seite übersetzt.

    Falls Du also auf der Suche nach einer Aufgabe bist ... ;)

    Ich meinte eigentlich die Offlinehilfe, aber ich denke mal die hängen ja miteinander zusammen.

    Und das mit meinen Englischkenntnissen lassen wir mal lieber=O

    Das war auch keine Kritik, mir ist durchaus bewusst wieviel Mühe sich hier einige Leute machen, es war lediglich eine Feststellung.

  • Deine Übersetzung sieht sehr gut aus :thumbup:

    Danke, auch für das Korrekturlesen :).

    Statt "Briefkasten" würde ich "Postfach" verwenden. In einen Briefkasten kann ich was reinwerfen aber nichts mehr herausnehmen.

    Aus meinem "Briefkasten" kann ich Dinge (z.B. Post) wieder herausnehmen, sonst würde er ja irgendwann mal platzen ^^. Ich verstehe aber, was Du meinst - "Postfach" gefällt auch mir besser.

    Ob der in @@SyntaxHighlighting@@ ... @@End@@ eingefasste Beispielcode später als mehrzeiliges Beispiel dargestellt wird, kann ich nicht beurteilen (bei mir zumindest nicht). Das kann Tweaky aber bei Bedarf leicht ändern. In der englischen Version erscheinen die @@ Bereiche bei mir als normaler Text.

    Man kann diese Seite aufgrund der vielen Fremdlinks und Formatierungen eh nicht einfach per Deepl übersetzen, sonst wäre der Nacharbeitungsaufwand für Tweaky zu groß (daher auch .htm).

    Deepl war als Tipphilfe für die Mengentexte nützlich, trotzdem musste einiges von Hand optimiert werden.

    " ... diese Schlüssel können mit der Funktion TableKeys iteriert werden." Müsste das nicht MapKeys heißen? Die Funktion TableKeys finde ich nicht. Ist dann auch im engl. Original falsch.

    Stimmt, die Funktion TableKeys finde ich auch nicht und ja, so steht es auch im englischen Original.

    Der Link MapKeys liefert allerdings einen "404 Not Found" Fehler. Zum Thema Maps gibt es sowieso unterschiedliche Aussagen ob und falls ja, wie und wann es damit weitergeht.

    Egal, das soll Tweaky entscheiden ;). Ich werde MapKeys angeben, da es diese Funktion zumindest gibt (bzw. mal gab)

    ; Some time later:

    $vUndefined = 0xB0AD1CEA ; Bei Bedarf einen geeigneten Wert zuweisen

    Hier könnte man den Kommentar noch übersetzen

    Wird erledigt.

    Tweaky :

    Ich werde die o.a. Anregungen von water gleich einbauen und eine neue Version posten. Falls Du vorher vorbeischaust, bitte kurz warten.

    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."