+++ This bug was initially created as a clone of Bug #42819 +++
(Reconfirmed with 3.5.0)
Nested UNO structs behave in confusing ways.
Dim b0 as new "com.sun.star.table.TableBorder"
b0.HorizontalLine.OuterLineWidth = 9
Expected result: 0, then 9.
Actual result: 0, then 0.
The value change is *silently* ignored.
The way to achieve changing the value is:
Dim b0 as new "com.sun.star.table.TableBorder", l as new "com.sun.star.table.BorderLine"
l = b0.HorizontalLine
l.OuterLineWidth = 9
b0.HorizontalLine = l
My guess (confirmed by Noel Power in bug 42819 comment 2) is that in the statement "b0.HorizontalLine.OuterLineWidth = 9", the sub-expression "b0.HorizontalLine" returns a *temporary* fresh *copy* of the sub-struct, and that this temporary copy is modified instead of the substructure of b0.
I maintain that this is a trap for the programmer, and that StarBasic would be a better language if TMP0 worked as expected. From a possibly naive POV, Basic could for example make a distinction between rvalues and lvalues like C does and use reference instead of value (copy) in an lvalue, and continue using value (copy) in an rvalue.
Thanks for bugreport
reproduced in 3.3.4 and 3.5.4 Calc on Fedora 64 bit (Windows not tested)
What do You think about this bug?
(In reply to comment #2)
> @ Noel
> What do You think about this bug?
Sorry to take so long to reply to this, I would say that I agree with the report, I wouldn't go as far as to say it's a bug ( maybe we could say it is a quirk of libreoffice basic ) so... lets call this an enhancement (lame I know). I will try
and see if there is an easy fix ( or even an easy to see how to fix ) for this.
Hate to say it though, in my exprerience issues like this usually have a reason,
that reason usually being the basic compiler/runtime is sooo crap that trying to
make it do something sensible can be incredibly hard. Would be cool though if this could work in a sensible way
(In reply to comment #3)
> Hate to say it though, in my exprerience issues like this usually have a
> that reason usually being the basic compiler/runtime is sooo crap that trying
> make it do something sensible can be incredibly hard.
well at least now I see exactly why this is happening, all uno objects are introspected, all properties of an uno interface object ( or members of of an uno struct ) are retrieved via uno via a XPropertySet interface. So.. that explains why attempts to modify the nested structure fail ( ok we knew it was returning a copy but good to know exactly where ( and in master that is basic/source/classes/sbunoobj.cxx:2129 ) All operations on uno objects are generically treated this way so changing this would require some work.
>Would be cool though if
> this could work in a sensible way
I haven't been convinced that this is an impossible task yet, still investigating, possibly we could intercept attempts to access nested struct members and wrap them with a new internal object that might use reflection instead to set the values ( never used uno reflection but a quick look at the api and it looks promising )
(In reply to comment #4)
> I haven't been convinced that this is an impossible task yet, still
> investigating, possibly we could intercept attempts to access nested struct
> members and wrap them with a new internal object that might use reflection
> instead to set the values ( never used uno reflection but a quick look at the
> api and it looks promising )
of course I should have realised the reflection api ( being an uno api ) suffers from the same problem, however.. the c++ uno api that the reflection component uses is interesting
Noel Power committed a patch related to this issue.
It has been pushed to "master":
initial attempt at fdo#47263 allow direct access to nested uno structs
I'm tentatively marking this as fixed ( hopefully I haven't initiated BASIC meltdown )
Thanks for fixing this bug