@crlf umwandeln in echten Zeilenumbruch, in Analogie @tab etc.

Das eine ist AutoIt-Code der vom AutoIt-Interpreter ausgeführt wird, das andere ist ein String welcher AutoIt-Code enthält.
Für AutoIt ist es aber weiterhin nur eine Ansammlung von Zeichen - nicht mehr.
Du musst dem Interpreter sagen, dass es den String als AutoIt-Code ausführen soll:

$s_Au3String = '"Das ist ein Test." & @CRLF & @TAB & "Weiter geht es." & @CRLF'
ConsoleWrite(Execute($s_Au3String))

Ich würde davon abraten hier Execute zu verwenden. INI Dateien sind beliebig editierbar, dadurch kann man alles mögliche durch einfaches Editieren der INI Datei zur Ausführung bringen.
Die bessere Lösung wäre hier mit stringreplace() zu arbeiten.

$Zeile = IniRead ($ini_Datei, $ini_Section, $Schluessel, "")
$Zeile = stringreplace($Zeile,"@CRLF",@CRLF)
$Zeile = stringreplace($Zeile,"@TAB",@TAB)
; usw.

Misterspeed: Da machst du es dir aus Sicherheitsgründen meines Erachtens viel zu restriktiv...

Folgende Funktion macht das gleiche wie "Execute" lässt dabei aber nur Strings und AutoIt-Makros zu.

$s_Au3String = '"Das ist ein Test." & @CRLF & @TAB & "Weiter geht es." & @CRLF'
ConsoleWrite(_SaveExecute($s_Au3String))


Func _SaveExecute($sExecute)
	Local $aElements = StringSplit($sExecute, "&")
	Local $sSaveExecute = ""
	Local $fSave = False
	For $i = 1 To $aElements[0]
		$fSave = False
		$aElements[$i] = StringStripWS($aElements[$i], 3)
		If StringRegExp($aElements[$i], '^"', 0) Then $fSave = True	;Strings Version 1
		If StringRegExp($aElements[$i], "^'", 0) Then $fSave = True	;Strings Version 2
		If StringRegExp($aElements[$i], "^@", 0) Then $fSave = True	;AutoIt Makro
		If $fSave Then $sSaveExecute &= $aElements[$i] & "&"
	Next
	If StringRight($sSaveExecute, 1) = "&" Then $sSaveExecute = StringTrimRight($sSaveExecute, 1)
	Return Execute($sSaveExecute)
EndFunc

Natürlich ist die Funktion noch nicht zu 100% funktional (kleinere Probleme hat sie noch...), aber sie beseitigt schon mal die meisten Versuche, die man darauf loslässt.

Unsinn. Es ist einfach gefährlich Usercontent zur direkten Ausführung zu bringen. Sowas macht man einfach nicht, dann braucht man auch keine 20 Zeilen Code um den Usercontent halbwegs sicher zu filtern. Hier ging es lediglich darum bestimmte Steuerzeichen wie Tabulator oder Zeilenumbruch rückzuübersetzen, da es in ini Dateien Restriktionen diesbezüglich gibt.

misterspeed:

Betrachten wir deinen Code. Er funktioniert wie eine gut konfigurierte Firewall: Alles was durch darf, muss explizit erlaubt werden. Ergo: Immer wenn ein neues Makro erlaubt werden soll, welches ebenfalls ersetzt werden soll, muss man bei dir nicht nur wieder eine neue Zeile hinzufügen, sondern auch das ganze Programm neu kompilieren und wieder neu verteilen. Und - der größte Nachteil: Es ist ein Ansatz, der nur auf dieses eine Problem passt - und selbst da nur solange die Anforderungen sich um keinen Millimeter verändern. Die simple Lösung in allen Ehren, aber hier wird am falschen Ende gespart. Denn bei der Aufgabe wird in 95% der Fälle immer der Funktionsumfang erweitert aka "Ach, wenn mer scho ma dabei sin, ne...".

Meine Lösung unterstützt etwa 100 AutoIt-Makros bereits "von Haus aus". Ich finde dafür sind 11 Zeilen Code nicht zu viel (11+3 Zeilen Fragmentation = 14 Zeilen). Sie ist einfach deutlich flexibler und bietet die gleiche Scheinsicherheit wie dein Ansatz. Er erfordert schlicht deutlich weniger "Wartung" im Verlauf der Programmentwicklung. Daher rate ich zu der Methode, statt einer, die über alle Maßen restriktiv ist und dafür keinerlei Vorteile mitbringt außer dass sie äußerst kurzsichtig mal Arbeit gespart hat.

Für ausführlichere Erklärungen, warum mein Code in vielen Punkten zielführender ist, als deiner, obwohl beide die gleiche Aufgabe mit 100% der Punktzahl abschließen, kannst du dem Buch "Weniger schlecht Programmieren" entnehmen. Eine Empfehlung für alle die gerne Programmieren. Mal in Stichworten: Fragmentierung (möglicherweise wiederkehrende Programmteile in Funktionen auslagern), Sprache (immer Englisch... du merkst doch selbst, dass es auf deutsch nicht funktioniert, wenn du dir alleine "Schlüssel" anguckst), Universalität (deine Lösung passt auf genau EIN Problem. Bedeutet: Auch wenn du ähnliche Anforderungen hast, musst du komplett neu anfangen), Notation (auch in AutoIt hat sich die ungarische Notation durchgesetzt. Mit ihr gibt man unter anderem an, was man erwartet in der Variable zu speichern...), Formatierung (in deinem Falle: Nicht konsequent und zudem noch zutiefst unübersichtlich...), usw.

Damit du mich nicht falsch verstehst: Dein Code ist richtig und führt zur Lösung. Vermutlich sogar Sekundenbruchteile schneller als meiner. Er folgt schlicht keinem Standard der professionellen Programmentwicklung. Das muss nicht unbedingt schlecht sein, aber solltest du planen in dieser Richtung tätig zu werden, solltest du dich schnell an die Standards gewöhnen, da du es dir sonst nur unglaublich schwer machst. Zum Thema der Sprache merke ich nur eines an:

$zovut = "Iosif"  ;Как тебя зовут

Ich denke das sagt alles.

Zitat von Bioshade

warum mein Code in vielen Punkten zielführender ist, als deiner, obwohl beide die gleiche Aufgabe mit 100% der Punktzahl abschließen

Nicht ganz.
Bei misterspeed wird AutoIt-Codeausführung über Stringinputs komplett unterbunden - bei dir ist es weiterhin problemlos möglich.
Z.B.:

$s_Au3String = '"" + FileDelete(@ScriptDir)'

Macht zwar keinen Sinn hier Diskussionen anzufangen und hat auch nix mehr mit dem Thema zutun, aber da mir gerade langweillig ist zwei, drei Anmerkungen zu deinem Roman...

Ich habe die Variablenbezeichnungen 1:1 aus dem Beispiel des Threaderstellers übernommen. Ich kenne durchaus die ungarische Notation und dessen Sinn, wobei wir hier von Autoit reden und dank des lieben Variant Datentyps... naja lassen wir das... ich selbst nutze in meinen Scripten ebenfalls die ungarische Notation und in der Regel auch die englische Sprache. Sei also beruhigt.

Was du bei 4 Beispielcodezeilen an der Formatierung auszusetzen hast erschließt sich mir auch nicht, da gab es schlicht und einfach nichts zu formatieren.

Du brauchst mir auch nicht erzählen was Funktionen sind und wie man diese sinnvollerweise gestalten sollte. Ich bin ausgebildeter Informatiker, programmiere auch nicht erst seit gestern und habe jedemenge Fachwissen über Software Design, auch wenn ich mich beruflich entschieden habe Administrator statt Programmierer zu werden.

Ich kritisiere nicht deine Funktion, welche in der Tat sehr vieles abdeckt, sondern die Tatsache, dass du beliebigen veränderbaren Text als Autoit Code interpretierst (hoffentlich wirklich nur Strings und harmlose Makros) obwohl das hier in der konkreten Augabenstellung überhaupt nicht notwendig ist. Ohne dein Buch über "gutes" Programmieren gelesen zu haben (Korrektur es geht ja nur um "weniger schlechtes" Programmieren) kann ich mir beim besten Willen nicht vorstellen, dass dir jemand soetwas ernsthaft empfehlen würde wenn es nicht zwingend notwendig wäre oder aufgrund der Augabenstellung Sinn macht.

Nun zu deinen 11 Zeilen und 100 Makros:

Local $aReplacements[3][2] = [ ["@CRLF" , @CRLF] , ["@TAB" , @TAB] , ["@CommonFilesDir" , @CommonFilesDir] ] ; usw. kannst du gern auch mehrzeilig und mit Tabulatoren darstellen, damit es formatierungstechnisch etwas her macht und leichter erweiterbar ist


ConsoleWrite(SpecialCharReplace("...", $aReplacements))


Func SpecialCharReplace($sText, $aReplace)


  For $i = 0 to UBound($aReplace)-1
   $sText = stringReplace($sText,$aReplace[$i][0],$aReplace[$i][1]) ; ggf. noch (not)case sensitive unterscheiden... könnte man als weiteren Funktionsparamter implementieren
  Next


 Return $sText


EndFunc

Eine wunderschöne flexible Funktion um multiple Sonderzeichen aus Texten zu entfernen oder zu ersetzen, welche man auch hier im konkreten Beispiel anwenden/gebrauchen könnte.
Achja und kritisier mich jezt nicht für fehlendes Errorhandling oder die tausend anderen Dinge die man daran verbessern/erweitern könnte. Das hier dient lediglich als Beispiel und ist keine saubere ausprogrammierte Funktion. Darum geht es hier im Forum auch nicht, sondern um Hilfe zur Selbsthilfe.

@Aspirin: Ja, das ist momentan noch der anfällige Punkt - siehe oben. Beides erfüllt dennoch die hier gestellte Aufgabe zu 100%.

misterspeed: Deine Anmerkungen zum Buch ignoriere ich, weil du nicht weißt wovon es handelt. Deine zuletzt veröffentlichte Version zum Beispiel ist deutlich besser als die letzte.

Und nun: Diskussion Ende? Mir geht es darum diese Standards auch bei Hilfestellungen soweit möglich einzuhalten.

Zitat von Bioshade

Beides erfüllt dennoch die hier gestellte Aufgabe zu 100%.

Welche Aufgabe?
Die erste Aufgabe war Strings mit AutoIt-formatierten Zeilenumbrüchen in normale Strings zu wandeln.
Das kann deine Funktion als auch Execute.

Diese Aufgabe erweiterte misterspeed dahingehend, dass die erste erfüllt werden soll ohne von außen Codeausführungen zu ermöglichen.
Diese Aufgabe erfüllen weder die Execute-Variante noch deine Funktion.

Kurz: Welchen Mehrwert gegenüber Execute bietet deine Lösung?

Zitat von AutoMit

Wer auf (m)einem Rechner eine ini-Datei manipulieren kann, der kann noch ganz andere Dinge tun.

Es geht hier nicht nur um böswillige Manipulationen durch Dritte. Wenn du dich beim editieren der INI Datei vertippst führt das bei Nutzung von execute() zum Programmabsturz mit einer Fehlermeldung die du wenn ich mir deine anderen Themen ansehe mit Sicherheit nicht verstehen und zuordnen können wirst. Wer schonmal stundenlang nach einer Fehlerursache gesucht hat, weil ihm ein böser Tippfehler unterlaufen ist der in seltenen Fällen zum Programmabsturz führt wird verstehen wovon ich rede. Sowas passiert dir mit der von mir beschriebenen Lösung jedenfalls nicht.

Zitat von AutoMit

Dort ist nach dem bisherigen Verlauf echtes Profiwissen gefragt.

Wenn man Neuling ist sollte man etwas mehr zurückhaltend mit solchen Aussagen sein. Dir wurde in beiden verlinkten Themen von sehr erfahrenen Forenmitgliedern ausreichend Hilfestellung gegeben. Wenn du nicht bereit bis dich tiefergehend mit Autoit bzw. dem systematischen Vorgehen beim Programmieren und Erlernen einer Programmiersprache zu beschäftigen bist du hier schlichtweg falsch. Das klingt vielleicht hart aber es ist so. Du lernst absolut garnichts wenn man dir jede Kleinigkeit vorkaut und wirst uns auch in Zukunft weiterhin mit Fragen bombardieren wenn du nicht anfängst etwas mehr Eigeninitiative zu ergreifen.

Zitat von AutoMit

Bitte Leute - lasst uns unsere Energie in die Lösung von Fragen stecken. Bitte.

Jupp schlag ich dir auch vor. Wäre jedenfalls sinnvoller als eine Stunde über imaginäre Bananenprobleme zu schreiben...

[Blockierte Grafik: http://i.imgur.com/H644Cfy.jpg]