StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I answer this part of your question:</p> <blockquote> <p>How do I eliminate the need for 2x clicking on the radio buttons?</p> </blockquote> <p>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:</p> <pre><code>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 </code></pre> <p>It works, even though it takes a half-second for an unckecked RadioButton to be checked after you click it.</p> <p>The reason for the problem was explained two years ago (in 2008) in section 5 of the <a href="http://turbulentintellect.blogspot.com/2008/07/surviving-winforms-databinding.html" rel="nofollow noreferrer">Surviving WinForms Databinding</a> post on the Turbulent Intelect blog (Thank you, <a href="https://stackoverflow.com/users/67824/ohadsc">ohadsc</a>, for the link):</p> <blockquote> <p><strong>Rule 5: Don't bind to clickable Radio Buttons</strong></p> <p>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.</p> <p>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, <strong>the bound properties in your datasource will actually lag your radio buttons' visual state by one click</strong>. 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.</p> <p>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.</p> </blockquote>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload