Apache OpenOffice (AOO) Bugzilla – Issue 91220
patch: allow string accessors to Basic array variables which represent an UNO object
Last modified: 2013-02-24 21:00:58 UTC
In Basic, if a given variable contains a UNO object supporting the XIndexAccess interface, it is possible to write something like element = container( index ) where "container" is the UNO object supporting XIndexAccess, "index" an integer value, and "element" the element which is to be retrieved. It would be nice (and consistent to other scripting languages of competing products :) to also have a *name access* to UNO containers. That is, if an object supports XNameAccess, then the following should also be possible: element = container( "elementName" ) Currently, this doesn't work, instead the "elementName" is interpreted as integer value, being 0, so always the first container element is retrieved, without any warning/error (which could be considered a bug of its own). The attached patch implements the XNameAccess support.
Created attachment 54846 [details] patch
Created attachment 54847 [details] patch with -b, for better readability of what is done
-> fs Remember that Basic already accepts a shortcut to .getByName : oSheet = ThisComponent.Sheets.getByName("prettyName") ' -- or -- oSheet = ThisComponent.Sheets.prettyname Some people already use this shortcut (but I don't like it). Notice that the element name is not case sensitive with this method. The introduction of container("elementName") could be useful in a VBA mode. In a pure OOoBasic mode you have to be aware of possible conflict with container(index) method. Currently you can do: oSheet = ThisComponent.Sheets(1) oSheet = ThisComponent.Sheets("1") ' string is converted to a number, perfectly licit And there is the common error : oSheet = ThisComponent.Sheets("Feuille1") ' converts to zero, and gets Sheets(0) without error
> Currently you can do: > oSheet = ThisComponent.Sheets(1) > oSheet = ThisComponent.Sheets("1") ' string is converted to a number, > perfectly licit Uhm - if we want to support this case (and I suppose for compatibility reasons we want), then the patch is bogus :( > And there is the common error : > oSheet = ThisComponent.Sheets("Feuille1") ' converts to zero, and gets > Sheets(0) without error Which is exactly what I stumbled upon - and why I created the patch ...
I will have a look... STARTED, 3.x
Regarding the compatibility concerns I would prefer to keep the Basic default behaviour and address this in the scope of the VBA mode. Does anyone have a problem with this? WONTFIX for now.
close the invalid issue