Description: >Spinoff from ticket bug_138387 definition of "default" value in controlfields: a.) if you would like to have "0" (zero) as default value, you first have to define for example "1" and then change to zero. If you try to enter "0" directly, it is interpreted as "empty" (NULL?) b.) the other way round is also a problem: it is not possible to change the default value to empty/NULL. You have to delete the control and add it from scratch Steps to Reproduce: 1. self explaining 2. 3. Actual Results: in numeric control fields you can not define "0" (zero) directly. You have to define i.e. "1" first and can define "0" then. Once you have defined a "non NULL" default value, it is not possible to set the default to "NULL" again. Can be necessary, if the table behind itself has rules for defaults. Actually this is only possible by deleting the control field and recreate it. Expected Results: Mainly resetting to NULL should be possible Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 7.1.0.0.alpha1+ Build ID: 312a33b7636334f6ce3b6d1702bc5d3e45215601 CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: de-AT (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-11-17_01:31:31 Calc: threaded Graphics: Device-1: VMware SVGA II Adapter driver: vmwgfx v: 2.18.0.0 bus ID: 00:02.0 chip ID: 15ad:0405 Display: x11 server: X.Org 1.20.8 driver: vmware unloaded: fbdev,modesetting,vesa resolution: 1920x1014~60Hz OpenGL: renderer: SVGA3D; build v: 2.1 Mesa 20.0.8 direct render: Yes
Created attachment 167470 [details] test file On pc Debian x86-64 with master sources + gtk3 updated today, I don't reproduce this. Here are the steps I did: - launch attached file - edit Tasks form - ungroup taskId part - select Formatted field at right - type "0" in default value - close window => 0 appears as default value - select again Formatted field at right - remove "0" in default value - close window => 0 disappears as default value
Have tested with different versions of LO: LO 6.4.6.2 - no problems. Could set the default to '0' directly. Is also shown in the field. Could reset it to NULL without any problem. Then opened with LO 7.0.3.1. Looked at the fields and saw in the properties the default '0', but isn't shown in the field of the form (VCL: gtk3). With VCL: kf5 the default is empty, but I couldn't set it to '0'. I couldn't set it to any value. The default for GUI in the form could only be set for Text controls, not for numbers and also not for dates. There will appear a default for dates in the properties, but it won't be used in the form. Very buggy with LO 7.0.3.1! Then I tried it with LO 7.1.0.0 alpha 1+ (2020-11-13). There the behavior is the same as reported: You couldn't write down '0' directly. You have to choose '1' and then go back to '0'. And: You couldn't set it back to NULL. Then with LO 7.1.0.0 alpha 1+ (2020-11-21). Same as with LO 6.4.6.2: No buggy behavior. Seems the bug is gone. Tested all with OpenSUSE 15.1 64bit rpm Linux.
(In reply to Robert Großkopf from comment #2) I confirm - the bug is gone in Version: 7.1.0.0.alpha1+ Build ID: 4486ab59348ddbfa4b050195477c2842c0a7de0a CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: de-AT (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-11-21_13:22:04 Calc: threaded
Thank you Richard for your feedback. The good news is, it'll be ok for future 7.1.0. (master has corresponded since today to future 7.2.0). (see https://wiki.documentfoundation.org/ReleasePlan/7.1) Now, there are still some versions to come on 7.0 branch where there's the pb (see https://wiki.documentfoundation.org/ReleasePlan/7.0) About, 6.4, let's forget it since it's almost EOL. Should we put this one to WFM do you prefer the bugtracker stays opened for the moment? (I've got no strong opinion here).
(In reply to Julien Nabet from comment #4) I guess, wasting time for solved problems in the next release should be avoided. There are workarounds for this weaknesses. I would agree, if you put this ticket to WFM. thank you
Let's put WFM then
Have described the buggy behavior in LO 7.0.3.1 as new bug 138416 .