How to prevent auto-selection of radio buttons

Question

When adding an instance of the Gtk# RadioButton class to a GUI, it is automatically checked ("activated") as the first member of its radio button group.

For Gtk, this has been discussed to some extent in another question, with the main point of the selected answer being that users expect one radio button to be selected at all times.

I do not dispute that.

However, I am automatically generating my user interface in a way so each radio button is linked to a data model, but none of the radio buttons can, at any time, get a reference to any of the other RadioButton instances. The data model ensures that one radio button is checked at all times.

Beside being sufficient to match user expectations, I consider this good practice, as like this, data integrity is ensured by the data model, not by the GUI.

Unfortunately, Gtk# will automatically check all radio buttons like this, as it considers each radio button to be the first in its group. For adding the various radio buttons to the same group, I would have to pass the first radio button in the group to the constructor of the other radio buttons - which I cannot, as pointed out above, as I do not have any way to get the reference to that first radio button when instantiating the others.

Setting the Active property of the radio button to false does not help, nor does invoking the Toggle method.

Is there any way to suppress this automatical selection, possibly by subclassing and overriding something I could not find yet? Alternatively, is it somehow possible to force a CheckButton to look like a radio button for this purpose?

If there is really no other solution, I will try and implement the solution suggested in another answer that involves adding a second hidden radio button for each of my radio buttons, but I would find that extremely hacky for production code.

Garboil

why can't you just loop the radio buttons and uncheck them all? using gtk_toggle_button_set_active () that is inherited from GtkToggleButton.... – Spreadeagle

@ymz: Because the buttons do not seem to accept that value. They make sure that at least one button per group remains checked. – Garboil

i usually won't suggest this (as the official docs) but... gtk_toggle_button_toggled may do the trick – Spreadeagle

@ymz: Well, RadioButton has a Toggle() method, which seems to be the same thing, but it doesn't yield any visible result. Probably, the RadioButton automatically reestablishes its state. – Garboil

Would it work for you, if you were to create that group only after the UI is created? You could observe your UI and get that radio button. Now, I don't have gtk# experience so it's just a suggestion. – Thumbsdown

@Messer: Unfortunately not. All widgets are generated by factories based upon an abstract description. (That is also why the radio buttons have no knowledge of one another; each factory generates a single widget that will only afterwards be inserted into the complete window hierarchy by the calling code.) There is no post-processing step where the factories could modify the generated widgets after they have become part of the window hierarchy (and outside of the factories, code must remain agnostic to the type of the widgets created). – Garboil

"inserted into the complete window hierarchy by the CALLING CODE" - so can't you create such a group within this calling code and then add all buttons to it while inserting them into the hierarchy? – Toname

@Aconcagua: The calling code does not know what is being created. Ideally, it does not even know that a type RadioButtonexists, it just knows the abstract widget base class. That's the point of the abstract factory pattern. – Garboil

And the parent widget itself does not know anything about it's children eigher, does it? Do you have any control over the abstract description? Idea would be to create an intermediate widget getting all the buttons and inserting them into a group internally... – Toname

@Aconcagua: Indeed, the parent widget is created by a factory itself (and after all, it's not even guaranteed all radio buttons in one group are directly within the same parent widget). From the point of view of the abstract description, the radio button descriptions are self-organizing and are all that's needed to maintain a valid state. A requirement to add any additional information to the abstract description would seem ... redundant. – Garboil

Well, apparently you need some way to group the buttons together... Could you assign group ids by some means? Either by parametrizing the factory appropriately or by getting the ids from your data model? Then you could use a std::map<unsigned int, std::vector<RadioButton>> (or multimap, if you prefer) for keeping track of all buttons. Probably within the factory... – Toname

@Aconcagua: I'd need some kind of a global map then, as the factories are instantiated on demand based upon the information from the model. Still, I'm not sure how to do that, as Gtk# widgets can be generated from a given model several times in parallel. I.e. for each group of n radio buttons from the model, there could be m Gtk# representations of each of the n buttons. Hence, I would have to keep track of which Gtk# radio button is part of which model representation somehow. – Garboil

@O.R.Mapper you could use toggle buttons and only allow one to be toggled at a time not the best but it should work easily. – Grimbald

Answer 1

Extension to Josip's solution: Create your own radio button widget, actually containing nothing else than two gtk radio buttons, one of which always is hidden. Your factory then creates this one instead of the original gtk button...

Toname

While this is still hacky, it at least nicely encapsulates the hackiness into one enclosed component. So, for lack of any better answers, I will accept this one. – Garboil

Answer 2

Radio buttons are similar to check buttons except they are grouped so that only one may be selected/depressed at a time.

They require a group to perform their duty properly.

Try the solution from the down, it's not so hacky, just try to add one hidden radio button that is always selected.

Septum

This may be a matter of personal interpretation, but I really doubt saying "it's not so hacky" makes using a widget that is always hidden any less hacky ;) – Garboil

True that. But if there's no other solution... do it like this. ;) – Septum

Ugly/dirty solution - but actually wanted to propose the same as not having any better idea either... Hopefully there is not too much data to be represented... – Toname