BITMAP-Datei mit FileRead lesen.

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

Zitat von olfibits

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

Es liegt daran, dass die Dateien nicht binär gelesen und somit falsch interpretiert werden, wenn du auf dem Zugangsparameter der beiden FileOpen +16 addierst,

dann funktioniert auch das ganze schon wieder.

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 :

#include <FileConstants.au3>  ; Konstanten für FileOpen

; -> bisherige Zeile :
;$handl=FileOpen ("bitmap.bmp")   ; Bitmap-Datei einlesen
; -> ersetzen durch :
$handl=FileOpen ("bitmap.bmp", $FO_BINARY)   ; Bitmap-Datei einlesen (binary)

$Daten=FileRead ($handl)
$error=@error
$Length=@extended
FileClose ($handl)
MsgBox(0,"","$handl="&$handl&" error="&$error&" extended="&$Length)

; -> bisherige Zeile :
;$erg=FileOpen("ergebnis.txt",2)
; -> ersetzen durch :
$erg=FileOpen("ergebnis.txt", BitOR($FO_OVERWRITE, $FO_BINARY))

FileWrite($erg,$Daten)
FileClose($erg)
Sleep(1000)
;run("notepad.exe bitmap.bmp")
;run("notepad.exe ergebnis.txt")
run("HexeditMX bitmap.bmp")
Sleep(1000)
run("HexeditMX ergebnis.txt")

Gruß Musashi

Zitat von DOheim

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.

Und hier $Daten in einer MsgBox :

Soweit sind die Ausgaben identisch !

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

Gruß Musashi

Zitat von DOheim

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.

Zitat von DOheim

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

Du liest die Dateien aus und sie liegen binär im Skript vor. Die Binärrepräsentation ist richtig, denn verwendest du BinaryToString($Daten) so kannst du die Stringrepräsentation deiner Daten sehen, und dort taucht auch dann das "BM" in der Konsole auf und die Datei ist exakt wie die bitmap.bmp im Texteditor.

Zitat von DOheim

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.

OT:

Zitat von DOheim

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

Zitat von 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