To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=53818
User ab changed the following:
What |Old value |New value
================================================================================
Priority|P3 |P4
--------------------------------------------------------------------------------
Target milestone|--- |OOo Later
--------------------------------------------------------------------------------
------- Additional comments from [EMAIL PROTECTED] Mon Sep 12 05:48:06 -0700
2005 -------
Hi Noel,
now I know what you mean, but I won't call this behaviour incorrect. Whenever
a value passed from UNO via a language binding a conversion is performed. No-
where is guaranteed that this conversion always can be performed without
any "losses". In this situation the original UNO type is lost as Basic is not
able to store it within its own values.
So if you later pass this value to UNO again it's not the same value any more
and another conversion is performed, this time from Basic to UNO. And you're
right, in this situation a best fit algorithm is used. But this is only the
case for any parameters where Basic simply cannot know which target type is
expected by the implementation. So in general the type is choosen that proba-
bly will succeed in the most cases. So if the source type is a number the
"smallest" possible representation is chosen, a 42 long would be converted to
a byte. So a widening conversion - also performed by the C++ any stream opera-
tors - will always succeed. And in general especially implementations of any
based interfaces have always to be aware of dealing with language bindings
that cannot always provide the exact UNO type. So at least if a complex type
is expected the implementation should be generous concerning the passed type.
In case of doubt, it even has to use the com.sun.star.script.TypeConverter ser-
vice. There are also languages that are even less typed than Basic. By the way:
As a workaround in Basic it should also be possible to force the desired target
type using the CreateUnoValue runtime function.
Of course it could be an option to keep the original UNO type in Basic and I
even know some other situation where this could be helpful. But this would
mean a really deep change for the Basic object/value system. I also think that
it could be difficult to decide when this UNO type has to be given up in case
of modifying a Basic array converted from an UNO sequence. This all could be-
come really ugly.
So I think this task is near to WONTFIX. I keep this task for tracking in case
that there are more reasons to change the UNO type handling in Basic, but I set
it to P4 / OOo Later and have my doubts if it will be fixed.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
