Created attachment 118240 [details] demonstration database: See Form1 and Macro 1 .In Base, you have a form, we'll call Form1. See demo attachment for reproducing. 2. There are two defining characteristics of Form1: a.) it has an entry in the Filter property for MainForm and b.) it has a date/time field. 3. Open Form1 4. Navigate beyond the last row of data in Form1 to the Insert Row. 5. Type Something in the bottom-most field (a text field) 6. Press the save record button or navigate back to the first row UNEXPECTED RESULT: the date field at the top has gone from the desired NULL/EMPTY input to a zero date which in this case is 1/1/1800. Alternately, you can reproduce using the macro saved in the database which does the same thing, basically. The 0-date 1/1/1800 is persistent in the Form1 recordset until it is closed (no matter if you navigate to other records) but it is not saved to the table. The workaround is to delete the filter on the form. However, that is a non-obvious workaround because why would there be a connection between the way the date is displayed and the existence of a filter on another field....
Using LO 5.0.1.1 on Linux OpenSuse 13.2 KDE. Also reproduced on Windows 7 64-bit LO 5.0.0.5 and LO 4.5. I think this has been a problem going back through many versions.
Confirming on OSX 10.10.5 with Version: 4.1.4.2 Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72 I also see that default date entry flash briefly on screen when switching from one record set containing a still empty date field to the next record containing the automatically displayed default date.
The form appears to behave correctly in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 see attached screenshot ==>> regression
Created attachment 118241 [details] Correct display of values in LO330
To re-situate the context, that default 00/00/0000 displayed value was always the way that OpenOffice.org displayed null date values in forms, in which case, if I am to understsand Doug's comments correctly, even this would be incorrect for him, as he wants a completely blank control. As I recall, the zero date display was a much griped about "feature" of previous versions of OpenOffice.org, the only difference between then and now being that the controm field displays the default date of LibreOffice as the null date, i.e. 1/1/1800 as defined in Calc (go figure). So, the regression I refer to is not in the problem of the actually displaying a null value per se, but the fact that the previous zeroed out "00/00/0000" display now shows Calc's default date setting instead.
Yes, I would like the blank date control before the InsertRow method to stay blank after the InsertRow method is executed. No reason why the InsertRow method should change the appearance or value of the date control in this situation. This is a bug for me because the zero date behavior is inconsistent, both with the way the form works when there is no filter, and inconsistent with the value actually reported back to the table. If you close and open the form again and browse back to the same record the date will be reported correctly as null, even though when it was recorded LO said it was a zero date. So if this was a limitation of how LO or OO works, that would be one thing, but instead it just seems like an anomaly.
The functionality also was impervious to changing ODBC settings on a MySQL back-end to report zero-dates as null. Proper functionality would have been responsive to that option.
Have tested it with LO 3.5.7.2 - the same bug: the field should be empty, but shows a date 1/1/1800. Same behavior in date/time and date-fields. So I set this version to 3.5.7.2 - the oldest version I have tested. My system: OpenSUSE 13.2 64bit rpm Linux.
The bug, meaning that the added record shows date 1800-01-01 upon redisplay, is already present in the earliest bibisect version that I can find for Linux, bibisect_linux_x86_64_lo35_and_later version oldest, which identifies itself as LibreOffice 3.5.0 Build ID: d6cde02 I am setting version in this report to 3.5.0 release. So far as I know, this leaves OS/X as the only plausible way go further with bibisect. I once thought I could fix the form definition to give much better results using daily dbgutil bibisect version 2015-08-28, but now I cannot do it again. I think I have to give up for now.
This happens only if the current filter does not match the newly inserted record. In the attachment 118240 [details], since the filter is "text 1 = 't'", this bug does not appear if the new record has value 't' in text1.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=11ce80e1e7085e2073850056e47e4e997905d286&h=libreoffice-5-0 tdf#93724 KeySet insert: properly set default values: NULL & right type It will be available in 5.0.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Migrating Whiteboard tags to Keywords: (bibisectRequest) [NinjaEdit]