+++ This bug was initially created as a clone of Bug #42819 +++ (Reconfirmed with 3.5.0) Nested UNO structs behave in confusing ways. Consider: Sub TMP0() Dim b0 as new "com.sun.star.table.TableBorder" MsgBox b0.HorizontalLine.OuterLineWidth b0.HorizontalLine.OuterLineWidth = 9 MsgBox b0.HorizontalLine.OuterLineWidth End Sub Expected result: 0, then 9. Actual result: 0, then 0. The value change is *silently* ignored. The way to achieve changing the value is: Sub TMP1() Dim b0 as new "com.sun.star.table.TableBorder", l as new "com.sun.star.table.BorderLine" MsgBox b0.HorizontalLine.OuterLineWidth l = b0.HorizontalLine l.OuterLineWidth = 9 b0.HorizontalLine = l MsgBox b0.HorizontalLine.OuterLineWidth End Sub 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)
@ Noel Greetings What do You think about this bug?
(In reply to comment #2) > @ Noel > Greetings > 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 > reason, > that reason usually being the basic compiler/runtime is sooo crap that trying > to > 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": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1720641bf36306fc296635925e571556ced8a302 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