[Libreoffice-bugs] [Bug 133889] Invoking a Basic routine with ByRef Long or Double parameter does not return modified value

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=133889

--- Comment #1 from libre officer <smartazaiz at gmail.com> ---
(In reply to Mike Kaganski from comment #0)
> This is one of two related bug reports (the other is bug 133887); attachment
> 161869 [details] contains the tests for both. Please run
> TestByRefFromInvoke, and only check last two lines of output (OutputByRef3
> and OutputByRef4) for the purposes of this bug.
> 
> If there is a routine with a ByRef parameter (i.e., inout parameter),
> invoking it using XScript::invoke [1] requires passing *in* values through
> the first array (sequence), and getting their modified *out* values in the
> last passed array. This bug is for explicit Long and Double parameters:
> 
> > Sub Foo(v As Long) ' default ByRef
> >     v = 100000
> > End Sub
> 
> > Sub TestInvoke
> >     oScript = thisComponent.getScriptProvider().getScript("vnd.sun.star.script:Standard.Module1.Foo?language=Basic&location=document")
> >     oScript.invoke(Array(0&), aOutInd, aOutArr)
> >     MsgBox aOutArr(0) & " " & TypeName(aOutArr(0))
> > End Sub
> 
> TestInvoke above passes "0&" (i.e., an explicit Long value) as initial value
> of the variable passed to the Foo, and expects to get the modified value in
> the aOutArr(0) - i.e., it should output "100000 Long".
> 
> However, the actual returned value is 0 of type *Integer*. It is possible to
> get the correct result by modifying the value passed to invoke call like
> this:
> 
> >     oScript.invoke(Array(200000), aOutInd, aOutArr)
> 
> So it is not enough to pass an explicitly-typed long value; it turns into a
> smaller type if its value fits that smaller value.
> 
> The conversion was introduced in
> https://git.libreoffice.org/core/+/11f9aa4fcb2ad0a5fada8561c7041e7f25a059fc,
> and was made conditional (dependent on VBASupport) in
> https://git.libreoffice.org/core/+/9cdb73ff28c4cd6380412468f34ff10e46292a07.
> The reason for the conversion is expressed as "Choose "smallest"
> represention for int values because up cast is allowed, downcast not". I
> *suppose* that the idea was that it's possible to call some UNO API like
> this:
> 
> > Dim n As Long
> > n = 1
> > oSomeObject.AMethodExpecting16BitValue(n)
> 
> ... which would fail if value of n would be passed as 32-bit integer to the
> method. Thus, I suppose that removal of the conversion could be an
> incompatible change breaking infinite number of existing macros (so
> unacceptable; yet, I don't have a proof of this suspicion). I also don't
> know if it's possible to find a proper condition to disallow downcasting for
> the purposes of ByRef parameters.


I run your `TestByRefFromInvoke` and got this Message Box:

OutputByRef0: [ (Empty)]        [Error 91 (Error)]      [6.75 (String)] [True
(Boolean)]        [7 (Integer)]   [7 (Integer)]   [7 (Integer)]   [7 (Integer)]
(Ref: 6.75)
OutputByRef1: [ (Empty)]        [Error 91 (Error)]      [ (String)]     [True
(Boolean)]        [0 (Integer)]   [0 (Integer)]   [0 (Integer)]   [0 (Integer)]
(Ref: True)
OutputByRef2: [ (Empty)]        [Error 91 (Error)]      [ (String)]     [False
(Boolean)]       [1 (Integer)]   [1 (Integer)]   [1 (Integer)]   [1 (Integer)]
(Ref: 1)
OutputByRef3: [ (Empty)]        [Error 91 (Error)]      [ (String)]     [False
(Boolean)]       [0 (Integer)]   [0 (Integer)]   [0 (Integer)]   [0 (Integer)]
(Ref: 100000)
OutputByRef4: [ (Empty)]        [Error 91 (Error)]      [ (String)]     [False
(Boolean)]       [0 (Integer)]   [0 (Integer)]   [0 (Integer)]   [0 (Integer)]
(Ref: 12.5)


But I don't understand why this line:

oScript.invoke(a1Param, aOutInd, aOutArr)

You declared `invoke` like this:

Function Invoke(aParams()) As String

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200614/8cbaa097/attachment-0001.htm>