为什么将我的单选按钮绑定到应用程序设置会在单击时改变其行为？

发布于 2024-09-07 17:31:18 字数 635 浏览 1 评论 0原文

可能的重复：
使用 ApplicationSettings 存储 WinForms RadioButtons 的 Checked 属性 < /p>

I组框中有三个单选按钮。当它们未绑定到应用程序设置时，它们的行为正常。

将每个选中的属性绑定到应用程序设置后，会发生以下情况：我必须单击未选中的单选按钮两次才能将其选中。第一次单击后，所有三个都被取消选中。

我也尝试只绑定其中两个，但行为是相同的。

有人可以帮忙解决这个问题吗？

谢谢。

我还在 MSDN Visual 上询问基础综合论坛。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

屋顶上的小猫咪 2024-09-14 17:31:18

您可以将以下事件处理程序添加到 GroupBox 中三个 RadioButton（其中 Checked 属性绑定到应用程序设置）中每一个的 Click 事件中：

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

它可以工作，即使未选中的 RadioButton 需要半秒的时间。点击后检查。

两年前（2008 年）幸存 WinForms 数据绑定发表在 Turbulent Intelect 博客上（谢谢 ohadsc 提供的链接） :

规则 5：不要绑定到可点击的单选按钮
我知道如果你有的话该多好
可以绑定你的一堆收音机
按钮到枚举属性。我真的
做。你认为你只是要去
连接一些格式化和解析事件
翻译回您的枚举，并且
一切都会好起来的。那就太糟糕了
方便的话，如果真的有效的话。但
WinForms 不适合这个。
现在有 3 个完整版本（或者是 3.5
发布？），情况就是如此。
这是因为事件顺序，
不是MS可以去的
切换不会造成数千
的开发人员感到非常厌烦
关闭。
问题实际上归结为
事实上，与其他控件的数据不同
属性，一个的 Checked 属性
单选按钮实际上并没有改变
直到焦点离开单选按钮。
与所有 WinForms 控件一样
焦点实际上并没有离开收音机
按钮，直到焦点被赋予后
另一个控制，事实上直到
新的 Click 事件之后
集中控制已启动。结果
这与广播有关
按钮，如果你尝试绑定到
他们，你的绑定属性
数据源实际上会落后于你
单选按钮的视觉状态减一
单击。如果你只有两台收音机
按钮，数据源将是
与可见状态完全相反，
直到你点击其他地方
不会触发以下操作
引用那些数据源
特性。这可以使这成为
真正令人恼火的错误要追踪。
我差点以为自己出现了幻觉。
现在，老实说，有可能
让它发挥作用。但它是最笨拙的
曾经拼凑过的拼凑。好吧也许
没那么糟糕...但是很乱
肯定是黑客攻击。这需要大量的工作
为了一些真正应该的事情
已经可用。尽我所能
告诉，解决这个问题的唯一方法
问题而不放弃
数据绑定机制是
本质上是制作你自己的RadioButton
控制，通过属性改变和
实际有用的事件顺序。
您可以从头开始编写一个，
或RadioButton 的子类并覆盖
所有事件逻辑都带有自定义
消息处理。

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.