I can’t quite picture what you want to do, but maybe you could call stopImmediatePropagation on some of the lower level mouse events in a high priority event listener.
Hi,thanks for the reply. Actually that was my third option, but not sure if it's very good also..
Here is a simple scenario:
User must select between 2 radio buttons:
1) no volume -> sets variable volume=0 and selects the radio button (that is the normal use case)
2) set volume -> opens up a pop up with a list that has a X button to close and 4 options: 25% volume, 50% volume, 75%, 100%
At this point the set volume radio button should not be selected and the user has 2 choices:
-> hit the X button to close - nothing changes and no volume radio button is still selected and volume is still = 0
-> hit one of the volume % buttons -> the set volume radio button gets selected and the variable volume=25/50/75/100 depending on the button selected by the user.
That's a pretty common scenario and it's bugging me that I can't easily alter the radio button selection logic since whenever I click it, it gets selected and I can't put a logic in between in a standard way. This should apply to any component with selection, just like ButtonBar has it with the Changing event.
So is there any other more convenient way to accomplish this scenario that you could recommend?
I think it depends on the details. I don’t see why it would be so bad to let the second radio button get selected, show the popup then change radio buttons based on the outcome of the popup. Although I’m not sure why you can’t use a slider and mute button instead.
It was just an example, I have a simmilar case right now and it's not me who invents how things should work... it is designed like this cause there is not much space to put all the radio buttons and the data they carry is different not like volume, that's why they group them like that. And also one of the radio buttons has a hint under it, which should show at the same time the radio button is selected but at that time nothing is yet selected from the pop up to fill that hint box with...
And yes what I did right now is what you just suggested.. I select the radio button when clicked and then deselect it depending on the outcome and yeah in this case I guess it's harmless, but as a user interaction and feedback the radio button should not go selected and deselected back and forth unless it stays that way and since the selected process has not been finished it should not be marked as selected upfront. And second sometimes successful selection of a radio button would immediately activate showing next screen for example and in this case I would have to write more complicated logic for some radio buttons to not show the next screen on selection and move that logic in the pop up they open.
I am not trying to argue with you, just trying to prove a point here so maybe you could tell me if it's ok to fill an enhancement request for this... thanks!
Oh and one more thing. Since there are 2 ways to use groups with radio buttons: group and groupName properties. groupName is ok, but group is not acting as expected either - There is Change event for the RadioButtonGroup but it's not an IndexChangeEvent like the List or the ButtonBar -> I was expecting the same logic with Change and Changing events and newIndex and oldIndex stuff... I'm surprized it's not the same since in a way it's a simplier version of them and I think it would be better if you could mimic that if it's possible - this would standardize the way groups/lists work which is always good. Currently I ended up using ItemClickEvent.ITEM_CLICK which at least gives me the new item selected, cuz otherwise with Change event I have to RadioButtonGroup(event.target).selection to get it -> definitely not the way I am used to write logic for Lists and ButtonBars.
So I would like to make an enhancement requests for these 2 things...
Message was edited by: FM_Flame
You are always welcome to file an enhancement request.