Bug Hunting Session
Bug 47263 - [BASIC] nested UNO structs confusing
Summary: [BASIC] nested UNO structs confusing
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
3.3.4 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:3.7.0
Keywords:
Depends on: 42819
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-13 00:07 UTC by Lionel Elie Mamane
Modified: 2012-07-06 06:23 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Elie Mamane 2012-03-13 00:07:07 UTC
+++ 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.
Comment 1 sasha.libreoffice 2012-06-05 02:59:03 UTC
Thanks for bugreport
reproduced in 3.3.4 and 3.5.4 Calc on Fedora 64 bit (Windows not tested)
Comment 2 sasha.libreoffice 2012-06-05 02:59:58 UTC
@ Noel
Greetings
What do You think about this bug?
Comment 3 Noel Power 2012-06-27 01:54:02 UTC
(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
Comment 4 Noel Power 2012-06-27 07:48:42 UTC
(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 )
Comment 5 Noel Power 2012-06-28 05:06:32 UTC
(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
Comment 6 Not Assigned 2012-07-04 12:16:17 UTC
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
Comment 7 Noel Power 2012-07-05 01:59:40 UTC
I'm tentatively marking this as fixed ( hopefully I haven't initiated BASIC meltdown )
Comment 8 sasha.libreoffice 2012-07-06 06:23:11 UTC
Thanks for fixing this bug