BUG ??? File Read nach Script breaking Changes Version 3.3.14.2

Mahlzeit,
ich bin am verzweifeln!!!!
Bis zur Version 3.3.8.1 hatte ich einen file open File read Befehl OHNE mir irgendwelche Gedanken zu dem Thema Zeichensätze zu machen.
Das hat auch alles wunderbar funktioniert - ICh öffnete *.prn Dateien sowohl für Nadeldrucker als auch für Laser,.

Dann kam es Dicke.

Version 3.3.14.2 --> Ich musste den File open dialog anpassen. Aber was auch immer ich eingebe für die Nadeldruckerfiles bekomme ich nur quadrate angezeigt. Egal welcher im Handbuch stehender Zeichensatz eingesetzt wir. Mit Notepad ++ funktioniert die Darstellun im ANSI Mode genau so wie es sein soll -- > Autoit only quadrate.

Ich beschreibe die Zeichenkette:"EScap"Klammeraffe"Escape"GRosbuchstabe C"NUL als wort nul"Die beiden Großbuchstaben FF" (Ohne die Anführungszeichen)
ESC@ESCCNulFF

(Ein Druckbefehl --> Ich möchte eigentlich nur das 2te Zeichen - den Klammeraffen und das vierte Zeichen, das C haben aber das wird nichts)

Ich bräuchte BITTE schnell Hilfe -- > Danke

Gruß

Peter

PS.: In der steten Hoffnung das Problem richtig beschrieben zu haben

Ich habe die Files in allen zur Verfügung gestellten Modi geöffnet und mir das Ergebnis per msgbox anzeigen lassen.

Der demo code ist unspektakulär.
-------------------
Local $hFile = FileOpen ( 'F:\datei_pruefer\TMP\TMP_Beleg_in\DL268486.13', 16384 ) ;$ Anpassung auf Compiler Version 3.3.14.2
$erkenner = 'z'
$erkenner = FileRead ( 'F:\datei_pruefer\TMP\TMP_Beleg_in\DL268486.13',500)
MsgBox (0, 'Erkenner_1_ ', $erkenner)
FileClose($hFile)
-------------------------
Wobei ich die Werte von 0-16384 entsprechend Hilfe durchprobiert habe.......

Gruß

Peter

Ich kann noch etwas dazu beitragen:

1) Auf einen anderen Rechner Autoit 3.3.8.1 instaliert -- > Dann geht das wie es soll.
2) Wenn ich aus Notepad ++ (ANSI) heraus das File speichere und erneut mit Autoit3.3.14.2
öffne ist das Problem auch weg.

3) Ich habe ein paar 100.000 Files davon. --> Autoit 3.3.8.1funktioniert 3.1.4.2 NO GO

Jemand noch eine Idee?

Gruß

Peter

HAbe ich noch nicht geprüft mache ich gleich.

Ich habe die Textdatei Orginal und die mit dem Notepad ++ mal mit einem Hexeditor geöffnet:

1B 40 1B 43 00 0C FF 20 FF 20 FF FF 20 20 FF 20 von der ersten bis zur lezten Zeile der gleiche HEX

local $encoding = FileGetEncoding ( 'F:\TEMP\test2.13')

Ergebnis 2048 das dürfte es entsprechend der Hilfe zu dieser Funktion gar nicht geben.
-----------

Mit Autoit Version 3.3.8.1 kommt übrigens 0 = ANsi heraus
Mit Autoit Version 3.3.12.0 kommt übrigens 0 = ANsi heraus
Und die Zeichen stellen sich in Autoit < 3.3.14.0 so dar wie zu erwarten.
Der Fehler taucht erst mit 3.3.14.0 auf - Also mit dem Umstellen der Funktion.

Lehne ich mich zu weit aus dem Fenster wenn ich auf Bug tippe?

@Kanashius Sorry ich habe alle ausprobiert - siehe oben.
Ja in der doku zu fileopen steht selbstverständlich 2048 - aber nicht in der doku zu FileGetEncoding
----------------------------------------------

Anyway ich habe zu file open noch mehr neues.

Die Version 3.3.12.0 liefert unterschiedliche Werte ein und derselben Datei für den Fall:

Local $hFile = FileOpen ( F:\test.13, 16 );
$erkenner = FileRead ( F:\test.13, 100)

und
$erkenner_2 = FileRead ( $hFile, 100)

wenn ich es richtig verstehe wird '16' öffnen im binary Mode mit der Pfadangabe nicht ausgeführt sondern nur über das Handel

Kann das jemand bestätigen?

@'misterspeed

Du kommst meinen Erkenntnissen um eine Pizza zuvor
-------------

Ich möcht das ganze einmal so zusammenfassen:

Fileread über den Pfad ignoriert den in fileopen mitgegebenen Parameter des Codierungstyps. Das wahr wohl auch schon vor 3.3.14.0 so.

Nur bei einem Fileread mit Handl werden die Codierungsparameter aus fileopen berücksichtigt.

Das hat vor 3.3.14.0 meist nichts ausgemacht - weil es auch ohne diese Parameter zu brauchbaren Ergebnisen gekommen ist (wer nicht gerade binary benötigt hat).

Ab 3.3.14.0 ist die Angabe aber zwingend nötig!!

Was mich stört : -- > Das steht nirgends (oder ich habe es überlesen?) !.

Da gibt es dann 2 Möglichkeiten:
1) Das ist ein Feature mit einem Fehler in der Hilfe Datei.
2) Das ist ein Bug und die Hilfe Datei ist ok.

@ misterspeed --> Woher weißt Du das? Ich habe einen halben Tag gebraucht um das herauszufinden?

Danke für Eure Hilfe.

Auf gelöst möchte ich das noch nicht setzen - denn irgendwie sollten sich diese Erkenntnisse ja in der Hilfe wiederspiegeln - Was also tun?

Gruß

Peter

Note: Do not mix filehandles and filenames,
i.e., don't FileOpen a file and then use a filename in this function. Use either
filehandles or filenames in your routines, not both!

Das hatte ich so nicht verstanden Ich ging immer davon aus, dass für den Fall von fileread/filewrite usw. nicht gemischt werden soll. Also entweder mit Pfad oder mit Handl. Vielleicht ist auch mein Englisch nicht gut genug? Aber in der Hilfe zu fileread steht ausdrücklich:

Alternatively you may use a string filename as the first parameter.

Vielleicht ist auch mein Verständnis von Fileopen usw. nicht richtig. Das Handl gibt es erst mit fileopen. Da ich in fileopen den Pfad sowieso schon festgelegt habe benutze ich den dann auch in den folgenden Befehlen read write usw.

FileReadRead in a number of characters from a previously opened file.
FileRead ( "filehandle/filename" [, count] )
Parameters

Return Value

Remarks
A negative or not defined count, reads the whole file from the current position.

If a filename is given rather than a file handle - the file will be
opened and closed during the function call - for parsing large files
this will be much slower than using filehandles.
Note: Do not mix filehandles and filenames, i.e., don't FileOpen() a file and then use a filename in this function. Use either filehandles or filenames in your routines, not both!

Both ANSI and UTF16/UTF8 text formats can be read - See FileOpen() for details.

A file can be read as binary (byte) data by using FileOpen()
with the binary flag - in this case count is in bytes rather than
characters. A count value that is too large can lead to AutoIt stopping
with a memory allocation failure.

@misterspeed

Danke das ist extrem verständlich --> Sollte in die deutsche Hilfe

Was mir bis dato nicht klar war, dass ich mir das fileopen hätte sparen können, wenn ich hinterher das fileread mit pfadangabe nenutze.
Den Satz :
don't FileOpen a file and then use a filename in this function. Use either filehandles or filenames in your routines, not both!

hatte ich vollkomen falsch verstanden. Ich hatte das wie folgt verstanden:
1) fileopen
2) fileread ----> hier nicht mischen
3) file write ----> hier nicht mischen
4) fileclose

Dein Satz:
Fileread mit direkter Pfadangabe ermittelt die Codierung automatisch und erzeugt dann ein passendes fileopen handle. Ein manuelles fileopen ist hier absolut irrelevant, da fileread nichts vom bestehenden handle wissen kann wenn du es nicht explizit übergeben hast.

Macht es glasklar.

OK seit Jahren doof gestellt ---> Danke

Deine Erkläung sollte wirklich in die Hilfe....

Gruß

Peter

High Mars,
ja da geht einem der Hut hoch. Zumal ich auch noch der Meinung war, alles richtig zu machen.
Zuerst ein fileopen dann ein Fileread. Mein Fehler war nur, dass ich das mit dem Mischen von Handl und Pfadangabe falsch interpretiert habe. Ich sozusagen ein nutzoses Filopen gemacht habe. Ich bin über Wochen fast durch die Decke vor lauter .

Ich möchte es an dieser Stelle nochmal vorschlagen, die Essenz des ganzen , insbesoders die Erklärung von misterspeed in die Deutsche Hilfe aufzunehmen.

Denn ab und an finde ich würde etwas mehr Erklärung allen viel Zeit sparen. Ich hätte da noch einen - mancher mag nun lachen, weil fast zu simpel - aber da schreibt man zuerst If fileexist F:\Test\A*.* -- > Das funktioniert. NAch 3 Monaten wird aus der Zeile dann
If fileexist F:\Test\*.*.

Und man wundert sich warum es einfach nicht funktionieren will. Bis man feststellt --> Autoit kann das so nicht. Steht --> Ja klar bei Google und in keiner Hilfe.

Gruß

Peter