On 26/11/2013 17:42, Lionel Elie Mamane wrote:
On Tue, Nov 26, 2013 at 02:36:41PM +0100, Fernand Vanrie wrote:
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,
why not a extra property , "date" = isodate as it was (all old code
can run it)
"cdate" = new way
That's essentially a variant of "roll back the change".
1) This requires an incompatible change again; 4.2 would be
incompatible with 4.1.
is suppose that there is not a lot off API-basic code around for 4.2 :-)
2) Applied to Time, it leaves the problem of round-tripping.
3) If we set DataFieldProperty to the name of the new
(pseudo?)property (UnoDate? DateAsUNO? StructDate?), the other
problems I'm thinking about should go OK, except that indirect
access through DataFieldProperty will still be incompatible, but
that should be minor?
Go for it, then we can go for 4.1.
If not: then please let it know, we can start changing the code using a
conversion
Greetz
Fernand
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
