Re: Vendors Name via UNO API / Basic Macros

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.

-- 
Lionel