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 ()

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