Apache OpenOffice (AOO) Bugzilla – Issue 74375
read file with fixed record len, missing bytes, 2 bytes offset
Last modified: 2017-05-20 11:27:34 UTC
I have a DATEV file with fixed len records (256 Bytes) and want to read record by record (in OO Basic). I open it in Random mode with block len 256. The problem is that the first two bytes are skipped and all subsequent records have 2 bytes offset. I expected bytes rec 1: 1 - 256, rec 2: 257 - 512, etc, but I get rec 1: 3 - 258, rec 2: 259 - 514 Something similar happens when writing this files in Random mode: the first two bytes are "away" (I don't remember anymore, because writing the file in binary mode solves the problem) When reading the file in binary mode, the same applies. The first 2 bytes are missing. When I do a subsequent get with a Byte Position (e. g. 2560), again the first two bytes are missing (starts from 2562). Since I don't need the first two bytes, I can program a workaround (in attached file), but that is enerving. I tried, if this is a platform depending problem and did this also on Linux (OO 2.0, SuSE 9.3), but there the get command doesn't work at all (runtime error?!)
Created attachment 42878 [details] Program file to Test the problem
Created attachment 42879 [details] file with data to test
szodrow, any chance you could provide step-by-step repro instruction? Thanks a lot.
Created attachment 42979 [details] Worksheet with Macros and instructions
Hello, in the worksheet FileReadProblem.ods you find macros and instructions that show my problem(s). You have to modiy the directory and file name in the macro and you have to create a new test file or use e. g. the test file datev2blocks. :-)
->ab
STARTED, not yet reproduced
What does "STARTED, not yet reproduced" mean? Did the problem not occur? Is there something missing to reproduce it? Is it still unclear what the problem is? :-)
ab->szodrow: Unfortunately the status STARTED is misleading. It does not mean that I'm already working on this issue, it's only the next logical step following the status NEW. My boss wants me (and all my colleagues) to react on a NEW issue very fast. So I don't have the time to really reproduce every issue, especially if they look complicated like this one. I only check, if I'm the right one to deal with it in general and set it on STARTED. But I still need to reproduce it. I hope things are clearer now... :-)
basic and scripting issues now should be assigned to component "scripting"
set target to 3.x according to http://wiki.services.openoffice.org/wiki/Target_3x
After some more testing, I found the cause for this problem now: I had created a buffer of data type string. String is in Unicode in OpenOffice Basic. When writing non ASCII characters to disk those characters were physically expanded. When looking to those files in a hex editor, you could see this and suspecting an error. I replaced the string buffer with an Byte Array and the problem is solved. I think it was good to place a comment somewhere in the OpenOffice Documentation how to handle binary files correctly (Help or Wiki). Can you tell me a place where I can place an example? :-)
ab->szodrow: So you think we can close this issue or is there still also a wrong behavior in Basic? Concerning a hint in help or an example: If you think this should be part of the OpenOffice.org help please submit an issue to ufi@openoffice.org. Concerning Wiki I doubt that the OpenOffice.org Deve- loper's guide is the right place as it mainly deals with using UNO and only covers Basic in this context. You can have a look yourself: http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/OpenOffice.org_Developers_Guide STARTED again to don't leave it on NEW.
szodrow->ab: Can be closed
Reset assigne to the default "issues@openoffice.apache.org".