Mike Kaganski
79a2e1d861
The problem appeared, when a macro loaded a library with a class module, that had a public element (e.g., a function) with the same name, as used for a local variable in the macro without a prior DIM. Normally, there is a precaution in SbModule::Find, which hides the names in class modules. However, this precaution failed during load. The reason was, that the flag identifying the module as a class module was set only when the module got compiled. It turned out, that first, it is parsed in SbModule::SetSource32 only partially, with minimal work to recognize the names (and a few other small things). At this stage, it is not marked as class module yet; and when the clashing name is looked up, it gets found in the module. Then its value is requested; at this point, the module gets compiled, and the "class module" flag is set; then, if the class module element tries to use another name from the same module, it fails, which produces visible error message. This change makes sure, that the initial fast parse stage also checks Option ClassModule, to set it properly. Also it drops redundant variable bIsProxyModule from SbModule, because mnType already contains the needed type information. And lastly, it reorders SbModule::Find a bit, to avoid searching a module, only to discard the result immediately, because it's a class module. Change-Id: I8add9873bf31fb767b64d27a36aef8e3a89a0de0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192075 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
StarBASIC Interpreter
Contains the StarBASIC Interpreter
This implements a macro language that, when in VBA compatibility mode, is intended to be interoperable with Visual Basic for Applications, allowing people to run macros embedded in their documents.