In 4.1.1 I can now find no way to set a default date value in Basic.  The DefaultDate attribute suffers from the same problem as the Date attribute, but there's no equivalent that I can find of the Text value to to set it indirectly.

(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.

Thanks for your comprehensive answer.  I hope that not too many people get stuck on this.  

I failed to find any release notes that warned me of this impending change.  It took me a long time to figure out what was going wrong (the Basic error message was not exactly helpful) since I normally assume I've done something stupid, until I realised that maybe it was due to an LO bug or change.  I was also a bit frantic since my Ubuntu LO 4.1 ppa wouldn't let me go back to 4.1.0 (I'd have had to download it from the web and then get stuck with MySql(Native) problems).

I'd never have guessed how to use the com.sun.star.util.Date type, so thanks for that.  

I'm glad to read we are now resistant to calendar changes, even if over-run by aliens with a different system.

(In reply to comment #3)

> I failed to find any release notes that warned me of this impending change.

Good point. Added to https://wiki.documentfoundation.org/ReleaseNotes/4.1#Changes_to_UNO_APIs

> (the Basic error message was not exactly helpful)

Yes, I agree. That's (half of) bug 40144.

> I was also a bit frantic since my Ubuntu LO 4.1 ppa wouldn't let me go back
> to 4.1.0

If you use aptitude as front-end, then the installation files (.debs) for
everything you ever installed in the past are in /var/cache/apt/archives/
until you empty the cache (from the aptitude menu). Doesn't make it
particularly easy to use them, though.

Maybe Ubuntu has a service similar to snapshot.debian.org that archives
past versions? Dunno.

> I'd never have guessed how to use the com.sun.star.util.Date type, so thanks
> for that.

Star Basic is annoying with structures... Actually, since bug 42819 and bug 47263 are fixed (I forgot they were...), you could try:

aDateControl.Date.Year = 2013
aDateControl.Date.Month = 5
aDateControl.Date.Day = 3

If it does not work, I'll make it a new Basic bug report / enhancement request.

Note, however, that this is not strictly equivalent to my previous example. E.g. if the current value of the control is 2012-10-30, and DateMax is 2013-06-30, then the above will fail. This

aDateControl.Date.Day = 3
aDateControl.Date.Month = 5
aDateControl.Date.Year = 2013

will succeed in this case, but fail if DateMin is 2012-10-15...

Thanks for that.

When I found the structure existed (by entering a date in the form and seeing what the attribute contained using the IDE) I saw that it contained Year, Month and Day.  I then tried setting these in Basic but it failed.

What seemed to happen is that until the Structure has been initialised in some way you can't just set the individual attributes. So oControl.Date.Year = 2013 fails unless the control has been initialised (eg by entering data manually in the form).  However, setting the Date control to a local struct does work (ie oControl.Date = dDate where dDate is a com.sun.star.util.Date struct), and from then on the Year, Month etc can be set individually.  Odd.

Anyway, I think I have found & fixed all my date & time code now for this, so not too much of a problem :-)

(In reply to comment #5)

> What seemed to happen is that until the Structure has been initialised in
> some way you can't just set the individual attributes. So oControl.Date.Year
> = 2013 fails unless the control has been initialised (eg by entering data
> manually in the form).

Yes, the structure is probably initialised to 0000-00-00; so when trying
to set the year, one tries to set the date to 2013-00-00, which is not a
valid date and gets rejected.

It is the same problem than what I described with respecting DateMin and
DateMax at all times. I expect the same to happen e.g.:

 - when Date is 2013-03-31, set oControl.Date.Month = 2
   (because there is not 31st February)
 - when Date is 2013-02-15, set oControl.Date.Day = 31
   (because there is not 31st February)

Thanks.

It is just as well you give such great support.  I find the UNO documentation almost incomprehensible - there's too much terminology and structure I don't know (and don't need to know most of the time).  So although http://api.libreoffice.org/docs/common/ref/com/sun/star/form/binding/XValueBinding.html might help if I was building a product and needed compatibility across versions, frankly I've no idea how.  

But never mind - I'm happy with it all working now.  I did previously struggle with the time format.  The date was OK as an ISO yyyymmdd (which I use anyway elsewhere), but I can see the advantages of using proper structures for both

This just cost me two or three [profanity resisted] hours. Please document changes that will break code in a prominent and appropriate place (this change is not mentioned in the API reference at http://api.libreoffice.org/docs/common/ref/com/sun/star/awt/XDateField.html). And would it have been *so* much extra work to provide CDateToDateStruct and CDateFromDateStruct functions?

(In reply to comment #8)
> This just cost me two or three [profanity resisted] hours. Please document
> changes that will break code in a prominent and appropriate place

Like https://wiki.documentfoundation.org/ReleaseNotes/4.1#Changes_to_UNO_APIs ?

> (this change is not mentioned in the API reference at
> http://api.libreoffice.org/docs/common/ref/com/sun/star/awt/XDateField.html).

It is mentioned in the API reference of the SDK version 4.1.1. Downloadable from the same place as LibreOffice itself, i.e. your distribution's package repository or http://www.libreoffice.org/download/ (click "Software development kit (SDK)").

The on-line one apparently is from an older version... Good point. I'm going to find out how to get it updated.

> And would it have been *so* much extra work to provide CDateToDateStruct and
> CDateFromDateStruct functions?

Not sure what you mean. Amount of work depends on what they are supposed to do, where they are supposed to be available (Java, Python, Basic, all of them, ...), ... From the name "CDateToDateStruct" my guess is that you expect them to convert from a C Date to a UNO Date; except that I don't know of a standard C date type, so maybe you mean the OS-specific type? E.g. "struct tm" on Unix? LibreOffice uses such functions internally in its C++ code, so we could consider exporting them in the SDK for C/C++ extensions to use... Is that what you mean?

(In reply to comment #9)
> > please document
> > changes that will break code in a prominent and appropriate place
> 
> Like
> https://wiki.documentfoundation.org/ReleaseNotes/4.1#Changes_to_UNO_APIs ?
> 
Not really. For that to be any use I'd need to know the problem was due to the latest upgrade. I ran into it when changing from OpenOffice. (Having fixed my spreadsheet for LibreOffice, it is now unusable on another computer with OpenOffice). Rather than reading the entire change history of LibreOffice since it forked, I looked for documentation of the current version. I suspect this is a normal response.

> The on-line one apparently is from an older version... Good point. I'm going
> to find out how to get it updated.
> 
Doing that automatically would be a very good idea. As would having older versions available for those behind the bleeding edge. If I were actively developing solutions it might make sense to have the SDK installed, but this had been stable functioning code since 2007.

> > And would it have been *so* much extra work to provide CDateToDateStruct and
> > CDateFromDateStruct functions?
> 
> Not sure what you mean.
>
Sorry, I'm using the built-in BASIC, which has CDateToISO and CDateFromISO functions for convenience in cases like this used to be.

(In reply to comment #10)
> (In reply to comment #9)
>>> please document
>>> changes that will break code in a prominent and appropriate place

>> Like
>> https://wiki.documentfoundation.org/ReleaseNotes/4.1#Changes_to_UNO_APIs ?

> Not really. For that to be any use I'd need to know the problem was due to
> the latest upgrade. I ran into it when changing from OpenOffice. (Having
> fixed my spreadsheet for LibreOffice, it is now unusable on another computer
> with OpenOffice). Rather than reading the entire change history of
> LibreOffice since it forked, I looked for documentation of the current
> version. I suspect this is a normal response.

The documentation of the "current version" contains/contained the change.
The documentation on the website was outdated... So, unless you have another
specific suggestion, I'll consider that part closed since the documentation
on the website is updated now.

>> The on-line one apparently is from an older version... Good point. I'm going
>> to find out how to get it updated.

> Doing that automatically would be a very good idea. As would having older
> versions available for those behind the bleeding edge.

I agree. I started the internal discussions to make that happen:
http://lists.freedesktop.org/archives/libreoffice/2013-September/055741.html
http://lists.freedesktop.org/archives/libreoffice/2013-September/055740.html

>>> And would it have been *so* much extra work to provide CDateToDateStruct and
>>> CDateFromDateStruct functions?

>> Not sure what you mean.

> Sorry, I'm using the built-in BASIC, which has CDateToISO and CDateFromISO
> functions for convenience in cases like this used to be.

I see. I added the equivalents to/from the UNO structs as:

CDate(From|To)Uno(Date|Time|DateTime)

for LibreOffice 4.2 and 4.1.3

(In reply to comment #11)
With that I think I can consider my whinge to have been considered, understood, taken seriously and (at least in principle) dealt with. Thank-you.

As someone who struggles with much of the documentation surrounding UNO (so much so that I have almost given up on it), will the new routines be described in the LO Basic Help?  

The only way I have ever learned anything much about LO programming for Base is from the Help, occasional forum posts, and documents such as Andrew Pitonyak's guide from 2009.

I have noticed that the Help in some areas lags behind current releases by some margin (Draw for instance), and wonder whether there is a rigorous process for updating it when changes or additions are made.  Will CDateToUnoDate etc (if I have interpreted your syntax correctly) be documented there?  If not, where would I find it when I need it?

(In reply to comment #13)
> As someone who struggles with much of the documentation surrounding UNO (so
> much so that I have almost given up on it), will the new routines be
> described in the LO Basic Help?

If I can someone to review my patch to the Help... it is at https://gerrit.libreoffice.org/5945

But that's just adding them to the index of all Basic functions and creating a documentation page about each of them. If you have any suggestion of another help page where they should be mentioned, feel free to suggest.

Thanks.  I'm very glad to hear that the Help has been updated - I wasn't really sure whether the addition of these functions would be included.

I'll review and post any comments when I get to install 4.1.3, and I'll give a couple of them a whirl in place of my more pedestrian processing.  


I was quite lucky with this change in that I had determined a while ago that all functions to do with setting/reading form control values (and default values) should take place in a dedicated set of 4 subroutines.  I didn't have to make too many changes to sort it out, and won't need to do much to test these new ones.

I have just downloaded 4.1.3.2 for ubuntu 64 bit 12.04.

At first test the UNO conversion routines work fine (as expected).

I don't, however, find anything about them in the Help.  Help!

I tried the en-US help, and the online help at https://help.libreoffice.org/Basic/Converting_Date_Values.  I can't find anything on CDateTo/FromUNO...

(In reply to comment #16)

> (...) UNO conversion routines (...)
 
> I don't, however, find anything about them in the Help.  Help!

Menu Help / LibreOffice Help

Tab "contents", under "Macros and Programming" / "Command Reference" / "Alphabetic List of Functions, Statements, and Operators", they are in the list. But if one double-clicks in the entry, the right pane becomes blank. I added the help files for the new functions, and added them to this alphabetic list, but forgot to mark the new help files for installation. Fixed now (so for LibreOffice 4.1.4).

(In reply to comment #17)
> I tried the en-US help, and the online help at
> https://help.libreoffice.org/Basic/Converting_Date_Values.

I was not aware of that help page. I added them there and also in the sister page "Converting Time Values". Again will be for 4.1.4.

OK - I can see them in that list.  

They aren't in the main index (CdateFromIso is) nor can be found using the Find tab.

I had some additional confusion because the ubuntu distribution doesn't include the latest GB help file, only the US one, and I was therefore looking in the 4.1.1. file.  I have updated to the US one for 4.1.3.

(In reply to comment #19)

> They aren't in the main index (CdateFromIso is) nor can be found using the
> Find tab.

Just tested, and this is fixed in master and (pending review) in LibreOffice 4.1.4, by the same fix as alluded to comment 18 (that is, mark the files for installation). Thanks for checking though, it might have required another fix.

I have installed 4.2.0.0 beta1 in parallel with 4.1.3.

I installed the language pack and help, but pressing F1 or using the menu, always takes me to the website, not the installed help.  I have no idea why.

The website doesn't seem to have your changes, but then it doesn't seem to cater for different LO versions as far as I can tell (the link I have is https://help.libreoffice.org/swriter/.uno:HelpIndex?Language=en-GB&System=UNIX&Version=4.2#bm_id3149178).  It's also somewhat difficult to use.

So unless you have any ideas I'll have to await an ubuntu ppa with 4.1.4 or 4.2 before reading your revisions.

I have tested the date/time help in 4.1.4.2 (downlaoded in parallel with my ubuntu 4.1.3).  All OK.  Thanks.

*** Bug 80425 has been marked as a duplicate of this bug. ***