Ich rate daher einfach mal und schlage folgenden Aufbau vor:
Danke, du hast schon richtig erahnt wohin ich wollte. Ich hatte keine Vorstellung, wie ich die Codes platziere, da sie mehrfach auftreten können aber eigentlich ja als Key fungieren sollen.
Ich möchte die Fehlerkataloge verschiedener Geräte in eine JSON-Datei überführen und damit eine Software füttern, mit der auch unsere Innendienstmitarbeiter telefonisch eine erste Diagnostik vornehmen können.
Meine Idee ist, dass der User den Fehlercode eingibt, Geräte die diesen Code verwenden angezeigt bekommt und dann für die weiteren Informationen das korrekte Gerät auswählt (bzw. dies im Dialog mit dem Kunden tut - das für den Fall, dass gerade kein Zugriff auf die Kundendaten möglich ist - z.B. tel. Notdienst).
Hier mal zwei fiktive Codes, die aber z.T. unterschiedliche Bedeutung haben können (je nach Gerät):
Fehlercode: 108
Geräte: Device_A, Device_B, Device_C
Bezeichnung: ClockTimeError
Beschreibung: Fehler Echtzeituhr
Ursachen: Uhrzeit nicht gestellt, Batterie auf Mainboard leer, Mainboard defekt
Beseitigung: Uhrzeit stellen, Batterie auf Mainboard ersetzen, Mainboard ersetzen
Fehlercode: 108
Geräte: Device_D, Device_E
Bezeichnung: TemperatureError
Beschreibung: Fehler Temperatursensor
Ursachen: Sensor defekt oder nicht angeschlossen
Beseitigung: Sensor anschliessen oder ersetzen
Fehlercode: 333
Geräte: Device_A, Device_B, Device_C, Device_D, Device_E
Bezeichnung: LogBatteryError
Beschreibung: Fehler Log-Speicherbatterie
Ursachen: Spannung auf kritischen Wert gefallen
Beseitigung: Batterie ersetzenIn JSON würde ich das jetzt so anlegen:
{
"errorcode version": "0.0.1",
"error list": [
{
"code": 108 [
{
"device": ["Device_A", "Device_B", "Device_C"],
"name": "ClockTimeError",
"description": "Fehler Echtzeituhr",
"reason": ["Uhrzeit nicht gestellt", "Batterie auf Mainboard leer", "Mainboard defekt"],
"disposal": ["Uhrzeit stellen", "Batterie auf Mainboard ersetzen", "Mainboard ersetzen"]
},
{
"device": ["Device_D", "Device_E"],
"name": "TemperatureError",
"description": "Fehler Temperatursensor",
"reason": "Sensor defekt oder nicht angeschlossen",
"disposal": "Sensor anschliessen oder ersetzen"
}
],
"code": 333
{
"device": ["Device_A", "Device_B", "Device_C", "Device_D", "Device_E"],
"name": "LogBatteryError",
"description": "Fehler Log-Speicherbatterie",
"reason": "Spannung auf kritischen Wert gefallen",
"disposal": "Batterie ersetzen"
}
}
]
}Ist das in der Form korrekt?
Vom Ablauf her sieht das ja soweit OK aus (ich weiß nur nicht, warum die Sleep darin sind).
Ich würde es etwas anders gestalten:
$sCmd = "C:\Program Files (x86)\Sage\Sage 100\8.1\Shared\OLStart.exe /APP ABF /EXCL /DB ACCDE /VER 8.1"
$sClasshWnd = "[CLASS:OFormPopup]"
$sClassInstCtrl = "[CLASS:OFormSub; INSTANCE:2]"
; Run OLStart.exe
$PID = Run($sCmd )
$hWnd = WinWait($sClasshWnd)
WinActivate($hWnd)
If WinWaitActive($hWnd, 30) Then ; Timeout 30 s
; Wait for 30 seconds. <<< bezieht sich dein warten auf "WinWaitActive"? - s. TimeOut-Parameter
;~ Sleep(30000)
ControlSend($hWnd, "", $sClassInstCtrl, "{Enter}")
EndIfWegen der Remote-Verbindung beachte das Edit in Post #4.
Die Verwendung von Class/Instance ist auch immer der ID vorzuziehen, da diese bei vielen Programmen dynamisch generiert wird und dadurch bei jedem Programmstart differiert.
Laut Doku ist FileSetPos auch nur mit einem filehandle einsetzbar ?
Das ist korrekt.
Aber warum zum Teufel willst du die Datei UNBEDINGT zum Lesen UND Schreiben öffnen?!
Dazu besteht doch keine Notwendigkeit, so wie du das umsetzt.
Also
1. sRead = FileRead(Dateipfad)
2. sRead manipulieren
3. hwnd = FileOpen(Dateipfad, Overwrite)
4. FileWrite(hwnd , manipulierte sRead)
5. FileClose(hwnd)
Backslash, Asterisk, Fragezeichen, Größer, Kleiner sind alles "Magic Charakters" und deshalb im Pattern mit einem Backslash zu maskieren.
Da du nur einen Lese- und einen Schreibvorgang hast, spar dir FileOpen und verwende einfach den Dateipfad für Read/Write. Dann hast auch keine Probleme mit den Flags.
Edit:
Das dein Text gelöscht wird, liegt daran, dass du im gemeinsamen Read/Write anders vorgehen musst.
When reading and writing via the same file handle, the FileSetPos() function must be used to update the current file position.
wie kann ich denn den geänderten HTML Code wieder abspeichern, das kriege ich irgendwie nicht hin ?
In deinem Kommentar steht zwar: Öffnen zum Lesen und Schreiben - Aber du tust es nicht. Du musst schon das Flag setzen.
Daher ist es für die "normale" Word find & replace nicht erreichbar.
Das ist schon klar. Mit "Suchen & Ersetzen" meinte ich schon eine auf das VBA Objekt bezogene, zu implementierende Funktion, die das übernimmt.
Ich wollte nur klarmachen:
Wenn ich sowieso ersetze, dann doch lieber mit Variablen statt Fixwerten.
Den Aufwand zu betreiben, die teilweise sehr aufwendigen Vorlagen neu aufzusetzen kann ich derzeit nicht leisten.
Aber wo ist der Unterschied, ob du per Suchen & Ersetzen einfügst:
Suche "Meier" Ersetze "Müller"
oder
Suche "Meier" Ersetze "INIRead(Inipfad, Chef)" - mit entsprechender VBA Umsetzung
Danach hast du alle Vorlagen dynamisch aktualisiert.
Excel-Instanz offen bleibt oder nicht ?
Mit ProcessExists auf eine Excelinstanz prüfen. Das Blöde ist aber, dass sich unbegrenzt Excel-Instanzen öffnen lassen.
Aber zum Test: Öffne vor dem Ausführen deines Skripts den Taskmanager. Findest du dort eine/mehrere Excel-Instanzen: Abschießen.
Und nun starte dein Skript in der jetzt Excel-freien Umgebung. Wenn es dann noch nicht klappt: PC aus Fenster werfen. 
Zum Suchen & Ersetzen kann ich im Moment nichts sagen.
Aber ein Tipp: Verwende für sich evtl. ändernde Daten Variablen, die du z. B. aus einer INI oder Datenbank liest. Geht mit VBA ebenso einfach, wie in AutoIt.
Jedoch bekomme ich immer noch die Speichermeldungen,
EDIT: Ich vermute, das ist nicht die Speichermeldung, sondern die ScreenUpdate-Meldung ("..Datei wurde verändert, soll die Datei neu geladen werden" - oder so ähnlich). Das musst du natürlich auch abfangen, siehst du in meiner Close-Funktion. Obwohl das in der normalen _Excel_Open-Funktion, die du kpl. mit False für alle Parameter setzt, ja auch deaktiviert sein sollte. 
Ich verwende bei mir eine eigene Open und Close - Funktion, die jeweils Excel-Objekt erstellen und Workbook öffnen, sowie Workbook speichern und Objekt schließen in einem Rutsch erledigt. Da poppt keine Dialogbox auf.
Vielleicht kannst du es verwenden:
Func _ExcelBookOpen($_sFilePath, $_bVisible=1, $_bReadOnly=False)
Local $_oExcel = ObjCreate("Excel.Application")
If NOT IsObj($_oExcel) Then Return SetError(1, 0, 0)
If NOT FileExists($_sFilePath) Then Return SetError(2, 0, 0)
If $_bVisible > 1 Then $_bVisible = 1
If $_bVisible < 0 Then $_bVisible = 0
With $_oExcel
.Visible = $_bVisible
.WorkBooks.Open($_sFilePath, Default, $_bReadOnly)
.ActiveWorkbook.Sheets(1).Select()
EndWith
Return $_oExcel
EndFunc ;==>_ExcelBookOpen
Func _ExcelBookClose($_oExcel, $_bSave = 1, $_bAlerts = 0)
If NOT IsObj($_oExcel) Then Return SetError(1, 0, 0)
If $_bSave > 1 Then $_bSave = 1
If $_bSave < 0 Then $_bSave = 0
If $_bAlerts > 1 Then $_bAlerts = 1
If $_bAlerts < 0 Then $_bAlerts = 0
$_oExcel.Application.DisplayAlerts = $_bAlerts
$_oExcel.Application.ScreenUpdating = $_bAlerts
If $_bSave Then
$_oExcel.ActiveWorkBook.Save
EndIf
$_oExcel.Application.DisplayAlerts = True
$_oExcel.Application.ScreenUpdating = True
$_oExcel.Quit
Return 1
EndFunc ;==>_ExcelBookClosedann findest Du die Werte hier:
Alternativ kann man auch den VBA-Editor nutzen (Excel öffnen, <Alt+F11>) und dort im Objektkatalog (Symbol wie ein Karton) anzeigen lassen.
Ist aber sehr hypothetisch
Irgendwie musste ich ja meinen Kopf aus der Schlinge ziehen. 
Das ist aber schon durch Parameter 2 von _Excel_Open erledigt.
Grundsätzlich ja, aber wenn z.B. das Objekt mit _Attach von einem Excel im Hintergrund "gekapert" wird, kann das durchaus anders sein.
Aber du hast recht - ohne Skript.... 
Aber leider habe ich nichts gefunden, wie man das Speichern Fenster abschalten kann, das wird immer wieder angezeigt ?
Vor dem Aufruf von ..Save:
$oExcel.DisplayAlerts = False
Schau dir in der Hilfe die Excel UDF an, alle Funktionen, die mit _Excel... beginnen.
Aber als FileCopy-UDF wird das wohl sehr heftig werden, wenn es überhaupt irgendwie geht.
Ich überlege gerade, das mit wChart in Nim zu schreiben und auch dort den async Prozess zu nutzen. Zur Kommunikation mit SciTE hatte ich das schon genutzt (async).
wChart nutzt auch GDIplus, aber halt wesentlich performanter.
Aber das hat keine Eile, werde ich mal immer so nebenbei weiter verfolgen.
Auch, wenn Du die Aktualisierung nur z.B. jede Sekunde vornimmst?
Weniger als 0.1 s ist nicht sinnvoll, da dann zu wenig Werte generiert werden und kein an- u. absteigender Graph, sondern eine kurze wilde Zick- Zacklinie entsteht.
Ich mach mir mal Gedanken, wie ich das in einen externen Prozess/anderen Kern auslagern kann.
