StringFormat mit anderer Syntax

  • Ich verwende ja sehr gerne StringFormat. Ist deutlich übersichtlicher als eine Stringverkettung mit den vielen Wechseln zwischen & und Variablen/Text. Auch der Einsatz von verschiedenen Stringbegrenzern ist deutlicher zu handeln. Was mich etwas störte ist, dass bei Angabe vieler Variablen nicht auf Anhieb sichtbar ist, welche Variable zu welchem Format-Platzhalter gehört.

    Deshalb habe ich mir eine andere Version der Funktion erstellt (_StringFormat), in der die zugehörige Variable direkt im Anschluss an den Format-Platzhalter innerhalb einer geschweiften Klammer angegeben wird.

    Wundert euch nicht über den Variablennamen, den ich in der Funktion für die Zählvariable der Schleife verwendet habe: Hier musste ich sicherstellen, dass dies keine Variable sein kann, die vom Funktions-Anwender genutzt werden könnte.




    EDIT [29.09.2018]

    Wie Musashi richtig bemerkt hat, habe ich völlig verpennt, dass der normale Textanteil ja auch geschweifte Klammern enthalten kann.

    Ich möchte ein Maskieren von Zeichen durch den Anwender möglichst vermeiden, weil dies dann vom Standardhandling der Funktion abweicht. Ich setz mich mal dran.


    EDIT 2 [29.09.2018]

    Ich habe mich jetzt dafür entschieden, dieses Problem analog zur Nutzung von Stringbegrenzern zu lösen: Man maskiert geschweifte Klammern einfach mit sich selbst. Also: {{interner String mit geschweiften Klammern}}


    EDIT 3 [30.09.2018]

    Richtiger Hinweis von Xori: Da im Text sowohl Backslash als auch Prozentzeichen bereits mit Backslash maskiert werden müssen, ist es sinnvoll diese Maskierung zu übernehmen.

    Somit: \{interner String mit geschweiften Klammern\}

  • Wozu die geschweiften Klammern dahinter, deine UDF soll doch extra hinter dem Formatzeichen den Inhalt bekommen also sind die doch überflüssig.

    Finde diese Syntax ehrlich gesagt ziemlich bescheiden aber wers mag.


    Für dein Beispiel würde ich aber aber nicht StringFormat nehmen sondern viel lieber ExpandVarStrings, ist kürzer und liest sich besser, naja Geschmackssache halt:

    @Mon, @MDay, @Hour, @Min, @Sec muss man übrigens nicht formatten, die sind alle zweistellig.

    Code
    1. Opt("ExpandVarStrings", 1)
    2. Global $sNameProcess = "Solitair.exe"
    3. Global $sResult = "[@MDAY@.@MON@.@YEAR@ @HOUR@:@MIN@:@SEC@] Der Prozeß ""$sNameProcess$"" wurde vom User '@UserName@@@@LogonDomain@' gestartet."
    4. ConsoleWrite($sResult & @CRLF)
  • Hallo BugFix !


    Sehe ich das falsch, oder filtert deine Funktion auch 'normalen' Text in geschweiften Klammern heraus ?

    Code
    1. ; Codefragment zum Einfügen :
    2. $sResult = 'Beispiel 1 : Hallo {normal text inside curly brackets} '
    3. ConsoleWrite($sResult & @CRLF)
    4. $sResult = StringFormat('Beispiel 2 : Hallo {normal text inside curly brackets} ')
    5. ConsoleWrite($sResult & @CRLF)
    6. $sResult = _StringFormat('Beispiel 3 : Hallo {normal text inside curly brackets} ')
    7. ConsoleWrite($sResult & @CRLF)

    Ausgabe :

    Beispiel 1 : Hallo {normal text inside curly brackets}

    Beispiel 2 : Hallo {normal text inside curly brackets}

    Beispiel 3 : Hallo


    Gruß Musashi

    86598-musashi-c64-png

    Einmal editiert, zuletzt von Musashi () aus folgendem Grund: Tippfehler

  • Wozu die geschweiften Klammern dahinter, deine UDF soll doch extra hinter dem Formatzeichen den Inhalt bekommen also sind die doch überflüssig.

    Und wie kann man ohne abgrenzende Zeichen feststellen, wo der Inhalt endet? Bsp.: "%02i" soll befüllt werden mit '$var +1' <-- solche Zuweisungen müssen möglich sein.

    Für dein Beispiel würde ich aber aber nicht StringFormat nehmen sondern viel lieber ExpandVarStrings, ist kürzer und liest sich besser

    Schreibe ich so undeutlich? - Mein Thread heißt doch "StringFormat mit anderer Syntax" und nicht: "Wie kann ich folgenden Bsp.-String ausgeben?"

    Mein Bsp. ist also kein Problem, das es zu lösen galt. Es ist nur ein willkürlich gewähltes Bsp. für eine Anwendung von StringFormat. Das wird vielleicht deutlicher, wenn du sowas umsetzen willst: StringFormat("[% 10s]\t%s", $s1, $s2).

    ExpandVarStrings ist nunmal wenig (oder besser gesagt gar nicht) geeignet um Strings zu formatieren. Weshalb du also Birnen in meine Schale mit Äpfeln wirfst und dann den besseren Geschmack von Birnen preist, entzieht sich meinem Verständnis.

    @Mon, @MDay, @Hour, @Min, @Sec muss man übrigens nicht formatten, die sind alle zweistellig

    Jein.

    Die Makros geben Strings der Länge 2 zurück (ggf. mit führender Null). Soweit hast du völlig recht.

    StringFormat legt aber fest, wie die Werte zu interpretieren sind. Ich bevorzuge schon, dass ich einen Ziffernwert (und das sind diese Makros inhaltlich) auch entsprechend formatiere. In diesem Fall also als %i. Damit würde aber ein Wert mit Vornull nur einstellig angezeigt werden. Somit ist die Anweisung %02i erforderlich. Man kann natürlich auch verlustfrei mit %s ausgeben, aber dann sind wir wieder bei der Nichtübereinstimmung von Inhalt und Format (auch wenn das in AutoIt leider keine Rolle spielt). Ist sicher eine Geschmackssache, die jeder auf seine Art handhabt.

    Sehe ich das falsch, oder filtert deine Funktion auch 'normalen' Text in geschweiften Klammern heraus ?

    Da hast du, zu meiner Schmach, leider völlig Recht. Kam mir im Moment, als ich das erstellt habe leider nicht in den Sinn, dass diese Klammern auch normaler Text sein können. :Face:

    Einfach weglassen kann man Einfassungszeichen nicht (s. mein Kommentar zu Zitat #1). Da muss ich jetzt mal nach einer eleganten Lösung suchen. Ich möchte ja nicht unbedingt, dass zusätzlich Zeichen maskiert werden müssen, weil das dann vom normalen Handling abweicht.

  • Kam mir im Moment, als ich das erstellt habe leider nicht in den Sinn, dass diese Klammern auch normaler Text sein können.

    Mir kommt (genau wie dir) überhaupt nicht in den Sinn, was geschweifte Klammern in einem mit Variableninhalten anzuzeigenden und zu formatierenden TEXT (!) zu tun hätten....

    Vor allen Dingen dann, wenn ich als Anwender der Funktion WEISS, dass diese Zeichen relevanter Funktionsbestandteil sind!

    Musashi , wo ist der Fehler im linken Bild?

    Hier käme NIEMAND auf die Idee, dass "100%ig" im Text "erlaubt", bzw. maskiert werden müsste. Oder doch? Dann schreibt mal ein Ticket an die DEV´s vom StringFormat()!


    Alternativ zu den geschweiften Klammern kann man ja eins der vielen vielen Steuerzeichen oder allgemein "ungenutzten" Sonderzeichen im ASCII-Zeichensatz verwenden. Aber wie gesagt...nur selbst fressen macht fett!


    Ich jedenfalls finde die Funktion klasse! Und falls mich irgendetwas daran stören sollte und/oder ich Ideen zu einer Verbesserung/Erweiterung habe, dann setze ich diese einfach um. Das mache ich mit vielen Codeschnipseln, die ich so aufschnappe. Die Fähigkeit, diese Schnipsel auf eigene Erfordernisse anzupassen scheint der Unterschied zwischen mir und den Horden von C&P-"Programmierern" zu sein.

    Mir würde nie einfallen, dem Funktions-Ersteller erzählen zu wollen, dass an seiner (für seine Ansprüche) funktionierenden Funktion etwas "falsch" wäre.

    Vor allem dann nicht, wenn die Funktion einwandfrei unter Beachtung der "Regeln" (hier: die geschweiften Klammern sind Funktionsimmanent) funktioniert.

  • Mir kommt (genau wie dir) überhaupt nicht in den Sinn, was geschweifte Klammern in einem mit Variableninhalten anzuzeigenden und zu formatierenden TEXT (!) zu tun hätten....

    Das kann bei einem JSON-String schon mal schnell nach hinten losgehen.


    Ich bin selbst kein Fan von StringFormat, da mir das Syntaxhighlighting beim Verketten viel hilfreicher erscheint.

    Klar, ich setz zwar ein bisschen mehr Zeichen um alles hinzubiegen aber mir wird farblich markiert was wo eingetragen wird.

  • Hallo Andy !

    Mir würde nie einfallen, dem Funktions-Ersteller erzählen zu wollen, dass an seiner (für seine Ansprüche) funktionierenden Funktion etwas "falsch" wäre.

    Was ist den daran verwerflich, wenn man ein Skript testet und den Ersteller auf mögliche Lücken hinweist ?

    Das ist, aus meiner Sicht, eine aktive und wünschenswerte Mitarbeit. Dass das beschriebene Verhalten bei geschweiften Klammern so nicht beabsichtigt war, hat BugFix ja bestätigt

    Es wurde von mir niemals der Wert der Funktion selbst angezweifelt, geschweige denn nach einer Lösung verlangt. Von daher kann ich das Statement '...nur selbst fressen macht fett !' , sollte es denn an mich gerichtet sein, nicht nachvollziehen.


    Nun, wie ich gerade sehe hat BugFix ja einen Fix gefunden ;)


    Gruß Musashi

  • BugFix schöne Sache, aber die geschweiften Klammern "klassisch" mit \{ und \} zu maskieren möchtest du nicht tun? Das wäre einheitlich und man spart sich eine seltsamere Syntax. Nicht zuletzt weil, alpines im Sinn, JSON Objekte auch solch komische Strukturen aufweisen könnten.

    Es gibt sehr viele Leute, die glauben. Aber aus Aberglauben.
    - Blaise Pascal