BITMAP-Datei mit FileRead lesen.

  • Mein Programm, das BITMAP-Dateien bearbeitet, lief immer prima.
    Jetzt habe ich eine kleine Änderung vorgenommen und es neu compiliert.
    Nun funktioniert es nicht mehr.
    Und warum?
    Es liegt an der Funktion FileRead. Mit ihr konnte ich die BITMAP-Dateie einlesen, so wie sie ist. Also jedes Byte wurde unverändert in das Zielfeld eingelesen.
    Aber das neue FileRead scheint "mitzudenken". Es erkennt wahrscheinlich, dass es sich um eine BITMAP handelt und liest eine völlig verstümmelte Zeichenfolge ein.

    Ich arbeite mit

    AutoIt Stabil 3-3-14-2.

    So wie es auch heute noch angeboten wird.


    Was kann ich nun machen?

  • Vielleicht musst du irgendwo einen "Binary" Flag setzen, eventuell vorher mit FileOpen festlegen und dann bei FileRead auf das handle verweisen.

    neben AutoIt jetzt auch noch in C/C++, Java und Python aktiv :)
    Stand 04.04.2018, 13:34

  • Vielleicht musst du irgendwo einen "Binary" Flag setzen, eventuell vorher mit FileOpen festlegen und dann bei FileRead auf das handle verweisen.

    Das war auch mein Gedanke, daher mal wieder die obligatorische Standardbitte an DOheim :

    Könntest Du ein abgespecktes aber lauffähiges Skript (und eine Bitmap) posten, mit dem sich der beschriebene Fehler reproduzieren läßt.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Hallo DOheim !

    Vorab : Der Hinweis von alpines ist natürlich zu 100% korrekt !!

    Ich persönlich bin aber kein großer Freund von 'magic numbers', sondern bevorzuge aussagekräftige Konstanten, d.h. :

    $FO_OVERWRITE statt 2 für -> Schreibmodus (löschen des vorherigen Inhaltes)

    $FO_BINARY statt 16 für -> Binärmodus erzwingen

    usw.

    Vollständige Liste, siehe : https://www.autoitscript.com/autoit3/docs/f…ns/FileOpen.htm

    Das ist letztlich reine Geschmackssache - technisch ist es identisch ;). Danach würde dein Skript wie folgt aussehen :

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Vielen Dank für Eure Antworten. Aber leider bringt das keine Lösung.

    Auch wenn ich den Mode 16 in

    $handl=FileOpen ("bitmap.bmp",16)

    verwende, wird mir nach $Daten nicht der wirkliche Inhalt der Datei eingelesen, sondern

    jedes Byte wird in zwei hexadezimale ASCII-Zeichen zerlegt.

    Das Zurückschreiben mit

    $erg=FileOpen("ergebnis.txt")

    hatte ja nur den Zweck, dass man sieht, was in $Daten steht.

    Und mit dem Feld $Daten will ich ja im Programm arbeiten.

  • Das Zurückschreiben mit

    $erg=FileOpen("ergebnis.txt")

    hatte ja nur den Zweck, dass man sieht, was in $Daten steht.

    Und mit dem Feld $Daten will ich ja im Programm arbeiten.

    Hmm, so genau weiß ich auch nicht, was Du mit den Daten machen möchtest.

    Screenshot Bitmap im Hex-Editor
    Sreenshot ergebnis.txt im Hex-Editor

    Und hier $Daten in einer MsgBox :

    Screenshot MsgBox

    Soweit sind die Ausgaben identisch !

    Mit z.B. ConsoleWrite wird $Daten so nicht angezeigt. Dazu folgendes angeben : ConsoleWrite(String($Daten))

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Hallo Oscar und Musashi,

    mein BITMAP-Programm kann verschiedenes.

    Z.B.: siehe

    Assembler

    insbesondere mein Beitrag #8.

    Ich kann auch die in einer eine Excel-Datei eingetragenen Koordinaten (die evtl. innerhalb Excel mittels trigonometrischer Funktionenerrechnet wurden) auswerten und danach eine Zeichnung erstellen.

    Aber das geht nun alles nicht mehr, weil die AutoIt-Entwickler einfach FileRead so verändert haben, dass man eine Bitmapdatei nicht mehr unverändert einlesen kann. Enttäuschend!

  • wird mir nach $Daten nicht der wirkliche Inhalt der Datei eingelesen, sondern

    jedes Byte wird in zwei hexadezimale ASCII-Zeichen zerlegt.

    Wo wird was zerlegt?

    Das sagt mir dass du dir die eingelesen irgendwo ausgegeben hast um diese anzusehen.

    Öffnest du diese Datei in einem Text-Editor oder in einem Hex-Editor oder wo?

    Und was sind "hexadezimale ASCII-Zeichen"?

    Zeige uns einen möglichst kurzen Code der das von dir beschriebene Verhalten reproduziert und wir können dir helfen.

    Das Problem liegt nämlich mit 99,9% Wahrscheinlichkeit nicht am FileRead sondern an einer ganz anderen Stelle.

    Aber das geht nun alles nicht mehr, weil die AutoIt-Entwickler einfach FileRead so verändert haben, dass man eine Bitmapdatei nicht mehr unverändert einlesen kann. Enttäuschend!

    Dann wärst du der erste der damit Probleme hast.
    Man konnte sowohl früher als auch heute Binärdaten einlesen und ausgeben.

  • Also der erste ist er nicht. - Ich hatte bei diesem Wechsel auch Probleme als ich alten Code neu compiliert hatte. Es dauerte Stunden bis ich das bemerkte.

    Daraufhin habe ich zu jedem Code akribisch notiert mit welcher Autoit Version ersellt und compiliert. Wegen oftmals kleiner Codeänderungen, macht es bei Scriptbreaking changes keinen Sinn alles anzupassen. Im übrigen schaue ich mir seitdem die Changes auch an - anstelle blauäugig die neue Version aufzuspielen.

    Im übrigen erinnere ich mich auch, dass es mit 16 nicht getan war und ich irgendwie alle Varianten durchprobiert hatte. Aus dem Bauch heraus fand ich die alte Lösung auch besser - obwohl die neue datzu zwingt sich mit diesem Problem auseinanderzusetzen.

    Peter

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

    Ab 19-10-22 ergänzt um:

    Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen. (Albert Einstein)

  • Ich muss zugeben mein Test war blöd gewählt.

    Neu:

    Bitte die hier angefügte Datei Test.zip in einen neuen Ordner extrahieren und dann Test.au3 starten.

    • run("notepad.exe bitmap.bmp") zeigt nun, wie die Bitmap-Datei aussieht. Zum Beispiel am Anfang stehen bei jeder Bitmap-Datei die beiden Zeichen "BM"
    • run("notepad.exe ergebnis.txt") zeigt, was wirklich eingelesen wird. Dabei musste ich aber ein "x" (d.h. irgend ein anderes Zeichen) davorsetzen, weil FileWrite sonst die hexadezimale Zeichenfolge erkennt und entsprechend zurückkonvertiert.
      Im Feld $Daten steht also statt der beiden Zeichen "BM" die hexadezimale Zeichenfolge "0x424D" am Anfang.
      0x42 ist der Hexadezimalwert für "B" und 0x4D ist der Hexadezimalwert für "M".

    Mit dieser hexadezimalen Zeichenfolge kann aber mein Programm nichts anfangen.

  • Herzlichen Dank Alpines,

    das ist die Lösung. Ich werdeBinaryToString($Daten)in mein BITMAP-Programm einbauen und dann wird es wieder wie früher laufen.

    Ich habe nicht gewusst, dass diese hexadezimale Zeichenfolge als "Binary" bezeichnet wird.

    Nochmals Vielen Dank!

  • Das Fileread spielt in meinem BITMAP-Programm an verschiedenen Stellen eine Rolle. Außerdem hat ja das neue FileWrite auch seine Tücken.

    Es war mir zu mühselig mich in das umfangreiche Programm wieder einzuarbeiten und alles entsprechend anzupassen.

    Deshalb habe ich es mir einfach gemacht:

    Ich habe von AutoIt 3.3.8.1 die Compilerdatei Aut2exe.exe in Aut2exe.exe umbenannt und in den Ordner C:\Program Files (x86)\AutoIt3\Aut2Exe kopiert.

    Mit dieser habe ich mein BITMAP-Programm kompiliert und nun läuft es wieder.

    Sehr befriedigend ist das nicht.

    Gibt es eigentlich Assembler-Befehle bzw. -Routinen, mit denen man auf Basis von AssembleIt eine Datei einlesen und schreiben kann?

    Einmal editiert, zuletzt von DOheim (22. November 2017 um 18:18)

  • Gibt es eigentlich Assembler-Befehle bzw. -Routinen, mit denen man auf Basis von AssembleIt eine Datei einlesen und schreiben kann?

    Dir ist es zu mühselig das FileRead in deinem Programm entsprechend anzupassen aber mal einfach die File-Prozeduren durch Assemblercode zu ersetzen stellst du dir einfacher vor?

    Zum Thema Assemblerfilefunktionen: Möglich natürlich und sicher auch schon irgendwo vorhanden. Aber da man ja in ein bestimmtes FileSystem schreibt wird man die entsprechenden System-API-Funktionen hierfür ansprechen. Also genau das was auch die File-Funktionen von AutoIt machen - nur anders verpackt.

    2 Mal editiert, zuletzt von AspirinJunkie (22. November 2017 um 19:06)

  • OT:

    Gibt es eigentlich Assembler-Befehle bzw. -Routinen, mit denen man auf Basis von AssembleIt eine Datei einlesen und schreiben kann?

    Genau dafür wurde AssembleIt NICHT gemacht!

    Ziel war und ist, den "inner Loop" von an sich "langsamen" AutoIt-Schleifen und Berechnungen zu beschleunigen und ansonsten sämtliche Vorteile von AutoIt und dessen Funktionen zu nutzen.

    Wie AspirinJunkie erläutert hat, sind so gut wie alle "nativen" AutoIt-Funktionen sehr eng an das Windows-API gekoppelt, ich würde einfach sagen, gewrappert....

    Wenn nicht gerade irgendwelche esoterischen Ausnahmen bestehen, welche größtenteils durch den AutoIt-Datentyp Variant beeinflusst werden, dann laufen die nativen Autoit-Funktionen genau so schnell ab, wie die API-Aufrufe dieser Funktion in beliebigen anderen Programmiersprachen!

    Es macht also seltenst Sinn, eine (AutoIt-)API-Funktion durch den Aufruf der API per DllCall() ersetzen zu wollen.

    BTT:

    DOheim

    Ich habe von AutoIt 3.3.8.1 die Compilerdatei Aut2exe.exe in Aut2exe.exe umbenannt und in den Ordner C:\Program Files (x86)\AutoIt3\Aut2Exe kopiert.

    Mit dieser habe ich mein BITMAP-Programm kompiliert und nun läuft es wieder.

    Sehr befriedigend ist das nicht.

    Wieso ist das nicht befriedigend? Ich verwende in der Firma ausschliesslich die 3.3.8.1 und mir käme nicht im entferntesten in den Sinn, dort auf eine der "neuen" AutoItversionen upzugraden, wozu auch?

    Die von mir erstellten Scripte laufen seit Jahren problemlos. Und daher ist dort ist der "Update-Wahn" völlig fehl am Platz!

    Nach einem Update auf ein "neues" AutoIt nicht bzw. viel schlimmer, FALSCH laufende Scripte würden einen immensen wirschaftlichen Schaden bedeuten. Vom Schaden meiner Reputation garnicht zu reden....

    Übrigens könntest du folgendes versuchen, um mit der "neuen" AutoItversion trotzdem glücklich zu werden.

    Erstelle eine eigene Funktion __FILEREAD__(), welche genau das macht bzw. zurückgibt, was du benötigst. Diese Funktion zu erstellen solltest du schaffen, siehe dein Post#15.

    Dann ersetzt du im gesamten Script (in SCITE per ctrl+h) das (AutoIt-native) FileRead durch deine __FILEREAD__-Funktion.

    Würde mich sehr wundern, wenn das nicht zum Erfolg führen würde ;)

  • Recht vielen Dank für Deine Antwort.

    Deine Ausführungen machen mich sicher: Ich werde AutoIt 3-3-14-2 deinstallieren und 3.3.8.1 installieren.

    Dann werde ich mich wieder wohlfühlen.

    Nochmals vielen Dank und bis bald mal wieder.