Apache OpenOffice (AOO) Bugzilla – Issue 100659
The type of variable doesn't return correctly
Last modified: 2017-05-20 09:32:02 UTC
See the attached document public-dim-issue.odt. There are two macro modules 1) The macros in module1 : Option Explicit public a1 as String Sub Main a1 = "Hello Module1" msgbox a1 'error, it returns 0 End Sub ============================== 2) The macros in module2 Option Explicit private a1 as Integer Sub Main a1 = 1 msgbox a1 End Sub ================================= When run Module1.Main, a1 returns 0. It is incorrect. a1 should return "Hello Module1". Notice: a1 is defined as public String in Module1, while defined as private Integer in Module2.
Created attachment 61267 [details] test document to demonstrate this issue
Created attachment 61268 [details] patch to fix this issue
pflin -> ab, do you think the patch is good for you?
Remarks on this Issue. The anomaly comes from the handling of Private variables in OOoBasic. A) Without special option, Private variables are in fact Public ! (see Issue 17948) Proof : if you change in module2 the declaration to : public a1 as integer you have exactly the same result, wrong message and no error. I would not say it's a Basic bug, because there are two public declarations on the same variable; the last one is used. It's a programmer bug. If you really want to use Private variables you must use a special option: see solutions B) and C) B) Keep private a1 in module2 and change module1 like this: Option Explicit public a1 as String Sub Main CompatibilityMode(True) ' enforce Private variable handling a1 = "Hello Module1" msgbox a1 'error, it returns 0 End Sub then you get a runtime error : undefined variable. This is in my opinion the only real bug. It should display Hello Module1. C) Another option is the VBA mode (which includes the same correction of OOoBasic). Change module1 to this: Option Explicit Option VBASupport 1 ' use VBA compatibility mode public a1 as String Sub Main a1 = "Hello Module1" msgbox a1 'error, it returns 0 End Sub then you get the same incorrect runtime error : undefined variable.
regarding a), b) & c) a) private not private eeek!!!, ok lets forget about that ( I had ) but I disagree about the second part regarding 2 public variables, I would think this is an issue of scope. b) & c) I would say are the same thing, vbasupport includes the CompatibilityMode setting the patch though doesn't address the issues fully, also the compatabilitymode awareness part seems wrong, imo those bits shouldn't have been removed. Also because of the way basic treats ( and stores ) module scope variables this problem is a little trickier than it first seems. I think even the order of the compilation of the modules might even cause some problems :-/ needs further investigation
-> PATCH, STARTED
hi andreas, please don't use the patch in this issue, let me try and dig out the latest version ( and erm look again at that newer patch which I meant to do... but didn't yet )
.
ab->npower: Sending this issue to you until you got time to have a look
Created attachment 63168 [details] latest patch version
->ab ( let the tennis begin ;-) ) finally I got a chance to look again at this. The main problem is that ( and it's mentioned somewhere below ) is that there is some confusion regarding scope. In 'ordinary' basic public module variables are actually defined at the library level. If you have 2 module variables with the same name then only one will really be used ( as one eclipses the other ). The patch addresses this by really defining module variables at the module level. Note: the comment in the patch about 'SbUserform' ( which dosn't exist yet upstream ) is equally valid for 'SbClassModuleObject' hmm I didn't really address visibility with this patch, e.g. if you have 2 module variables of the same name, both are equally 'visible' say from a third module. Which variable do you get by default? ( I don't know ) but certainly you can qualify them with the Module ( Module2.var, Module2.var etc. ) One would guess that both in VBA which variable you really get if you don't qualify the variable with a module specifier is an implementation detail. Until I come across some 'real' code to force me to obey whatever strange rule that VBA might employ I suggest we ignore this part for now
> Until I come across some 'real' code to force me to obey whatever strange rule > that VBA might employ it appears that you can't do this in VBA, the compiler will not allow the ambiguity
STARTED
As the patch still is in discussion and not directly usable I change the issue type to defect avoid conflict with the inactivity time rules.
I beg to differ, I think it is directly useable, what is that issue? ( setting back to patch in the mean time )
Oops, obviously I did not read the complete discussion carefully enough. Sorry So -> cws ab74, OOo 3.2 to meet formal cws requirements.
ab74 -> ab75
OOo 3.3
Not enough time left for 3.3 -> 3.4
OOo 3.3, FIXED
Verified in CWS mib17 (Warning: There is a "option vbasupport 1" missing in the bugdoc. Without that option, the test results still in "0" rather than "Hello Module1")