Bug 37590 - Radio button in BASE change state in lockstep instead of exclusively
Summary: Radio button in BASE change state in lockstep instead of exclusively
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected)
3.4.0 RC1
Hardware: x86-64 (AMD64) All
: high critical
Assignee: Noel Power
Keywords: regression
Depends on:
Reported: 2011-05-25 09:12 UTC by SURCOUF
Modified: 2012-02-09 08:24 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Sample file to illustrate the bug (12.19 KB, application/vnd.oasis.opendocument.database)
2011-05-25 09:12 UTC, SURCOUF
test odb where radio buttons work in LibO 3.3.2 (12.59 KB, application/vnd.sun.xml.base)
2011-05-27 03:02 UTC, Alex Thurgood
alternative test file that demonstrates the problem (7.57 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-05-27 06:04 UTC, Noel Power
Complet file created under LibO3.2.1 (16.80 KB, application/vnd.sun.xml.base)
2011-05-28 00:31 UTC, SURCOUF
version 2 of the patch (912 bytes, patch)
2011-05-30 12:38 UTC, Noel Power

Note You need to log in before you can comment on or make changes to this bug.
Description SURCOUF 2011-05-25 09:12:04 UTC
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.

Comment 1 Alex Thurgood 2011-05-26 01:35:49 UTC
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).

Comment 2 Alex Thurgood 2011-05-26 01:36:36 UTC
setting qa confirmed.

Comment 3 Alex Thurgood 2011-05-26 01:37:23 UTC
Setting platform OS to All. I tested on Mac.

Comment 4 Alex Thurgood 2011-05-26 01:56:32 UTC
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.

Comment 5 Zoltán Reizinger 2011-05-26 04:14:33 UTC
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.
Comment 6 Alex Thurgood 2011-05-26 07:35:12 UTC
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.

Comment 7 Alex Thurgood 2011-05-26 07:43:38 UTC
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.

Comment 8 Alex Thurgood 2011-05-26 08:14:12 UTC
setting blocker status
Comment 9 Petr Mladek 2011-05-27 02:44:01 UTC
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.
Comment 10 Alex Thurgood 2011-05-27 03:02:04 UTC
Created attachment 47220 [details]
test odb where radio buttons work in LibO 3.3.2
Comment 11 Alex Thurgood 2011-05-27 03:02:23 UTC
@Petr : done
Comment 12 Alex Thurgood 2011-05-27 03:43:12 UTC
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.

Comment 13 Alex Thurgood 2011-05-27 04:31:45 UTC
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 :

Comment 14 Alex Thurgood 2011-05-27 04:37:54 UTC
Hmm, seems my previous post got cut off :

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 :

Comment 15 Alex Thurgood 2011-05-27 04:40:49 UTC
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.

Comment 16 Petr Mladek 2011-05-27 05:24:52 UTC
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.
Comment 17 Noel Power 2011-05-27 06:04:33 UTC
Created attachment 47227 [details]
alternative test file that demonstrates the problem
Comment 18 Noel Power 2011-05-27 06:07:57 UTC
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 ;-)
Comment 19 Noel Power 2011-05-27 06:14:56 UTC
indeed a build problem, works for me now
Comment 20 SURCOUF 2011-05-28 00:31:10 UTC
Created attachment 47242 [details]
Complet file created under LibO3.2.1

Here a BASE file created under LibO3.2.1

Comment 21 Noel Power 2011-05-30 12:38:49 UTC
Created attachment 47337 [details]
version 2 of the patch
Comment 22 Petr Mladek 2011-06-09 02:57:30 UTC
The send version of the fix has been committed as 

Comment 23 Björn Michaelsen 2011-12-23 13:27:20 UTC
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.
Comment 24 SURCOUF 2011-12-24 11:55:05 UTC
Bug still there. Default 3D aspect but in feature popup window assigned as flat. When changed to 3D, flat aspect appears.
Comment 25 Lionel Elie Mamane 2012-02-09 08:24:19 UTC
(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.