Re: Vendors Name via UNO API / Basic Macros

On 11/26/2013 01:56 PM, Lionel Elie Mamane wrote:
> On Thu, Nov 21, 2013 at 08:34:04PM +0100, Jan Holesovsky wrote:
> > Thomas Krumbein píše v Pá 15. 11. 2013 v 15:43 +0100:
>
> > > > > Well, this change was a small technical thing - but with a very big
> > > > > influence on typical market applications. Every custom macro application
> > > > > with dialogs or forms for user interfaces is influenced if dialogs/forms
> > > > > using Date/time fields.
>
> > > > Have you filed a bugreport, please?  A minimal example of the macro that
> > > > fails would be most appreciated.
>
> > > Well - it´s not a bug, because you mentioned the change in release-notes
> > > of version 4.1.
>
> > There are many ways how to make the problem less annoying in Basic
> > ;-) - we control the Basic implementation, so can work around many
> > things, and if we are lucky, this will be one of them. I am sure
> > we'd try to do that before the release with the incompatible change
> > if we knew early.
>
> Well, I considered doing some "magic" that when the property is
> written, if it gets an integer, interpret it the old way and if it
> gets a UNO Date struct, interpret it the obvious (new) way. Someone
> (Stephan Bergmann?) told me that one could do that for attributes but
> not (pseudo?)properties (or something like that); the Basic
> implementation (bridge?) would refuse to even pass a value of the
> wrong type to the C++ code. I don't see how to achieve it short of
> special-casing this into the bridge / other parts of the Basic
> implementation. Which sounds like a guaranteed subscription for
> maintenance nightmares, and thus not the best of ideas. Would the
> Basic implementation / UNO bridge people be willing to actually have
> that kind of special-casing?

Not sure what you mean with the sentence about attributes and 
properties.  But the Basic implementation would indeed be the place 
where to handle such special cases to improve backwards compatibility. 
(Which matches the observation that Basic authors and Basic code, which 
often comes included in documents, probably have the hardest time 
copying with our deliberate incompatibilities.)

Stephan