https://bugs.freedesktop.org/show_bug.cgi?id=68751
Lionel Elie Mamane <lio...@mamane.lu> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |NOTABUG
--- Comment #2 from Lionel Elie Mamane <lio...@mamane.lu> ---
(In reply to comment #0)
> I think this is because the Date attribute is now not a simple
> attribute but contains Day, Month and Year.
Yes, the type of the property changed from 32-bit integer to
struct ::com::sun::star::util::Date
(http://api.libreoffice.org/docs/common/ref/com/sun/star/util/Date.html)
The latter is the "standard" type for dates in LibreOffice. This change
allows to do stuff like:
aRecordSet.updateDate(5, aDateControl.Date);
if aRecordSet.getDate(5) = aDateControl.Date then
....
end if
while before one would have had to do more awkward stuff like:
Dim aDate as new com.sun.star.util.Date
aDate.Year = aDateControl.Date / 10000
aDate.Month = aDateControl.Date / 100 - Date.Year * 100
aDate.Day = aDateControl.Date - Date.Year * 10000 - Date.Month * 100
aRecordSet,updateDate(5, aDate)
Alas, with UNO properties, it is not possible to do autosniffing
stuff like "if I get an integer, then understand it that way,
but if I get a struct :com::sun::star::util::Date then interpret
it that way", the way the ::com::sun::star::form::binding::XValueBinding
interface does. The UNO framework just does not have this feature.
To set the control, you can do something like:
Dim aDate as new com.sun.star.util.Date
aDate.Year = 2013
aDate.Month = 5
aDate.Day = 3
aDateControl.Date = aDate
To have exactly the same code execute in different LibreOffice versions, you
could also use the XValueBinding interface
http://api.libreoffice.org/docs/common/ref/com/sun/star/form/binding/XValueBinding.html
If I remember well, we kept backwards compatibility in this one
(because it was possible).
> This is a pretty significant change for a minor release (4.1.1).
Yes. It should have been done for 4.1.0, but was overlooked. We
deeply regret that we had to do it in a minor (patchlevel) release.
See bug 67235 for details. Because of bug 67235, we had to change
the Time property of Time controls incompatibly anyway. So we made
the "big jump" and changed from integer to com.sun.star.util.Time.
(We could have left it compatible, but then it would break fairly
basic assumptions like the fact that
aTimeControl.Time = aTimeControl.Time
does not change the value.
Due to the introduction of nanoesecond precision (in place of
"only" centiseconds, if the control contains milli / micro /
nanoseconds, they would have disappeared by the above code.)
Changing Date controls was not strictly necessaary, but we changed
them at the same time for coherence reasons.
> will the behaviour in 4.1.1 carry on for all future versions?
That's the plan, yes. Using a structured date (instead of a
"weirdly encoded integer") precisely brings more "wiggle room"
for future evolution without changing the API. If the time
(and date) controls had used the structures, then we would
NOT have had to change the Time and Date properties at the time
of the nanosecond precision change.
So (somewhat whacky example), e.g., if in 15 years "the world"
switches to a different calendar system, and the structured
date format is changed to accomodate the new calendar... no
need to change the DateControl Date property.
I'm marking that as "NOTABUG"; that's the closest status I can find; a better
wording for this particular case would be "BYDESIGN" or something like that.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
