Beiträge von Schokolade

Hallo zusammen,

klar baut man mal MsgBoxes für Testzwecke ein, aber ich habe mir angewöhnt, die immer sofort wieder auszukommentieren oder zu löschen wenn sie ihren Zweck erfüllt haben. Habe in dem Skript, welches aktuell die sporadischen Hänger hat, auch nochmal geschaut - alle auskommentiert. Es müssen also wirklich irgendwelche Auotit Meldungen sein, vielleicht irgendwo ein Array nicht sauber definiert oder sowas... Ich baue jetzt mal den Code von Trancexx ein und werde es weiter beobachten.

Schöne Woche.

Hallo zusammen und nochmal vielen Dank für die zahlreichen Rückmeldungen Meinungen Ideen Lösungsansätze und Hinweise!!!! TOP!!

Zitat von water

Es gibt eine Lösung

Ich hatte vor ewigen Zeiten das selbe Problem (MsgBox wartet im Hintergrund auf ein "OK") und Trancexx hatte die Lösung.
Guckst Du hier: https://www.autoitscript.com/forum/topic/14…from-a-service/

Spannend. Ich verstehe zwar nicht jede Zeile in diesem Code, interpretiere das aber so, dass ich das ganze Konstrukt einfach vor meinen eigentlichen Quellcode setzen müsste und das kümmert sich dann darum, dass irgendwelche Fenster mit dem Titel "AutoIt Error" abgefangen werden?

Zitat von Kanashius

Ich würde sagen: Wissen ist macht .

Also füg am besten logging zu deinem Programm hinzu, sodass du herausfinden kannst, wo genau das Programm hängen bleibt, sodass du das beheben kannst.

Ein "Hilfsprogramm" zum beenden ist keine wirklich gute Lösung, sondern nur ein (meiner Meinung nach schlechter) Workaround, weil das eigentliche Problem komplett ignoriert wird.

Und ja, Fehlersuche+Behebung kann nervig sein, dafür wird man mit einem gut laufenden Programm belohnt

Zitat von Musashi

Sehe ich auch so.

AutoIt liefert bereits eine einfache Log-Funktion, siehe _FileWriteLog

Ihr habt beide Recht und eigentlich logge ich mit _FileWriteLog auch so ziemlich alles, was ich in den Skripten so tue, denn ich lege imme großen Wert auf umfangreiche, gut strukturierte Logfiles. Also ich schreibe eigentlich alle Return-Werte und Error Codes in die Logfiles zurück, aber sicherlich auch nicht alles... Darum handelte sich ja meine Ausgangsfrage, ob es möglich ist, pauschal Fehlermeldungen abzufangen (oder zu loggen)...

Zitat von Micha_he

das compilierte Script wird per Gruppenrichtlinie verteilt und beim Rechnerstart ausgeführt. Damit auch mit Admin- oder besser System-Recht, bzw. -Umgebung. Also werden MsgBox'en sowieso nicht auf dem User-Desktop angezeigt, welcher auch beim Rehnerstart noch gar nicht vorhanden ist, also auch dort nicht dargestellt werden könnte.

Ich empfehle in einem derartigen Fall, auf alle MsgBox-Zeilen im Script zu verzichten. Lassen sich ja schnell auskommentieren oder ausschließlich abhängig von einem Debug-Flag bei Script-Start einzublenden.

Auf MsgBoxes verzichte ich eigentlich immer und schreibe stattdessen in ein Log, wenn ich solche "Automatisierungstools" baue, denn die laufen ja als Local System und sind für den angemeldeten User unsichtbar.

Zitat von Peter S. Taler

Ja entweder so oder eben als allererste Zeile ein File write

und als letzte Zeile ein File delete schon hast Du es.. die Anpassung fällt also minimalistisch aus, und verändert dienen Code im Kern nicht.

LG

Peter

Aber man muss die exe neu kompilieren und überall ersetzen

Hallo und danke für eure Antworten, wenn sie auch etwas ernüchternd sind

Da ich auf Anhieb nichts anfangen kann mit

Zitat von Andy

wenn du COM verwendest

gehe ich mal davon aus dass ich keine verwende

Das mit dem Hilfsprogramm ist ein guter Tipp, danke dafür! Aber was, wenn das Hilfsprogramm dann ebenfalls an einer Stelle eine Fehlermeldung bringt und seinerseits in Endlosschleife hängt? Hilfsprogramm fürs Hilfsprogramm? Spaß bei Seite, das werde ich mir in der Tat mal anschauen, ob man einfach einen Dreizeiler baut. Dazu muss das eigentliche Programm ja nichtmal angepasst werden und eine Fehler.txt schreiben - es reicht ja, wenn das Hilfsprogramm das eigentliche Programm nach XX Sekunden abschießt, wenn das dann noch laufen sollte.

Danke euch.

Hallo zusammen.

Ich nutze diverse kleinere als exe Dateien kompilierte Autoit Skripte für Automatisierungen, z.B. um Dateien wie Word Vorlagen von einem Server ins Nutzerverzeichnis zu kopieren, um lokale User anzulegen, Verknüpfungen auf dem Desktop zu erstellen usw.... Die Dateien werden meist per Autostart beim Rechnerstart oder per Gruppenrichtlinie verteilt und automatisch im Hintergrund ausgeführt.

Das funktioniert in 99 von 100 Fällen auch tadellos. Aber ab und zu kommt es vor, dass eine Exe ewig im Taskmanager zu sehen ist, woraus ich mutmaße, dass sie irgendeine Fehlermeldung bringt, die man normalerweise wegklicken muss, bevor das Programm beendet wird. Aber da die Exe automatisch im Hintergrund ausgeeführt wird, wir die Meldung nicht angezeigt, kann vom User auch nicht weggeklickt geschweigedenn gelesen und analysiert werden.

Ist es irgendwie möglich, generell bei allen kleineren Skripten etwas einzubauen, dass Fehlermeldungen unterdrückt und das Programm stattdessen sofort beendet wird? Oder dass sämtliche angezeigte Fehlermeldungen nach einem kurzen Timeout verschwinden und das Programm dann geschlossen wird?

Danke für eure Tipps.

Ah, hübsch, das mit dem ? und dem : kannte ich noch gar nicht, so lernt man immer wieder was dazu

Ich tue mich aber auch erfahrungsgemäß deutlich leichter, wenn ich die Befehlszeilen kurz halte und nicht zu sehr verschachtele, gerade, wenn man nach einem Jahr noch mal den Quellcode anpassen muss oder so.

Zitat von autoBert

oder benötigst du deine Platzhalter im Textformat für andere Aufgaben?

Ich weiß jetzt nicht wie die Frage gemeint ist?

Falls jemand ein ähnliches Problem hat - Ich habe mit den Codierungsoptionen in FileOpen rumprobiert es hat mit ANSI geklappt:

Datei öffnen, Inhalt in Array lesen und Datei wieder schließen:

$vRTF = FileOpen($sZiel1 , 512) ;512 für ANSI nur zum Lesen
$aRTF = FileReadToArray($vRTF)
FileClose($vRTF)

Dann für jede Array Zeile nach Schlüsselwort/Platzhalter suchen und ersetzen:

For $j = 0 To UBound($aRTF)-1
    If StringInStr($aRTF[$j] , "_GRUSSFORMEL_") > 0 Then
        $vStringReplaceReturn = StringReplace($aRTF[$j] , "_GRUSSFORMEL_" , $sGruss)
        $aRTF[$j] = $vStringReplaceReturn
    EndIf
    If StringInStr($aRTF[$j] , "_NAME_") > 0 Then
        $vStringReplaceReturn = StringReplace($aRTF[$j] , "_ZEILE_NAME_" , $sName)
        $aRTF[$j] = $vStringReplaceReturn
    EndIf
    ;usw...
Next

Dann die RTF wieder mit ANSI im OVERWERITE Modus öffnen und mit dem Inhalt des kompletten Arrays überschreiben und die RTF wieder schließen:

$vRTF = FileOpen($sZiel1 , 512 + 2) ;512 für ANSI + 2 für OVERWRITE
_FileWriteFromArray($vRTF , $aRTF)
FileClose($vRTF)

So werden die Umlaute, die an den entsprechenden Stellen eingefügt/ersetzt werden, richtig dargestellt.

Komisch ist nur, dass mit ...

FileGetEncoding($sZiel1)

... 256 als Rückgabewert kam, aber wenn ich 265 statt 512 verwende, klappt es nicht.

Na wie auch immer, für mich funktioniert das jedenfalls so.

Danke für eure Denkanstöße

Danke für eure schlauen Sprüche ähm Tipps Ich habe es jetzt ohne die _GUICtrlRich... Befehle hinbekommen

Danek aber auch das habe ich mir schon angeschaut und das beispiel in Scite kopiert und komme leider nicht weiter. Da werden ja bestimmte Positionen im Text markiert und ersetzt/gelöscht. Ich möchte aber Text ersetzen der an unterschieldichen Stellen vorkommt.

Danke für die Hinweise mit der Sortierung und dem Vergleich der Attributnamen in Spalte 0. Hilft mir aber leider in dem Fall nicht weiter, daher habe ich dann ja GetObjectAttribute für jedes einzelne Attribut verwendet.

Ein Beispiel:

User1:

givenname: Max

sn: Mustermann

title: Dipl.-Ing.

User2:

givenname: Sabine

sn: Musterfrau

title:

Mal davon ausgehend, dass jeder einen Vor- und Nachnamen hat, aber nicht jeder einen Titel...

If $Titel = "" Then
    $Gruss = "MfG " & $Vorname & " " & $Nachname
Else
    $Gruss = "MfG " & $Titel & " " & $Vorname & " " & $Nachname
EndIf

Danke für den Hinweis Bert.

Was genau meinst du mit Vorlage laden?

Und _GUICtrlRichEdit_ReplaceText hatte ich auch schon gefunden nur weiß nicht wie ich das nutzen soll, da gibts ja keine Parameter für "zu ersetzender Text" und "Ersatz Text"...

Hallo autoiter und water !

Danke für eure Antworten und Hinweise.

Das mit den Calltips hatte ich schon gefunden aber meine Frage war in der Tat, ob es mit F1 Taste geht, damit arbeite ich ziemlich viel. Habe mich jetzt aber schon dran gewöhnt, die HTMs manuell zu öffnen, geht ja auch Danek nochmals.

PS: water: Ich glaube es war der Befehl GetObjectProperties, der die Properties in eine Array schreibt? Da war mir aufgefallen, dass der nur Properties auflsitet, die einen Wert haben und die nach Alphabet sortiert. Da hätte ich gebraucht, dass auch leere Werte als "" ausgelesen werden und man auch vielleicht die Reihenfolge selbst festlegen kann bzw. das Array so gefüllt wird wie man die Properties als zweiten Parameter angegeben hat, also z.B.

_AD_GetObjectProperties($User , "personalTitle,givenName,sn,department,title,mail")

sodass man bei Mehrfachabfragen immer weiß, dass $Array[3][1] der Nachname ist.

Hätte ich das irgendwie einfach für mich abändern können? Also ist kein großes Problem, ich habe mich mittlerweile so beholfen, dass ich mit GetObjectAttribute gearbeitet und für jedes Attribut eine eigene Variable genommen habe, also z.B.

$sNachname			=	_AD_GetObjectAttribute($User , "sn")

$sVorname			=	_AD_GetObjectAttribute($User , "givenName")

Ist wie gesagt nicht dramatisch - ganz im Gegenteil: Vielen lieben Dank dafür, dass es dieses Include überhaupt gibt!!! Erleichtert so einiges!!

Hallo zusammen.

Ich habe hier eine TXT und eine RTF Datei als Vorlagen mit enthaltenen Schlüsselwörter wie z.B. _GRUSSFORMEL_ , _NAME_ , _TELEFON_ .

Weiterhin habe ich eine ini Datei

Gruss = Mit freundlichen Grüßen
Name = René Müstermän
Telefon = +49 40 / 123-45 · +49 171 / 23456

Nun kopiere ich die Vorlagen TXT und RTF, z.B nach @AppDataDir und lasse dort dann in den kopierten Dateien die o.g. Schlüsselwörter durch die Werte in der ini ersetzen, ungefähr so:

$sINI = @Scriptdir & "\Config.ini"

$sGruss = IniRead(  $sINI  , "Allgemein", "Gruss", "")
$sName = IniRead(  $sINI  , "Allgemein", "Name", "")
$sTel = IniRead(  $sINI  , "Allgemein", "Telefon", "")

$sQuelle1 = @Scriptdir & "\Briefvorlage.txt"
$sQuelle2 = @Scriptdir & "\Briefvorlage.rtf"

$sZiel1 = @AppDataDir & "\Briefvorlage.txt
$sZiel2 = @AppDataDir & "\Briefvorlage.rtf


FileCopy (  $sQuelle1  ,  $sZiel1  ,  9)
FileCopy (  $sQuelle2  ,  $sZiel2  ,  9)

;REPLACE IN TXT
_ReplaceStringInFile(  $sZiel1 , "_GRUSSFORMEL_" , $sGruss)
_ReplaceStringInFile(  $sZiel1 , "_NAME_" , $sName)
_ReplaceStringInFile(  $sZiel1 , "_TELEFON_" , $sTel)

;REPLACE IN RTF
_ReplaceStringInFile(  $sZiel2 , "_GRUSSFORMEL_" , $sGruss)
_ReplaceStringInFile(  $sZiel2 , "_NAME_" , $sName)
_ReplaceStringInFile(  $sZiel2 , "_TELEFON_" , $sTel)

Während in der TXT Datei zu ersetzten Werte, speziell die Umlaute, richtig dargestellt werden (u.a. in Notepad und Word), ist das bei der RTF Datei nicht der Fall. Öffnet man die RTF Datei mit einem Texteditor, stehen die Umlaute richtig drin (also das ß zb. als ß), aber wenn man die RTF in Word öffnet, erscheinen die Umlaute falsch, z.B. das ß als ß.

Das hat doch sicher irgendwas mit der Codierung im RTF Dokument zu tun? Ich habe auch schon rausgefunden, dass es diverse Befehle für _GUICtrlRichEdit..... gibt und mit denen rumprobiert, komme aber nicht weiter Daher meine Frage in die Runde: Was muss ich tun, um die Ersetzungen inder RTF so vorzunehmen, dass die Umlaute danach auch richtig angezeigt werden?

Ich bin für jeden Tipp dankbar und freue mich auf eure Ideen

Hallo, ich habe mir die AD.au3 runtergeladen und ins Include Verzeichnis kopiert. Da sind ja auch zu jeder Funktion htm Hilfen dabei - kriegt man die so integriert, dass man sie aus Scite heraus über die Hilfe Funktion mittels F1 Taste angezeigt bekommt?

Alles klar, danke. Gibts denn einen offiziellen Newsletter von/für Autoit, aus dem man sowas erfahren würde?

Hallo zusammen und danke für die zahlreichen Antworten und Hinweise!!!

Oscar : Vielen Dank aber das hast du jetzt ja nur so geändert, dass man es bei sich lokal anpassen kann, aber wenn man auf einem weiteren Rechner die aktuelle Autoit Version herunterlädt und installiert ist der vermeintliche Bug noch da, muss man also aufpassen.

Habe mir jetzt nicht den ganzen englischen Thread durchgelesen - hat jemand eine Vermutung wie das ausgehen wird? So lange bleibe ich dann doch erst mal bei der v3.3.14.2

Hallo zusammen.

Ich habe schon lange ein Autoit Skript laufen, welches CSV Dateien ausließt, umsortiert usw... Der Inhalt der Dateien und auch des Skriptes soll an dieser Stelle weitgehend egal sein, es geht lediglich um den Befehl _FileWriteToLine. Und zwar ist mir folgendes aufgefallen:

Mein Skript läuft schon länger und tut was es soll, u.a. immer die erste Zeile einer Textdatei (bzw. CSV) entfernen, und zwar mit folgendem Befehl:

_FileWriteToLine($sDateipfad , 1 , "" , True )

Das steht auch so inder Hilfe: If _FileWriteToLine() is called with $iOverWrite as 1 and $sText as "", it will delete the line.

Nun ist mir zufällig aufgefallen, dass die Folgeoperationen meines Skriptes nicht mehr richtig funktionieren und nach kurzer Suche bin ich drauf gestoßen: Die erste Zeile wird nicht mehr gelöscht. Nur warum?

Ich habe vor einiger Zeit mal den Entwicklungsrechner gewechselt und dort ohne groß nachzudenken Autoit heruntergeladen und installiert, und zwar die Version v3.3.14.5 . Nach dieser Installation habe ich das Skript noch mal kompiliert, um ein paar Kleinigkeiten anzupassen, die nichts mit dem o.g. Befehl zu tun haben.

Nun habe ich mir mal den Installer vom alten Rechner geholt und diesen durchlaufen lassen und siehe da, mit dieser Version, der v3.3.14.2 funktioniert das erneut kompilierte Skript wieder und die erste Zeile wird mit o.g. Befehl gelöscht.

Hat jemand eine Idee, warum das in der neuen Version nicht mehr klappt? Ist das vielleicht ein Bug?

---

Nachtrag: Ich sehe gerade, dass in der v3.3.14.5 für den Befehl _FileWriteToLine() der Parameter $bFill hinzugekommen ist, siehe Hilfe und siehe Changelog #3093.

Es ist aber egal, ob man diesen Parameter auf TRUE oder FALSE setzt, also

_FileWriteToLine($sDateipfad , 1 , "" , True , True)
oder
_FileWriteToLine($sDateipfad , 1 , "" , True , False)

Mit dem Befehl wird die Zeile nun nicht mehr gelöscht, sondern es bleibt eine leere Zeile stehen. In der Hilfe steht aber nach wie vor, dass die Zeile gelöscht wird, wenn abeim dritten Parameter "" und beim vierten TRUE angibt.

Hallo autoBert und vielen Dank!
Es klappt zwar mit der Datei aus dem Windows Notepad aber genau an so eine Lösung hatte ich gedacht, als ich auf das Problem gestoßen bin und den Thread hier verfasst habe.
Das werde ich bestimmt mit einbauen, dann ist man auf der sicheren Seite

Guten Morgen!
Ich wollte euch eben eine Beispiel Datei erstellen und dabei ist mir aufgefallen:

1. Wenn ich eine neue, leere Datei mit N++ erstelle und als .ini abspeichere, ließt AutoIt die Umlaute falsch ein.
2. Wenn ich für diese Datei in N++ dann unter Sprachen zwischen "MS-DOS-Stil" und "MS ini file" hin und her wechsle, die Umlaute wieder korrigiere, die beim Sprachenwechsel "zerschossen" werden, und die Datei wieder speichere, ließt AutoIt irgendwann die Umalute richtig ein. Nach welchem Schritt genau habe ich jetzt nicht ausprobiert, denn
3. Wenn ich eine neue, leere Datei mit dem Windows Notepad erstelle und sie als ini-Datei abspeichere, ließt AutoIt die Umlaute sauber ein. Danach kann ich die Datei mit N++ bearbeiten/ergänzen und AutoIt ließt weiterhin alle Umlaute sauber ein.

Also: Alles gut, Problem gelöst. Dann liegt das Problem wohl nicht an AutoIt, sondern an N++.

Anbei noch die beiden ini Dateien für diejenigen, die es interessiert - test8.ini ist mit Windows Notepad erstellt und funktioniert super, test9.ini mit N++ und funktioniert nicht.

Die ini Datei wurde mit Notepad++ erstellt und wird von einigen Leuten ergänzt (meist mit dem Windows Notepad). Ich habe schon probiert, in Notepad++ als Sprache MS-DOS-Stil einzustellen, bringt leider nichts.

Kann ich denn eine neue ini Datei an meinem Rechner im richtigen "Format" erstellen, die dann einfach von den Leuten mit Notepad.exe geöffnet und ergänzt wird?

Alternativ würde mir noch einfallen (analog zum Bsp. von Andy) ein kleines Zusatzprogramm mit GUI zu schreiben, in dem die Leute dann den Dateinamen mit Umlauten eintragen und das Zusatzprogramm das dann in die eigentliche ini schreibt.