Re: Vendors Name via UNO API / Basic Macros

On 26/11/2013 13:56, 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?
>
> > > What´s happend, you can read my article on my homepage. It is in german
> > > language but I am sure, you get the context ;)
> > > http://www.mic-consulting.de/index.php/opersource/api-makros-libo-aoo/10-datumsfelder-geaendert-in-lo-4-1-1
> > I am sorry, cannot get the context :-(  Can you please turn it into a
> > minimal example of what used to work, and send it here?  Or even better,
> > file the bugreport, and send here the link?
> Another user already did that: https://bugs.freedesktop.org/68751
>
> It already led to concrete mitigation steps (in the form of utility
> functions to convert between the Basic native date type and UNO Date,
> Time and DateTime) in 4.1.3 (correctly documented in 4.1.4).
>
> If anybody has concrete actionable ideas on how to sweeten the bitter
> pill (short of "rollback the change"), we sure can consider it.
why not a extra property , "date" = isodate as it was (all old code can 
run it)
                                           "cdate" = new way

Greetz

Fernand
>