Apache OpenOffice (AOO) Bugzilla – Issue 17784
Strange behaviours of old basic objects
Last modified: 2017-05-20 11:29:23 UTC
REM ***** BASIC ***** 'the code below shows some strange behaviours 'of the interpreter when you use names of 'basic libraries as they would be objects Option Explicit Sub OldObjects Dim Obj As Object Set Obj = tools Print Obj.Name Print tools.gimmicks(,,,,,).tools.name Print schedule.gimmicks(,tools,).tools.thiscomponent.dbg_properties 'if a library is loaded, also modules names 'can be use globalscope.basiclibraries.loadlibrary("Tools") msgbox Strings.Ucb.Misc.name End Sub
Andreas, please take care of this and retarget accordingly (OOo2.0?)
-> OOo 2.0
According to the roadmap of OpenOffice.org 2.0 (http://tools.openoffice.org/releases/q-concept.html) this issue has been scheduled for 3.0.
So what? Is any specification violated by this Basic behaviour? No one has to use undocumented properties and if he does, he can't complain about the result. -> Completely uncritical, -> P5, probably WONTFIX
I'm surprised and sorry to hear this from you. You'll consider me a nitpicker but I think that this kind of things makes the difference between a toy and a professional tool regards Paolo
Hi Paolo, sorry, obviously I have phrased my comment too harshly. It really wasn't my intention to accuse you beeing a nitpicker. So I want to give some more background information how I rank the priority of tasks. In general for me tasks that prevent _correct_ (taking VB as reference) programs from running are far more criti- cal than tasks that describe the strange behaviour of a even more strange Basic macro. This task is a perfect example for the latter. Of course it would be nice if even things like this could be fixed and maybe you're right that this makes OOo Basic looking more pro- fessional. But when I started scanning my Basic issues some weeks ago, I had more then 90. I could mark many as double or invalid and could also fix some, but nearly all of the remaining 60 issues are far more critical than this one, because they can really break a correct Basic program or behave incompatible to VB. But I do even fix issues I consider to be uncritical, if the fix is easy and without risk. So I just fixed your i17826 "Basic: flaws in the colored syntax" that I also consider to be very uncritical. But here a fix probably would be much more difficult and risky be- cause it touches mechanisms and implementation details in the dee- pest Basic core. And I had to learn that it's better to be _very_ careful there. So I think fixing this task is simply not worth the risk and effort. Nevertheless I appreciate your critical view. Please continue to nitp... - ooops ;-) - to analyse the OOo Basic behavior precisely. I just can't promise to fix everything. Problems like this most probably will only be fixed if the fix is _very_ easy. Regards Andreas
Andreas, thank you for your kind reply. I must say that I agree on almost everything you said. Sure I agree with P5 and even P10 if it would exist :-) But nevertheless I would like that this small issue would be fixed, first or later. Anyway here the "problem" is not "correct code does not work" but "incorrect code does work" that is much different and less severe. Therefore I can understand your point of view and I will not reopen the issue if you will close it regards Paolo
Reset assigne to the default "issues@openoffice.apache.org".