Apache OpenOffice (AOO) Bugzilla – Issue 18683
regression: option buttons with different names handled as *one* group
Last modified: 2006-05-31 14:29:06 UTC
Hi, I have a problem with the behaviour of option buttons in a spreadsheet *since* OO 1.1 Example: (*) X_BTN01 ( ) Y_BTN01 ( ) X_BTN02 ( ) Y_BTN02 ( ) X_BTN03 ( ) Y_BTN03 All option buttons are connected to the "status changed" event. Selecting one of them will cause the following: e.g. Y_BTN02 is selected ... S0 5.2/OO 1.0.3 OO 1.1 -- event is fired for X_BTN01 (State = 0) event is fired for event is fired for Y_BTN02 (State = 1) X_BTN02 (State = 1) the result: (*) X_BTN01 ( ) Y_BTN01 ( ) X_BTN01 ( ) Y_BTN01 ( ) X_BTN02 (*) Y_BTN02 ( ) X_BTN02 (*) Y_BTN02 ( ) X_BTN03 ( ) Y_BTN03 ( ) X_BTN03 ( ) Y_BTN03 -> The basic routine is called twice in OO 1.1 ... -> In OO 1.0.3 I deselected the X_BTN01 manually in the basic routine, if X_BTN02 or X_BTN03 was selected ... but not when an Y_ options button was selected ... -> In OO 1.0.3 every single option button was a group for it's own ..., cause all had different names ... -> In OO 1.1 all option buttons are handled as *one* group, even if they have different names as shown above ... -> I can only prevent this behaviour, if i create a second set of (dummy) option buttons X_BTN01 - Y_BTN03 ... IMHO option buttons with *different* names should not be handled as one group ... Different names are necessary if you want to acess a single option button by name e.g. to disable it ... this seems not to be possible if buttons have same names ... regards Oliver
Oliver, can you please provide a document for easier reproducing this? (stripped to the very necessary controls/macros)
Oliver, if I understand you right, you talk about two problems here: 1. If a document contains a number of radio buttons which *all* have different names, then they are handled as *one* group (which definately is a bug) 2. You get *two* "item status changed" events for every selection of a radio button: For the one being de-selected, and the one being selected I could reproduce 1., but not 2. I remember we had a bug for 2., but this has been fixed in the meantime (don't find the number currently, but could look ... ) Thus: - can you please provide a bug doc for 2. (better: for 1. combined with 2.) - which version are you using exactly (go to Help|About, press S, D, T while holding down the Ctrl-key, and write down the line appearing immediately below the button)
Created attachment 8779 [details] document for reproducing problem 1.
Hi Frank, thanks for the quick answer :-) I first noticed this behaviour on a w2k system with - OO 1.1 644 build 8600 - SO 6.1 beta 2 644m13s2 build 8609 (don't know if this happens in the beta1 too) I can not reproduce it on my knoppix system with OO 1.0.3 (641 build 8584) ... I agree with you, that the first is a bug. Radio buttons with different names should - under no circumstances - be handled as one group. I had a look at your attachment and I saw actually two events with OO 1.1 and SO 6.1beta2: -> one for deselecting the old, -> the second for selecting the new radio button .. log: x_01: not selected y_03: selected I think, this would be ok, if this would happen only inside a group (buttons with the same name). In OO 1.0.3 and SO 5.2 I get only a y_03: selected HTH best regards Oliver
Okay, so you're encountering 2. in 1.1 Beta2 - indeed we had this bug there, but it's fixed in 1.1RC3 (I think already in RC1), because it simply is a difference to the old behaviour which is not expected to change (though it may be argueable which behaviour does make more sense). So what's left here is 1.: In a document with n radio buttons all having a different name, the radios are treated as *one* group instead of *n* groups. changing the summary to better (a little bit) reflect this. I confirm and grab this issue then. In agreement with msc, I target it for 1.1.1, since it's a regression compared to 1.0.x.
now really targeting, and accepting
fixed in CWS dba01pp1 Since the radio buttons are often subject to breakage, I added an integration test to forms/qa, which checks for most cases which we had trouble with so far. fs->msc: The fix which caused this bug here was for #107014# (internal tracking system). I already checked that I didn't re-introduce #107014#, but you might want to do this, too, when you verify this bug here.
fs->msc: please verify in CWS dba01pp1. Thanks :)
fixed
verified in dba01pp1
Hi, this will be fixed in OOo 1.1.1 which will be available soon. I close this issue now as fixed. bye Marc
change subcomponent to 'none'