Beiträge von AspirinJunkie

Da hab ich mal Helferlein für derartige Fälle geschrieben.

Mit >>dieser UDF<< lässt es sich z.B. so lösen:

$aFiltered = _ArraySlice($aArray, '22,28,31,32,33,38,42')

Danach nur noch ein _FileWriteFromArray() und fertig.

Zitat von PSblnkd

ist mir aufgefallen, daß in der Datenbank-Datei einzelne Datensätze mehrfach vorkommen, teilweise auch unvollständig.

Kann man mit entsprechenden Constraints verhindern, dass solche Datensätze überhaupt eingetragen werden dürfen.

Zitat von PSblnkd

dann kommt noch dazu, daß sie nicht in der Reihenfolge der "LfdNr" abgelegt sind.

Man kann natürlich sortiert abfragen.

Zitat von PSblnkd

Ebenfalls müssen noch alle Umlaute etc. editiert werden ... es ist doch arbeitsintensiver, als angtenommen.

Die Umlaute selbst muss man eigentlich nicht anpassen. Man muss beim Zugriff im Grunde nur das richtige Encoding setzen.

Wie gesagt: Wenn du die DB zeigst, können wir dir entsprechend helfen.

Zitat von Alina

Ja ich habe gesehen, ds es ein Unterschied der Dateien von 185 Byte gibt. Inhaltlich gleich, aber irgendwo müssen ja die Bytes 185 Byte einen Grund haben.

Riecht mir eher nach Änderung der Kodierung.
Z.B.: Wenn in deinem Bild 185x die Bitfolge C4 vorkommt und der Texteditor die Datei in der Kodierung Windows-1252 interpretiert eingelesen hat.
Dann wird er diese Bitfolge als ein großes Ä interpretieren.
Wenn man das ganze nun aber speichert und der Editor den Inhalt nun in der Kodierung UTF-8 abspeichert, dann muss er die Kodierung für das Ä von C4 in C3 84 ändern, da das Ä in UTF-8 ebenso dort kodiert ist.
Heißt aber auch: du hast dann 185 Byte mehr Speicherverbrauch.

Zitat von PSblnkd

In der Zeit, die ich vergeblich im Internet rumgestochert [...]

In der Zeit in der WIR vergeblich in dem Nebel deiner Informationen rumgestochert haben, hätten wir dir schon 20x einen entsprechenden Konverter geschrieben.

Machen wir es kurz: Wir können nicht wissen, welches Format die Datei hat, wenn du sie uns nicht zeigst. Ich zitiere dich daher mal:

Zitat von PSblnkd

Man kann ja jeder x-beliebigen Datei das .dbf-Extension anhängen ...

Und genau deswegen können wir dir schlicht nicht weiterhelfen ohne den Inhalt der Datei.

Zitat von PSblnkd

Leider gibt es in der AutoIt-Hilfe keinerlei allgemeine Infos zu dem hier verwendeten SQL-Light. Wenn ich das richtig verstehe, basiert die gesamte SQL-Light-Funktionalität auf der integrierten SQLight.dll, zu deren Wirkungsweise (mir) nichts bekannt ist - z.B. wie ist wirklich das dbf-Ausgabeformat ...

Die in AutoIt integrierte SQLite-UDF (nicht SQL-Light) ist für die Interaktion von AutoIt-Skripten mit SQLite-Datenbanken gedacht.
Wer das verwendet, sollte also wissen was SQLite macht und wie man es anwendet. Hierzu dient die umfangreiche Doku von sqlite.
Die Schnittstellenfunktionen die AutoIt hierfür mitliefert, sind alle korrekt und ausführlich in der AutoIt-Hilfe beschrieben.

SQLite ist ein bestimmtes Datenbankmanagementsystem mit einem eigenen Format zur Speicherung.
DBF hingegen ist das Dateiformat (wir können ja nur vermuten) des Datenbankmanagementsystems DBase.

Beide haben erst einmal nichts miteinander zu tun.
Es gibt lediglich externe Tools um Daten von einem DBMS in das jeweils andere zu konvertieren.
Für dbase gibt es keine in AutoIt mitgelieferte UDF, für SQLite hingegen schon.

Es gilt weiterhin alles das was Oscar dich fragte.

dbf ist eine DBase-Datenbank (hornsalte Datenbank aus den 80ern...).

Es gibt Konverter um solche in sqlite zu konvertieren.

Ab da kommt man auch besser weiter.

Warum man eine Datenbank ausgerechnet in html konvertieren muss ist mir hingegen nicht klar. Daher gilt erstmal alles was Oscar sagte.

Zitat von mumpel

Das nützt in Word nichts, weil da der Quelltext eingefügt wird, da müsste man den ganzen Code erstmal ins spezielle Word-Zwischenablageformat bringen (zuviel Aufwand).

Ich habe keinen Schimmer was du damit sagen möchtest:

Zitat von mumpel

Bei "pinetools" sind es ganz andere Farben, a muss man den ganzen Quelltext nachbearbeiten, wenn man die selben Farben möchte wie in SciTe.

Ja und warum nimmst du dann nicht direkt SciTe, wenn dir dessen Farben so wichtig sind?
Unter edit findest du die Option "Copy as RTF".

Es gibt diverse Online-Syntax Highlighting-Tools.
Dort gibst du deinen Code ein, wählst die Programmiersprache und den Formatierungsstil und er formatiert dir den Code entsprechend.

Dann einfach noch per Copy & Paste in Word reinkopieren.

Ein Tool, welches auch AutoIt unterstützt wäre z.b. dieses: pinetools-syntax-highlighter

Ansonsten ist Word wohl eher semi-geeignet für Code-Dokumentationen.
Selbst in einfachem markdown hat man schon syntax-highlighting mit an Bord (je nach Interpreter) und das ist enorm verbreitet bei der Code-Dokumentation (siehe die readme.md bei github-repositories).
Und wenn es hübsch sein soll, dann wäre auch LaTeX eine Option mit integriertem Syntax-Highlighting.

Setz nach dem Löschen folgenden Befehl ab:

SELECT changes() FROM moz_historyvisits;

Wenn ich das richtig verstehe, dann möchtest du alle die löschen, welche nicht deinen Kriterien entsprechen?
Dann funktioniert das schon so wie du es geschrieben hast aber es ist zugegeben erst einmal schwierig auf Anhieb zu verstehen was der SQL-Code macht.

Als Alternative könnte man sich einen zusammengesetzten Wert nehmen und dort dann wieder mit NOT IN arbeiten.
Also z.B. so:

Global $aExceptions[4][2]

$aExceptions[1][0] = 1
$aExceptions[1][1] = 2
$aExceptions[2][0] = 5
$aExceptions[2][1] = 50
$aExceptions[3][0] = 6
$aExceptions[3][1] = 9

Global $sSQL = 'DELETE FROM moz_historyvisits ' & _
               'WHERE name || "," || host_key NOT IN ('

For $w = 1 To UBound($aExceptions) - 1
    $sSQL &= '"' & $aExceptions[$w][0] & ',' & $aExceptions[$w][1] & '", '
Next
$sSQL = StringTrimRight($sSQL, 2) & ")"

ConsoleWrite($sSQL & @CRLF)

Ob das unbedingt besser ist will ich gar nicht mal behaupten.
Zumindest eine Alternative und vielleicht eher zu verstehen.

Aus dem Array einen String mit den entsprechenden Bedingungen bauen und an den sqlite-Befehlsstring anhängen.

Für genauere Hinweise müsstest du ein Beispiel posten.

Wenn eine benutzerdefinierte Funktion aufgerufen wird, wird @error auf 0 gesetzt (Siehe Hilfe zu SetError() )

SetError(1)
Test()

Func Test()
    ConsoleWrite(@error & @CRLF)
EndFunc

In deinem Fall wird die Funktion _Eins() aufgerufen, hierbei wird @error auf 0 gesetzt und damit _Eins() auch einen @error-Wert zürückgeben würde, müsste man SetError() verwenden - das fehlt in deiner Funktion _Eins() jedoch.

Das geht mit AutoIt.
Im Grunde ist AutoIt sogar auf genausoetwas spezialisiert.

Im einfachsten Fall brauchst du etwas zur Detektion der Änderung - das kannst du z.B. über PixelCheckSum machen oder wie Moombas schrieb über Werteabfragen.

Und zum anderen brauchst du dann noch ein Konstrukt um die Änderung dauerhaft zu überwachen - das kann z.B. eine Endlosschleife oder soetwas wie AdlibRegister sein.

Ich habe dir mal ein Beispiel erstellt und dieses übertrieben kommentiert. Damit solltest du arbeiten können und einen Anstoß haben sich mit AutoIt zu beschäftigen:

; ===================================================================================================
; Globale Variablen / Konstanten - grundsätzliche an mehreren Stellen / mehrfach zu verwendende Werte
; ===================================================================================================
; Die Koordinaten des zu prüfenden Bildschirmbereiches
Global Const $nLeft = 100, _
             $nTop = 100, _
             $nRight = 500, _
             $nBottom = 400

; Variable, welche später die Checksumme des Bildschirmbereiches enthalten wird
; vorbelegt mit dem aktuellen Wert als Vergleichsbasis
Global $nCheckSum = PixelChecksum($nLeft, $nTop, $nRight, $nBottom), _
       $nCheckSumOld = $nCheckSum ; wird den vorherigen Wert enthalten - zum Vergleich
; ---------------------------------------------------------------------------------------------------

; Tastenkombination Shift-ESC zum Beenden des Skriptes - sonst wird es ewig laufen (siehe Endlosschleife)
HotKeySet("+{ESC}", _beenden)


; Endlosschleife (Until-Bedingung wird nie erfüllt)
Do
    ; aktuelle Checksum des Bereiches ermitteln:
    $nCheckSum = PixelChecksum($nLeft, $nTop, $nRight, $nBottom)

    ; Wenn sich der Bereich geändert hat - mache etwas - sonst den Bereich ignorieren
    If $nCheckSum <> $nCheckSumOld Then

        ; Vergleichswert für den nächsten Check aktualisieren
        $nCheckSumOld = $nCheckSum

        ; nun kommt der Teil, wie du auf das Ereignis reagieren möchtest
        ; hier beispielshaft nur erstmal eine Ausgabe per MessageBox:
        MsgBox(48, "Änderung erkannt", "Im Bereich gab es eine Änderung!")

    EndIf

    ; pausiere die Prüfung für 1s
    Sleep(1000)
Until False




; eigene Funktion, welche das Skript beendet (für HotkeySet oben)
Func _beenden()
    Exit
EndFunc

Ausführlich >>Hier<< diskutiert.

Wenn es kein LaTeX sein soll (was ich allein aufgrund der enormen Größe einer TeX-Distribution durchaus nachvollziehen kann) dann könntest du dich nach anderen Formaten und Umsetzern umsehen.
Das Prinzip bleibt im Grunde gleich: Dein Programm erzeugt Code in irgendeiner Auszeichnungssprache und dieser wird dann von einem Übersetzertool nach PDF konvertiert.

Auf Anhieb würden mir da Markdown und html einfallen. Für beide Formate gibt es pdf-Übersetzer für die Kommandozeile, wobei markdown eher eingeschränkt ist was Tabellenauszeichnung angeht - hier wäre evtl. AsciiDoc eine Alternative.

Groff hatte ich auch noch im Hinterkopf aber ob das heute noch state-of-the-art ist bezweifle ich ein bisschen.

Ansonsten hättest du noch die Wahl entsprechende Bibliotheken einzubinden (die oftmals Geld kosten) und deine PDF im Programm über die Bibliothek zu erstellen.

WMI setzt nichtbelegte Attribute auf NULL.
Null ist kein Leerstring und kann auch nicht mit diesem verglichen werden.

Deine Abfrage muss hier also If $objItem.ScreenWidth = null Then lauten oder ganz explizit If IsKeyword($objItem.ScreenWidth) = 2 Then.

Wenn du Zweifel hast, was dir zurückgegeben wird, dann frage am besten den Datentyp mit VarGetType() ab damit du weißt womit du es zu tun hast.

Wenn es dir hingegen darum geht die Datensätze zu überspringen, welche dort null stehen haben, dann kannst du das auch direkt beim Select filtern:

SELECT * FROM Win32_DesktopMonitor WHERE ScreenHeight IS NOT NULL AND ScreenWidth IS NOT NULL

Und wieder schamlose Eigenwerbung von mir!:
Um aus einem Array-In-Array-Konstrukt ein 2D-Array zu erzeugen (und auch andersherum), kann man ebenso die JSON-UDF nehmen:

#include "JSON.au3"
#include <Array.au3>

; Array-In Array bauen
Global $A[3] = [1,2,3]
Global $B[3] = [5,6,7]
Global $C[3] = [8,9,10]
Global $AInA[] = [$A, $B, $C]

; Array-In-Array in ein 2D-Array konvertieren:
$AInA = __JSON_AinAToA2d($AInA)
ConsoleWrite(@error & @CRLF)

; 2D-Array anzeigen
_ArrayDisplay($AInA, "2D-Array")

Die >>JSON-UDF<< bringt bereits Funktionen mit, die hier weiterhelfen können.
Der Vorteil der _JSON_addChangeDelete() wäre, dass 1. die gewohnte Syntax - halt in einem String - verwendet werden kann und 2. noch viel komplexere Verschachtelungen - auch mit Maps und Dictionaries - hiermit behandelt werden können.
Lediglich 2D-Arrays werden noch nicht unterstützt (siehe Edit unten).

Beispiel hierzu:

#include "JSON.au3"

; [optional] Funktionen in Funktionsvariablen stecken um diese "umzubenennen"
; man kann natürlich stattdessen auch direkt die Funktionsnamen verwenden
Global $_get = _JSON_Get
Global $_write = _JSON_addChangeDelete
Global $_print = _JSON_Generate

; Unsere verschachtelte Beispielstruktur:
Global $a = ['a.Element0', 'a.Element1']
Global $b = [0, $a]

; Beispiel um aus der verschachtelten Struktur zu lesen:
ConsoleWrite('Lese aus $b[1], Item 1:' & @CRLF)
ConsoleWrite($_get($b, "[1][1]") & @CRLF & @CRLF)

; Schreibe / ändere einen Wert:
$_write($b, "[1][1]", "Neu")

; die gesamte Struktur nach dem Schreiben darstellen:
ConsoleWrite("Die gesamte Struktur nach dem Schreiben:" & @CRLF)
ConsoleWrite($_print($b) & @CRLF)

Edit: Die _JSON_Get() kann nun auch mit 2D/3D-Arrays umgehen. Syntaxbeispiel: [2, 3]

Zitat von tm5

HotKeySet("{F8}", "CheckHotkey")

Wo steckt die aufzurufende Funktion "CheckHotkey"?

Deine Funktion dial() wird zu keinem Zeitpunkt aufgerufen - du kannst sie also weglassen.

Zitat von Andy

Wieso Sonderfall? Die Anzahl der angehängten Nullbits entstehen doch immer, wenn die Summe der Anzahl der enkodierten Bits nicht glatt durch 8 teilbar ist. Und der Dekodierere "zufällig" beim angehängten Bitmuster ein Zeichen (Blatt des Huffman-Baums) erkennt.

Na der Sonderfall ist der, dass ein Zeichen den Code 0 besitzt und genau dieses Zeichen am Ende des Strings auftaucht. Das meinte ich mit Sonderfall. Indem ich alle Nullen hinten wegschneide habe ich das bisher umgangen.

Nun habe ich tatsächlich die Anzahl der ungenutzten Bits noch mit hinzugefügt (gerade bei github hochgeladen).
Jetzt wird die Größe des kodierten Streams in 37,5 % aller Fälle um 1 Byte ansteigen.
Ich denke das ist verschmerzbar denn nun hat man den Sonderfall auch noch mit abgedeckt.

Zitat von Andy

diese exzessive Beachtung sämtlicher(!) Design- und Coderegeln

Ich denke da sollte kein professioneller Programmier drüber schauen - dann würde die Aussage wohl ziemlich schnell zerpflückt werden.

Zitat von Andy

In der Funktion _huff_decodeBinaryToString() versuchst du ganz zum Schluß per RegExReplace() etwas, was imho so nicht funktionieren kann...außer bei "Textdateien" aka Dateien ohne Nullbytes.

Doch doch. Das funktioniert schon für den Fall, für den es gedacht war.
Nämlich folgender:

#include "Huffman.au3"

$sString = "AABC"

Global $bEncoded = _huff_encodeString($sString)
Global $sStringDecoded = _huff_decodeBinary($bEncoded)

ConsoleWrite($sStringDecoded & @CRLF)

Führe das einmal mit dem StringRegExpReplace() aus und einmal ohne und du siehst welcher Fall damit gelöst werden soll.

Beide Varianten scheitern jedoch weiterhin an diesem String: "ABCC"

Die Lösung ist tatsächlich so wie du sagst: Man muss die Anzahl der aufgefüllten Nullbits mitspeichern.
Das könnte man gleich am Anfang der kodierten Daten in 3 Bits packen (kann ja nur maximal den Wert 7 annehmen).
Das war mir durchaus bewusst - ich war in dem Moment aber schlicht zu faul für diesen arg unwahrscheinlichen Sonderfall noch diese Anpassung mit reinzudängeln.

Ich finde es aber echt geil wie ihr beiden tatsächlich diesen Code bis ins kleinste Detail verstanden habt.
Ich selbst hatte ab und an schon Probleme zu verstehen was ich eigentlich gemacht habe aber in eurem Fall ist das gleich nochmal ein Zacken schärfer.