Hi Paolo,
please find my comments inline...
consider the following code:
(before to run it, you will need a dialog with a button and a textfield)
Does the problem only occur if you call CommandButton1_onAction()
via a command button event? I assume it would be the same if you
started a sub calling GetFolderName() directly.
REM ***** BASIC *****
Dim oDlg As Object
Sub Main
GlobalScope.BasicLibraries.LoadLibrary("Tools")
oDlg = createUnoDialog(DialogLibraries.Standard.Dialog1)
oDlg.execute
End Sub
'manually binded to the onAction event of the
'CommandButton1
Sub CommandButton1_onAction()
'call the function in Tool.ModuleControls
GetFolderName(oDlg.Model.TextField1)
End Sub
Ok it works perfectly. No problem here.
Now run the nice (and useful!!) xray macro from Bernard Marcelly. (v4.0)
At this point try again the given code:
Where do I find this macro?
In OOo 1.1.4 you get an error because xray contains a modified version (same
name) of the GetFolderName function.
In OOo 2.0 all works fine.
This seems to indicate that something is changed in the StarBasic's "scope
model".
Anyway, as a further testing, I've created a uno package with xray and I've
installed it with unopkg --shared option
After this, I've got the same error due to the name conflict.
I guess that now (ooo 2.0) , when you call a routine from another one, the
basic interpreter search the matching routine in this order:
1. current module
2. other modules in the current library
3. other libraries at shared level (only if already loaded)
4. other libraries at user level (only if already loaded)
Is this correct?
If yes, I would ask why is the shared level checked before the user level?
And In wich order are checked libraries (and modules)? by
name ?
1. and 2. is correct, 3. and 4. not. Internally Basic makes no dif-
ference between shared and user level libraries. Indeed OOo 2.0 has
a more explicit distinction between shared and user level macros
but this is only true for the user interface. There should be no
change regarding the library handling in Basic core, at least not
on purpose. Of course I cannot be sure to have never caused some
unwanted side effects by doing other changes. When I have the xray
macro I will check why the problem does not occur on OOo 2.0 with-
out using the package variant.
Unfortunately there is no official rule how Basic handles searching
modules and libraries internally, this is all implementation detail.
In general Modules are organised as vector inside a Library and Li-
brary are organised as vector inside a library manager. Also the
document Basic libraries are integrated in this hierarchy making
thinks even more complicated.
The libraries' order inside the vector depends on the order the li-
braries are loaded and this probably is part of the problem here.
The Standard library is always loaded first but for all other libra-
ries it also depends on user interaction and on using LoadLibrary
inside the macros. Of course that can cause problems like yours.
Basic is not really designed to support strictly seperated scopes
or even name spaces or function overloading. And this is not easy
to change. The advantage of Basic to be easy and to find every sym-
bol somewhere without fully qualifying it here obviously becomes a
disadvantage. Of course this becomes more critical now where ma-
cros can be provided as UNO package.
Is this algorithm documented somewhere?
No, if you don't count the Basic source code... ;-)
Is the same algorithm used also for public/global variables ?
Yes, subs/functions and variables are the same regarding scope.
A part from this, I would like to hear some opinions about the current
StarBasic's scope model:
The main problem I see is that currently the macro developer has no control
over the name space in which his macro will run.
There are no name spaces at all. Everything is global.
Infact, although you can load external libraries from your macro program, you
cannot avoid to have unnecessary libraries already loaded, and this can
potentially raise problems, as in my demo code.
What do you mean by "unneccary libraries"? Nobody is forced to
load a library he doesn't need. And the xray library will not
be loaded before used. But you probably mean that you cannot
unload a library? That's true. Maybe we need a mechanism to
reset Basic.
Yes, a possible workaround would be to use fully qualified calls (e.g.
Tools.ModuleControls.GetFolderName(...) )
BUT
1) "fully qualified" calls are ugly and they sound not very basic-ish :-)
2) nobody really uses this workaround
3) what about confilcts between global / public variables (or constants)?
is the "fully qualified call" applyable to variables too? (i guess no)
Now we really run into target conflicts. You don't want to use
fully qualified calls giving you full control as they are not
Basic like but nevertheless you want to have full control. That
sounds contradictory... :-) You're right with 2) but this would
be true for every new concept we may implement to solve this
problem. E.g. I could imagine to have a "private" library mode
that make libraries only search inside there own scope and not
searchable from outside. Besides the fact that this wouldn't
be easy to implement (changes in the Basic searching mechanism
are always very risky) this also would have to be used to be-
come active.
3) No difference to subs/functions. Example:
REM ***** Lib Library1 / Module1 *****
public nValLib1
Sub InitLib1
nValLib1 = 42
End Sub
REM ***** Lib Standard / Module1 *****
Sub Main()
InitLib1
print Library1.Module1.nValLib1
End Sub
Executing Main correctly prints 42.
I'm not sure how problems like this can be solved in general.
Any ideas are welcome. But there will alway be a target con-
flict between "easy to use" and "full control".
Regards
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
