Das älteste Datum wird genommen, und die Dateien werden intern einfach hintereinandergehangen und dann evaluiert. Probiers mal aus.
Beiträge von alpines
-
-
Denn zumindest Buttons führt Windows intern als Fenster... Ist also gut möglich, dass er bei einem Vergleich die Buttons durchlässt.
In WinList tauchen nur Fenster auf und keine Buttons auch wenn intern diese mit einem Window-Handle identifiziert werden.
-
Kannst du nicht mit _WinAPI_GetClassName das ganze prüfen?
Hier ein kleiner Test:
AutoIt#include <WinAPI.au3> $hForm = GUICreate("Form1",200,200) $hButton = GUICtrlCreateButton("Button", 5, 5, 190, 190) GUISetState() MsgBox(0,0,_WinAPI_GetClassName(WinGetHandle($hForm))) MsgBox(0,0,_WinAPI_GetClassName(ControlGetHandle($hForm, "", $hButton)))Sollte das nicht reichen kannst du ja mit WinList nach dem Titel suchen und schauen ob es dort existiert, sollte es dort vorhanden sein, dann ist es ein richtiges Fenster.
-
Schaust du dir eigentlich auch die Fehlermeldungen an? Der Interpreter schreibt dir doch in der Konsole in welcher Zeile der Fehler geschmissen wurde.
Wenn du das ganze wirklich elegant lösen möchtest könntest du alles in Array schieben und diese dann durchgehen.
Dann hast du am Ende ein Array mit den ganzen Daten die geprüft und ausgeführt werden sollen und nur eine Schleife in der du das Array iterierst.
-
Ich bin davon ausgegangen, dass du nur einen Vorgang bei zusammengefassten Dateien hast. Ich werd das mal anpassen.
Dass er einzeln nicht konvertiert habe ich schon gefixt.
-
Hmm, es funktioniert aber ich bin mir nicht sicher ob das wirklich stabil mit anderen laufen wird.
Es sind nur Dateien erlaubt wo eine Vorgangsnummer enthalten ist (egal ob es mehrere Zeilen mit der selben Nummer sind, die werden einfach hintereinandergehangen).
Teste das ganze Mal bitte.
-
... dann sieht es ja wohl so aus, dass es sich anscheinend um ein "Problem" in der Windows-Plattform handeln könnte.
Ich kann nicht zu 100% sagen, dass es daran liegt. Mit Cache war der Prozessorcache gemeint und softwaretechnisch kannst du da nicht viel machen.
Es ist nur eine Vermutung.
-
Ich musste Path noch zu @ScriptDir ändern aber konnte das ganze reproduzieren.
Ich schätze mal, dass der Windows Scheduler die Ressourcen unregelmäßig verteilt, oder es aus dem Cache neu geladen werden muss und es ab und zu schneller läuft und ab und zu mal langsamer.
Dasselbe Problem findet sich auch in GDI+ wieder, manchmal läufts rasend schnell und manchmal eben langsam.
Deshalb solltest du lieber statt jeder Schleifeninkrementation (nach dem Inkrementieren Lichter) lieber mit TimerDiff die Differenz zwischen den einzelnen Schleifendurchgängen zählen.
So kannst du in einer While-Schleife warten bis der TimerDiff exakt gleich ist und anschließend die Lichter inkrementieren.
Außerdem musst du mir unbedingt folgende Frage beantworten:
Warum rufst du deine eigenen Funktionen mit Call auf? Ruf doch die Funktion lieber direkt auf und nutze Set_LS_Button() statt Call("Set_LS_Button").
-
5 kbytes sind 5kbytes, wenn du die jede Sekunde herunterlädst, dann sind das 18MB in der Stunde. Stunde wohlgemerkt! Und da machst du dir einen Kopf wg. Netzwerkauslastung?
Die Informationen in der Tabelle sind vermutlich nur 5 kB. Der ganze "Overhead" mit dem Code der hinter dem Spreadsheet steckt (der ehrlich gesagt gar nicht soo groß sein sollte, da man nur eine Ressource runterlädt und nicht die verlinkten CSS, Javascript und Bildateien.) wird sicherlich da noch ein paar kB draufpacken.
Aber das steht ehrlich gesagt trotzdem in keinem Verhältnis, selbst wenn es 50 kB in der Sekunde sind fällt das beispielsweise bei einer 16k Leitung (~ 1.8 MB/s) praktisch überhaupt nicht ins Gewicht.
-
Dank Weiterleitung, Oberfläche und allem was mit läd springt die Netzwerkauslastung dabei aber auch immer mal wieder auf ~2,8mb/s.
Die Auslastung ist nicht wichtig, mess lieber wie viele Daten du herunterlädst (inkl. Oberfläche) und verrechne das mit wie oft du in der Sekunde diese dann abrufst.
Deine Netzwerkkarte zieht immer mit voller Leistung also ist es nicht schlimm wenn sie 2.8 MB/s (Mb oder MB?) zieht, das bemerkst du nicht.
-
Ist es denn wirklich eine so hohe Netzwerkauslastung, dass für dich das Mitladen der Umgebung dir Schwierigkeiten bereitet?
Google selber bietet ja eine API für die Spreadsheets an, allerdings gibt es da keine AutoIt-Implementation dafür, nur Java/C#.
-
Ja, das Problem ist, dass du vom AutoIt Skript aus Cookies mitsenden müsstest um dich als authentifizierter Browser auszugeben (oder den Loginprozess nachbauen).
Du siehst ja in der Antwort, dass du nicht authorisiert bist die Datei einzusehen.
Ansonsten könntest du testen die Datei öffentlich einsichtbar zu machen, dann würde ich aber dort keine sensiblen Daten speichern.
-
Es ist zwar ein wenig versteckt aber im Beispiel zu _Crypt_EncryptData findest du im Switch-Case der Combobox die einzelnen Algorithmen.
3DES, AES128, AES192, AES256, DES, RC2, RC4.
Du kannst auch in die Crypt.au3 schauen und siehst dann relativ weit oben die unterstützten Algorithmen auch wenn eine gesonderte Hilfeseite, wie es bei der BASS_UDF.chm sie gibt, gut wäre.
-
Schneid mal mit dem Netzwerk Sniffer mit welche URL du exakt herunterlädst wenn du auf den Exportier-Link navigierst.
Im Source-Code sollte davon der Pfad zum Direktdownload der .csv enthalten sein also kannst du mit BinaryToString + InetRead den Quellcode laden, den Direktlink extrahieren und den dann anschließend herunterladen.
-
Ok, dann setze ich mich da mal ran.
-
Genau, nur möchte ich die Dateien (also txt´s) selbst anwählen welche er zusammenfassen soll.
Und er soll für jeden Vorgang dann praktisch eine eigene Datei erstellen? Was ist bei (10|12, 10|12, 11|12)? Wie soll er die zusammenfassen?
Oder wählst du dann wirklich nur Dateien aus die nur einen Vorgang besitzen?
-
Das Switch-Case ist für die GUI-Nachrichten im Moment und hat mit der Ausleserei deiner Checkboxen absolut nichts zu tun. (Zumindest wie du vor hast es zu implementieren)
Nimm die ganzen Ifs und packe sie in ein Case wo der Auslöser davon der Installations Button ist.
-
Das geht auch aber die Strings in der neuen Ausgabe sind nicht mehr die selben wie vorher? Statt ME-Nummerhast du jetzt SERIENNR.
Statt Auftrag hast du CHARGE. Soll das ganze angepasst werden oder so wie vorher bleiben?
Wenn die Aufträge verschmolzen werden sollen, ist die Reihenfolge der Werte wichtig? Welches Datum soll genommen werden?
Soll das Programm letzen Endes einen Ordner übergeben bekommen und dann dort alle Daten auslesen und sie in das neue Verzeichnis schreiben?
Also praktisch alles lesen und Vorgänge der selben Nummer aus unterschiedlichen Dateien zusammenfassen und die Datei löschenfalls sie leer ist?
Willst du über eine MsgBox auswählen ob du nur eine Datei umwandeln oder ein ganzes Verzeichnis? Das müsstest du erstmal alles klarstellen.
-
Wo füge ich den Pfad ein wo die datei sitz die ich holen will?
Das ist aktuell das FileOpenDialog, du kannst da einen String einsetzen und einen absoluten Pfad zu einer Datei damit kennzeichnen.
Das ist dann immer eine Datei, wenn du willst, dass er einen gesamten Ordner umwandelt muss ich das umscripten.
Wo füge ich den Pfad ein wohin die Datei dann umgewandelt hin soll?
Das ist die Konstante S_SPEICHERORT, das ist der Ordner wo die Datei abgespeicchert werden soll. Da kannst du z.B. Global Const $S_SPEICHERORT = "C:\bla" machen.
Der Dateiname ist der selbe, nur die Endung wird angepasst.
Kannst du bitte das noch so machen, das wenn die Datei dort geholt und umgewandelt wurde die geholte alte Datei dann gelöscht wird?
Na klar, ich hab das testweise nicht gemacht, da du das ganze erstmal eine Weile beobachten solltest bevor du wichtige Daten verlierst.
Könntest du noch eine MessageBox einfügen in der ich etwas als Anweisung einfügen kann, bevor man die Datei auswählt?
Das ist auch eine Kleinigkeit.
Ist das ganze so in Ordnung?
-
Deine Cases haben keine Werte. Du musst nach dem Case einen Wert ausgeben welcher als Vergleich dient für den Switch Wert.
Du switcht die GUI-Nachricht und als Case gibst du Buttons, Edits, etc an.
