Hi all,
consider the following code:
(before to run it, you will need a dialog with a button and a textfield)
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:
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 ?
Is this algorithm documented somewhere?
Is the same algorithm used also for public/global variables ?
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.
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.
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)
thanks
Paolo Mantovani
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
