I answer this part of your question:
How do I eliminate the need for 2x clicking on the radio buttons?
You can add the following event handler to the Click event of each of the three RadioButtons (of which the Checked properties are bound to Application Settings) in your GroupBox:
Private Sub RadioButton_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles tomRadioButton.Click, dickRadioButton.Click, harryRadioButton.Click
If sender.Checked = False Then
sender.Checked = True
End If
End Sub
It works, even though it takes a half-second for an unckecked RadioButton to be checked after you click it.
The reason for the problem was explained two years ago (in 2008) in section 5 of the Surviving WinForms Databinding post on the Turbulent Intelect blog (Thank you, ohadsc, for the link):
Rule 5: Don't bind to clickable Radio Buttons
I know how great it would be if you
could just bind your bunch of radio
buttons to an enum property. I really
do. You think you're just going to
hook up some Format and Parse events
to translate back to your enum, and
all will be well. It would be so darn
convenient, if it actually worked. But
WinForms just isn't cut out for this.
For 3 full releases now (or is it 3.5
releases?), this has been the case.
It's because of the event order, which
is not something that MS can go
switching up without causing thousands
of developers to get really cheesed
off.
The problem really comes down to the
fact that unlike other controls' data
properties, the Checked property of a
radio button doesn't actually change
until focus leaves the radio button.
And as with all WinForms controls the
focus doesn't actually leave the radio
button until after focus is given to
another control, and in fact not until
after the Click event of the newly
focused control has fired. The result
of this, as it pertains to radio
buttons, is that if you try to bind to
them, the bound properties in your
datasource will actually lag your
radio buttons' visual state by one
click. If you have just two radio
buttons, the datasource will be
exactly opposite the visible state,
until you click somewhere else that
doesn't trigger an action that
references those datasource
properties. Which can make this a
really infuriating bug to track down.
I almost thought I was hallucinating.
Now, in all honesty, it's possible to
make it work. But it is the kludgiest
kludge that ever kludged. Okay maybe
it's not that bad... but it's a messy
hack for sure. It takes a lot of work
for something that really should
already be available. As near as I can
tell, the only way to solve this
problem without giving up the
databinding mechanism is to
essentially make your own RadioButton
control, with a property change and
event order that is actually useful.
You can either write one from scratch,
or sub-class RadioButton and override
all the event logic with custom
message handling.