I've got a set of statebuttons in my xamribbon spread out across various tabs, all belonging to the same group. When I click on individual statebuttons they behave as expected, toggling their checked states on and off accordingly.
However, when I have a statebutton selected then switch tabs to select another statebutton, then switch tabs back again, the button I last selected on the first tab is still highlighted. It appears that the button highlighting remains in the context of each tab.
Functionally it still works: clicking on any button whether appearing as checked still re-selects it accordingly. It's just that it's misleading because I may not be on whatever button that is currently displaying as selected.
Is there any way to solve this?
Hello borong,
Thank you for your post!
I have been looking into it and have created a small sample application for you. In the sample application I have handled the RibbonTabItemSelected event. In the handler of the event I am getting the RadioButtonTools, that are in the different tabs of the XamRibbon. Then I check the name of the group of the RadioButtonTool and set the IsChecked property of the Tool.
This way you can uncheck the radio button. You can set your desired checks when the RadioButton should be checked/unchecked when the user switches the tab of the XamRibbon.
Please find the attached sample application and feel free to let me know if you have any further questions on this matter.
Hi Gergana:
Thanks for the quick reply. I've tried your solution but it results in the selected button being lost wherever i switch to, even the genuine button.
I've modified it a little to work based on the scenario that if my new and previous selected ribbon tab item both contain a selected button I would deselect the one in the new tab item (assuming that the one I just left contains the button I most recently selected), but that kinda falls apart if I have more than two tabs. It's better than nothing though, and I think it can be refined further to get what I need.
Still, this comes across as being quite hacky for what feels like an expected behavior and it isn't MVVM. Is there a way to address this in a following release?