Created attachment 47152 [details]
Sample file to illustrate the bug
Using regularly BASE for my database management, I noticed that all of my radio buttons are unsuable. When I choose a feature, all the radio buttons are selected and the field assigned to the radio button is wipped out. (See attached fiel). Yet everything goes fine with the OOo 3.2.1 version.
This bug is quite annoying for me since many of my database files are unsusable.
Thanks to works over the issue.
Confirming behaviour in 3.4rc1. The grouped buttons appear to have an all or nothing selected status. However, the problem was also apparent for me in :
- OOo-dev 3.4m0
- OOo 3.2.1
- NeoOffice 3.2 patch 2
- NeoOffice 3.1.2 patch 8
- OOo 3.3.0
- LibreOffice 3.3.2
I seem to recall a report (possibly on a user mailing list) that a grouped control no longer allowed individual control of its sub-elements (in this case radio buttons, but I imagine tick boxes would be the same).
setting qa confirmed.
Setting platform OS to All. I tested on Mac.
In order to confirm that this is a regression, could you provide a copy of the ODB file where the radio buttons work properly for you and indicate with which version of OOo / LibO you opened it ?
I have the impression that when you opened the form in LibO, it resets the status of the controls such that they do not get read correctly when you try to open the form in an earlier version.
I tested on OOo 3.3 and OOo 3.4Beta1, and LibO 3.4RC1, on win7.
The LibO 3.4RC1 hide "Referencevalue on" property values, on properties Data tab.
If I open example file attached here, in any version of OOo and added referencevalues on Mr., Miss, Mrs. to radio buttons and saved it(not added any values to reference values off) , and opened in any orther bersion of OOo the values shows it.
If I open in LibO3.4RC1 the values not present, the property empty, close file reopen in OOo the values present.
I not have LibO 3.3.x I can not test it.
Tested on LibO 3.3.2 where it works as Zoltan has indicated, if the reference values are reset.
It also works on OOo-dev 3.4m0.
It fails on LibO 3.4rc1. When the form is opened the previously preset values of the radio buttons are no longer selected. If you select any one of the radio buttons, all of them get set to "ON".
This is a regression with regard to LibO 3.3.2.
It also causes data loss between versions. If a user opens the file in LibO 3.4, edits a record using the radion buttons, saves, quits and then re-opens in 3.3.2, the data is not written to the corresponding field.
Nominating as blocker for 3.4 release.
setting blocker status
Noel, could you please have a look?
Is there any workaround to restore the broken file with LO-3.3?
SURCOUF, Alex, Zoltan, could you please attach a working database file crated by LO-3.3 or OOo? It would help a lot with debugging.
Created attachment 47220 [details]
test odb where radio buttons work in LibO 3.3.2
@Petr : done
Not sure whether this is relevant to the problem, but the XML of the file content.xml pertaining to the form is the same in both test files, however one thing I did notice is that 2 of the buttons have localized names, whereas the third has an English name :
<form:radio form:name="Bouton radio 1" form:control-implementation="ooo:com.sun.star.form.component.RadioButton" xml:id="control9" form:id="control9" form:label="Mr." form:current-selected="true" form:visual-effect="flat" form:value="Mr." form:data-field="Civility" form:image-position="center">
<form:radio form:name="Bouton radio 2" form:control-implementation="ooo:com.sun.star.form.component.RadioButton" xml:id="control10" form:id="control10" form:label="Miss" form:visual-effect="flat" form:value="Miss" form:data-field="Civility" form:image-position="center">
<form:radio form:name="Option Button 1" form:control-implementation="ooo:com.sun.star.form.component.RadioButton" xml:id="control11" form:id="control11" form:label="Mrs." form:visual-effect="flat" form:value="Mrs." form:data-field="Civility" form:image-position="center">
So we have Bouton Radio 1, Bouton Radio 2 and then Option Button 1, which is a bit strange.
On further investigation, I notice that the data files within the two ODB are different :
The data file from "Test.odb" contains the following strings :
Hmm, seems my previous post got cut off :
On further investigation, I notice that the data files within the two ODB are
The data file from "Test.odb" contains the following strings :
Well something in the binary string of characters I wanted to post is causing FDO to baulk and chomp my posts, so forget it.
Suffice it to say that the DATA files of Test.odb and Test(3).odb are markedly different.
The estimation is that less than 1% of users is affected by this bug. We do not want to delay the 3.4.0 release because of it. Instead, we will warn users in the release notes => no blocker => slightly reducing the severity.
Noel is working on it and should have the fix soon. If it blocks your work, you will be able to use nightly builds after this bug is fixed.
Created attachment 47227 [details]
alternative test file that demonstrates the problem
I pretty certain that http://cgit.freedesktop.org/libreoffice/libs-core/commit/?id=ecbd796ee8157047b1738ac12c98a6ef4d3c18ff fixes the bug, it's an import problem where the referencevalue isn't read. I tested with the alternative file above and verified that is fixed, unfortunately the odb file doesn't even display the form ( with/without ) the patch in my 3.4 branch build ( most likely some build issue ). Marking as fixed, well if I'm wrong we can always re-open ;-)
indeed a build problem, works for me now
Created attachment 47242 [details]
Complet file created under LibO3.2.1
Here a BASE file created under LibO3.2.1
Created attachment 47337 [details]
version 2 of the patch
The send version of the fix has been committed as
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
Bug still there. Default 3D aspect but in feature popup window assigned as flat. When changed to 3D, flat aspect appears.
(In reply to comment #24)
> Bug still there. Default 3D aspect but in feature popup window assigned as
> flat. When changed to 3D, flat aspect appears.
This bug is about all radio buttons going on/off in lockstep (together) rather than exclusively (setting one unsets all others). The 3D/flat thing you mention is bug 40381 and/or bug 33557. Closing this bug again.