Apache OpenOffice (AOO) Bugzilla – Issue 90594
Put Statement [Runtime]
Last modified: 2016-07-21 18:34:23 UTC
I have found a bug when used the "put" statement of VB: Open "c:myfile.bin" For Binary As #1 Dim i as Integer For i = 1 To 1000 Put #1, , "A" Next i Close #1 What must the size of file be? I have the size of file - 485 bytes. It is not correct.
first, * wrong component ( vba component is specifically for the vba interoperability feature ), the lines are blurred here though as this is a function that exists both in standard openoffice basic and vba. But anyway from a vba compatibility point of view this interests me :-) thanks for reporting it * I can confirm this behaviour with the snippet attached
I also can reproduce it. I think there are some similar issues. STARTED, OOo 3.x, P1 -> P3. ab->rupike: This is no P1 at all, please have a look at: http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#priority
I entered some more stuff about this but seem to have lost it ( probably it's gone into some unrelated bug and caused no end of confusion to someone else ) But basically the problem occurs because the impl code for Put _can_ handle an optional 'recordnumber' param. Unfortunately o) the impl code doesn't detect the 'recodnumber' param which is in the SbxError state o) in stdobj.cxx the 'recordnumber' param is not marked as optional o) optional params are only really handled in StepPARAM ( not run in this case though ) SbiRuntime::SetupArgs() ( which does run ) ignores Optional params altogether ( that is if named params are used ) so, I think we should make some effort improve things here ( seems like most of the code to do that is alread in StepPARAM), or is it intentional to leave each rtl function to decide for itself optional values etc.?
*** Issue 90593 has been marked as a duplicate of this issue. ***
From your comment I have understand that you started to fix the bug.
Can you inform me about status of the bug? - Thank you!
Can't reproduce any more, on Windows 8 or 32 bit Ubuntu Linux 14.04. Probably fixed by the new(ish) _USE_UNO file I/O that we use now instead. Resolving fixed.