Beiträge von misterspeed

1. Wenn du die Anzahl der Arrayelemente nicht kennst ist es ziemlich riskant in einer Schleife einen Arrayindex anzusprechen der irgendwo "weiter vorne" liegt und evtl. garnicht existiert.

Beispiel: Dein Array hat 100 Elemente, du befindest dich beim iterieren gerade bei Element 99 und sprichst dann Element "99+4" an.
Resultat: Programmabsturz, da du einen ungültigen Arrayindex verwendest

2. In einer FOR...IN Schleife gibt es soweit ich weiß keine Zählervariable $i die du ansprechen oder zur Berechnung eines Folgeindexes nutzen könntest.

3. Verwende einfach eine FOR...TO Schleife und schau dir die Funktion ubound(...) in der Autoit Hilfe bzw. das Array Tutorial von Bugfix an.

Bin davon ausgegangen, dass du das eher in einem Firmenumfeld als Rollout Script oder zur Imageerstellung/Vorbereitung verwendest. Microsoft Updates oder Servicepacks zusammen mit eigener Software zu verteilen dürfte seitens Microsoft btw sowieso nicht gestattet sein. Was man aber machen kann ist die Updateroutine von Windows zu automatisieren und ggf. darüber gezielt einzelne Updates herunterzuladen und zu installieren. Würde ich aber auf Fremdsystemen grundsätzlich nicht machen.

1. Viellicht wurde das System nur noch nicht neugestartet?
2. Vielleicht hat Microsoft wie so oft Mist bei den Updates gebaut und vergessen die Build Nummer korrekt zu aktualisieren und dies durch ein weiteres Update nach dem eigentlichen Service Pack korrigiert.

Letzlich auch egal... sobald alle Updates bis Stand heute installiert wurden ist davon auszugehen, dass Service Pack 1 vorhanden ist und auch korrekt erkannt wird. Also einfach das System patchen bis es nichts mehr zu patchen gibt und erst danach die SW Installationen starten (sofern SP1 wirklich Vorraussetzung ist). Grundsätzlich würde ich mir aber einfach eine Installations ISO inkl. SP1 beschaffen, dann spart man sich zum einen jedemenge Zeit und zum anderen erübrigt sich deine Frage nach der SP1 Prüfung.

Seh ich genauso. Macht garkeinen Sinn die DB ständig in aktueller Fassung zu integrieren. Was willst du machen wenn du auch nur eine winzige Änderung am Programm vornehmen musst? Wie willst du dann an all die individuellen DB Änderungen deiner Nutzer kommen wenn du Ihnen die aktualisierte Programmversion zukommen lässt? Dein Programmupdate würde den Nutzercontent dann wohl einfach ignorieren/verwerfen müssen. Ausser du betreibst enormen Aufwand für die Updateroutine wie oben skizziert. Dabei wirst du je nach Virenscanner aber auf Probleme stossen.

Wenn du die eigentliche Standard DB die du mitlieferst nicht zugänglich machen willst bietet es sich noch an die Änderungen des Benutzers als SQL Statements in eine Log-Datei zu schreiben. So kannst du dann bei jedem Programmstart all die gemachten Änderungen des Benutzers erneut in deine Standard DB übernehmen. Performant ist das aber sicher auch nicht.

Auch sehe ich keinen Grund was dein Problem damit ist, wenn die vollständige DB nach Programmende im Verzeichnis verbleibt. Während der Laufzeit ist diese ohnehin vorhanden und könnte kopiert/manipuliert werden. Das ließe sich btw über eine in memory sqlite DB lösen anstatt mit einer vorkompilierten Datei DB per fileinstall zu arbeiten.

Zitat von Weisgarnix

Das "Fett" sieht anders aus und ein ganz kleines Bisschen passts von der Skalierung nicht

Nunja da fette Schrift allgemein eine Auswirkung auf das Schriftbild hat (Buchstaben benötigen mehr Pixel und werden dadurch breiter und evtl. höher) würde ich den DPI Korrekturfaktor eben auch auf den "Fett"-Grad anwenden. Kannst das ja mal testen. Achja und anstatt permanent diese DPI Funktion aufzurufen würde ich den Korrekturfaktor einfach nur einmal am Scriptanfang ermitteln, in einer Variable speichern und später dann zur Berechnung der jeweiligen Schriftgröße oder Schriftdicke nutzen.

Zitat von Muecke

Ich prüfe doch in Ziele 1 ob die Datei Existiert wenn nicht dann erstelle ich die Datei in Zeile 2 Wenn Sie doch Existiert dann öffne ich die Datei in Zeile 6.
Habe ich dann nicht schon geprüft ob ich alle Berechtigungen etc. habe? und auch ob ich mit der Datei arbeiten kann?

Nein du prüfst damit nicht ob du irgendwelche weitergehende Berechtigungen hast. Wenn dir fileexists() zurückgibt, dass die Datei existiert bestätigt das maximal, dass du "Listrechte" auf das Verzeichnis hast, sprich du darfst sehen wie die Dateien im Verzeichnis heißen. Das bedeutet noch lange nicht, dass du die Datei kopieren, lesen, beschreiben oder gar löschen darfst.

Auf Fehler zu Prüfen macht immer Sinn, daher solltest du diese Prüfung auch nicht entfernen. Was wird wohl passieren wenn du die Datei wie hier gezeigt nur mit Fehlercode öffnen kannst? Genau deine späteren Schreibversuche werden alle scheitern. Hast du also nicht geprüft ob du die Datei erfolgreich öffnen konntest, dann wird dein Programm einfach davon ausgehen alles ist so wie es sein soll. Irgendwann stürzt das Programm dann vielleicht ab oder macht nicht mehr das was du wolltest. Du hast aber dann keine Ahnung warum und wo der eigentliche Fehler anfing.

Also gewöhn dir garnicht erst an Fehlerbehandlungen aus Bequemlichkeit oder Unverständnis wegzulassen. Wenn da ein Fehler kommt, dann gibt es auch einen und den solltest du beheben.

Die Frage ist doch was du für deine eigentliche Aufgabe benötigst. Grundsätzlich bietet dir Autoit zahlreiche Möglichkeiten Dinge zu automatisieren.

- Du kannst Maus und Tastatureingaben emulieren
- Du kannst sichtbare und unsichtbare Fenster / Programme steuern (entweder direkt oder mit Maus/Tastatur Emulation)
- Du kannst aber Autoit auch wie andere Programmiersprachen nutzen und z.B. Textdateien direkt bearbeiten, eine eigene GUI und vollwertige Windows Software erstellen
- Du kannst alle Windowsfunktionen und Einstellungen automatisiert auslesen / ändern (z.B. über die Registry, WMI, DLL Calls usw.)
- Du kannst die meisten Programme direkt über deren API automatisieren ohne auf Fenster, Maus und Tastatur Funktionen angewiesen zu sein
- Du kannst grafisch anspruchsvollere GUIs mit GDI und sogar in 3D mit diversen Erweiterungen realisieren
- Du kannst sogar Assemblercode zur Ausführung bringen
- uvm.

Natürlich kannst du jetzt mit allem mal rumprobieren, aber so ganz ohne konkrete Aufgabe und Ziel wirst du denke ich mit der Fülle an Möglichkeiten überfordert sein.

Ich empfehle dir daher dir eine einfache Aufgabe zu setzen, zu schauen wie du dies deiner Meinung nach realisieren kannst und dann ggf. hier nachfragen wie wir das realisieren würden. Sehr wahrscheinlich wird man dir dann die Vor- und Nachteile deiner Lösungswege aufzeigen und dich ggf. auf alternative Funktionen hinweisen die besser geeignet sind um die Aufgabe zu lösen.

Um zu deinem Notepad Beispiel zurückzukommen:

Die Funktion FileSaveDialog() ist nicht zur Automatisierung von externen Programmen gedacht, sondern sie stellt dir einen Standard Windows "Speichern" Dialog für deine eigene Software bereit. Da du Notepad automatisieren willst musst du den "Speichern" Dialog von Notepad aufrufen und entsprechend ausgefüllt absenden. Hierfür kann entweder die Tastenkombination STRG+S an das Fenster gesendet werden oder aber du verwendest die Funktion WinMenuSelectItem() um den Punkt "Speichern" im Dateimenü auszuwählen.

Letzlich ist die Automatisierung von Notepad aber nicht wirklich die bevorzugte Methode um Textdateien zu bearbeiten (wurde oben ja schon erwähnt). Hierzu verwendet man normalerweise die "File*" Funktionen und bei Bedarf diverse "String*" Funktionen. Evtl. wirst du hierbei auch die Nutzung der "Array*" Funktionen in Erwägung ziehen.

Wenn $file "-1" ist dann gab es Probleme die Datei zu öffnen bzw. zu erstellen. Wie die msgbox ja schon aussagt. Du musst also rausfinden warum das so ist. Hierfür kann es unzählige Gründe geben.

Die häufigsten Fehlerursachen:

- Du hast keine Berechtigung um im entsprechenden Pfad eine Datei zu erstellen oder zu ändern (Die Windows Benutzerkontensteuerung verbietet dies z.B. in den Standardverzeichnissen wie "C:\programme\...")
- Du hast einen Fehler im Dateipfad, sprich deine Variable $File_Name enthält einen Fehler (z.B. ungültige Zeichen oder allgemein ungültige oder noch nicht existente Pfade)
- Du verwendest fileopen() ohne später fileclose() zu verwenden und es verbleiben offene Dateihandles beim Programmende. Dies führt evtl. zur Zugriffsverweigerung, da Windows davon ausgeht, dass die Datei bereits in einem anderen Programm exklusiv schreibend geöffnet ist.
- Du öffnest die Datei mehrmals in deinem Script mit fileopen() ohne sie jeweils mit fileclose() zu schließen.
- Die Datei ist tatsächlich paralell noch in einem anderen Programm geöffnet und gesperrt.

Ähm hast du dir die Beispielscripte aus dem Link von UEZ angeschaut? Die dort verwendete Funktion _GDIPlus_GraphicsGetDPIRatio() Gibt dir das abweichende Verhältnis der DPI zum Standardwert. Damit kannst du die korrekte Schriftgröße wie im Beispiel berechnen.

Solltest du also neben der Standard GUI Schriftgröße noch weitere vom Standard abweichende Controls nutzen dann verwende dort eben ebenfalls den ermittelten DPI Abweichungsfaktor.

Ich würde ein if winexists(...) then vor den DLL Call stellen um Probleme mit nicht mehr existenten Fenstern zu vermeiden.
Evtl. ebenfalls sinnvoll wäre es DLLopen() und DLLclose() in Verbindung mit OnAutoItExitRegister() zu nutzen.

Zitat von Bioshade

Datenausführungsverhinderung habe ich bisher noch nie gehört - was ist das, und wie kann ich da eine Ausnahme machen?

Zur Datenausführungsverhinderung (Data Execution Prevention):
https://www.windowspro.de/andreas-krosch…r-konfigurieren

Xorianator könnte hier aber richtig liegen. Evtl. nutzt dein Script Drittsoftware welche zuvor beendet wird und dann zum Programmabsturz führt. Ohne Quellcode wirst du das aber nur selbst prüfen können.

Naja würde da den Fehler mal nicht zwangsweise bei deiner Anwendung suchen. Bei E/A Fehlern würde ich grundsätzlich erstmal RAM und HDD auf Fehler prüfen.

RAM-Test: https://www.heise.de/download/product/memtest86-41271
HDD-Test: http://crystalmark.info/redirect.php?product=CrystalDiskInfo

Ist hier alles okay prüfe im Gerätemanager ob alle Geräte fehlerfrei erkannt werden. Wenn nicht installier die passenden Treiber. Aktuelle Chipsatztreiber schaden jedenfalls nicht.

Sollte der Fehler immernoch auftreten kommt evtl. auch ein übereifriger Virenscanner in Frage... testweise deaktivieren und prüfen ob der Fehler dann nicht mehr auftritt.
Unter Serverbetriebssystemen könnte außerdem noch die "Datenausführungsverhinderung" zu Problemen führen. Testweise dein Script dort zu den Ausnahmen hinzufügen.

Gibt es nicht auch bessere Wege Putty bzw. SSH Sessions zu automatisieren? Eine kurze google Suche mit den passenden Begriffen lässt mich dies jedenfalls vermuten. Consolen-Programme wie Putty via Send/Controlsend zu automatisieren wäre mir jedenfalls viel zu heikel und unzuverlässig.

Bei der Arbeit nutzen wir in einem unserer BatchScripte z.B. WinScp in Verbindung mit einem Commando Script um lokale Backup-Dateien des Linux Hosts auf einen zentralen File Server zu übertragen. Ich nehme an mit Putty ist ähnliches machbar.

Ein weiteres Optimierungspotential besteht noch wenn deine Daten entsprechend strukturiert sind. Anstatt jedesmal die volle DB auszulesen könntest du dann inkrementelle Updates der lokalen DB machen. Sprich lediglich die Erstsynchronisierung verschlingt viel Zeit, alle Folgesynchronisiserungen werden kaum noch Zeit benötigen. Das erfordert aber zwingend einen Timestamp in den Tabelleneinträgen oder eine Log-Tabelle, welche jede Änderung zeitlich protokolliert.

Dir geht es also eigentlich nur um Performance Optimierung? Dann würde ich dir empfehlen deine bisherigen Versuche hier zu posten und ggf. auch erste Analysen durchzuführen was genau wieviel bzw. am meisten Zeit verschlingt.

Am lesen der Daten wirst du nicht viel optimieren können. Wenn du 350000 Einzelwerte zurückbekommst wird das immer einiges an Zeit benötigen. Tricksereien sind natürlich auch hier möglich. Im unten verlinkten Thread nutze ich beim Auslesen aus der DB die DB-Funktionen zum Verketten von Stings um letztlich nur einen einzigen Riesenstring aus der DB zurück zu bekommen. Dieser String muss dann zwar wieder von mir gesplittet werden, letztlich spart man je nach Datenmenge aber dennoch Zeit (insbesondere bei einer "entferneten" DB sollte das sehr viel bringen, da hier die meiste Zeit für den Transfer der vielen Einzelpakete drauf geht).

Beim Schreiben der Daten kann man aber durchaus einiges optimieren. Die simpelste Variante ist der Aufbau eines großen "Write"-Statements anstatt für jeden Recordset ein eigenes "Write"-Statement abzuschicken. Dadurch hast du nur einen einzigen Schreibvorgang und nicht hunderttausende.

Performance von SQLite optimieren?

Und was genau willst du von uns nun hören?

Meine Fragen zu deinem vorhaben:

1. Wozu eine lokale sqlite DB Kopie, wenn du die Daten bereits auf einem "richtigen" Datenbankserver hast und deine Software diese auch live von dort beziehen könnte?
2. Wenn du das schon machen willst, dann mach es doch. Wo genau ist deine Frage oder dein Problem? Das Vorgehen sollte doch kein Problem darstellen... SQL-Server Verbindung aufbauen, Daten lesen und Daten in die lokale DB schreiben.
3. Wenn du keine Ahnung hast wie du überhaupt eine Verbindung zur externen DB herstellst wäre es vielleicht nicht verkehrt zu erwähnen von welchem DB Server du sprichst (MS-SQL, MySQL, PostgreSQL oder vielleicht auch nur eine Access DB oder sonst irgendwas...). Je nach DB-Server gibt es die unterschiedlichsten Autoit UDFs.

Zitat von AspirinJunkie

Sicher?:

Da lag ich wohl falsch, zumindestens beim Einsatz von Hotkeys und Adlibregister wird die Ausführung von sleep() tatsächlich unterbrochen.

Hab das Script zwar nicht getestet, aber so auf anhieb würde ich dir davon abraten eine 1000ms Pause in deine Endlosschleife zu packen. Sleep() ist blockierend und deine Hotkeys werden erst ausgeführt wenn die Sleep() Funktion beendet wird. 100ms sollten mehr als ausreichend sein und sorgen für ein deutlich rekationsfähigeres Script. Dürfte in deinem Fall zwar nicht allzu relevant sein, aber für die Zukunft ist es vielleicht hilfreich zu wissen, dass zu lange "Sleeps" negative Auswirkungen haben können.

Deine @LF bzw. @CR Ersetzung ist übrigens fehlerhaft und führt zu doppelten Zeilenumbrüchen, da das @CR vom zuvor eingefügten @CRLF erneut durch @CRLF ersetzt wird. Das Ergebnis ist dann ein @CRLFLF

Hier eine korrekte Lösung:

if NOT StringInStr($sSource,@CRLF) then ;Wenn keine Zeilenumbrüche in Windows sichtbar
		$sSource=StringReplace($sSource,@LF,@CR);Ersetze Linux/Mac Zeilenumbrüche durch die von Windows
		$sSource=StringReplace($sSource,@CR,@CRLF);Keine Ahnung, warum jemand cr nutzen sollte, aber man weiß ja nie^^
	endif

Schonmal nach Alternativen gesucht? Anstatt die GUI zu automatisieren könntest du evtl. auch andere Methoden anwenden. Ein kurzer Blick in die Dokumentation der Software und schon findet man Informationen zu einem "command line interface".

Doku: http://www.trinamic.com/_scripts/downl…L_reference.pdf

Desweiteren gibt es auch einen Kundensupport, der dir vielleicht beim Lösen der eigentlichen Aufgabe behilflich sein kann.

Die Frage ist also wie so oft... "Was soll eigentlich gemacht werden?"
Das "Wie soll es gemacht werden?" ist letzlich zweitrangig.