WPF Bug Manifest (2)--radiobutton ischecked binding invalidation

The. NET framework is already a very easy to use library. Can do a lot of things for us automatically, and most of them do well. But the things that are done automatically are likely to be hidden because the framework itself does not understand the business logic. It automatically completes things that might be counterproductive to us.

RadioButton is one of them.

First, introduce the dependency property (DP) in WPF from the point of view of setting values. There are too many ways to control the DP of a control in WPF. You can use style, you can use animation, you can use the data Binding, you can use trigger, there are the most basic direct assignment. The control combines the value of each aspect of the above, and its precedence to determine what the final value of a DP is. More knowledge about this can be referred to as rain marks on DP articles or MSDN. (However, it is not certain that there is any introduction to the DP Priority system on MSDN.) ）

Most controls do not automatically change the value of one of their properties. But there are always some exceptions. RadioButton is one of them. What value does it automatically set? The answer is the ischecked attribute. RadioButton is characterized by a group of RadioButton with only one selected. When a radiobutton is selected, all other RadioButton are automatically set ischecked property to False.

The problem is that there are so many ways to set up a property, and when it automatically sets this property, what method should be used? This question was already discovered at. NET 3.0 and discussed at Microsoft's Forum. MSFT's Sam Bent also acknowledges the existence of the bug. The problem, however, is that no matter what existing methods RadioButton use to make the ischecked attribute false, "there will always be people who are unhappy". The 3.0-RadioButton automatically invalidates the value of style and template, and in 3.5, fix 3.0 of the bug, but it causes binding to fail.

The author verifies that the same logic is used in the. NET 3.5 SP1, even if the binding fails. Below we will use a "for Microsoft Select CEO" sample program to verify.

First define a person class, as follows:

Person

1using System.ComponentModel
2using system.diagnostics
3
4namespace Bindingradiobutton.model
5{
6/**////<summary>
7///
8///</summary>
9 public class Person:inotifyproperty Changed
Ten
Private fields#region private Fields

private bool Isceo;
Private St ring name;

#endregion

properties#region public Properties
/**////<summ Ary>
///
///</summary>
"public bool Isceo
" {
/get {return ISCE O　　　　　　　　　　
Isceo Set
{
if (value!=)
{
Isceo = value;
31 OnPropertyChanged ("Isceo");
32}
33}
34} 　　　　

/**////<summary>
///
///</summary>
public string Name
40 {
A. {return name;}　　　
43 Set
　　　{
-if (value!= name)
is {
name = value;
onpropertychanged ("Nam E ");
48}
49}
50}
Wuyi
#endregion
INotifyPropertyChanged
members#region inotifypropertychanged members
55< br>/**////<summary>
///
///;
The public event </summary> Handler propertychanged;

#endregion
protected
onpropertychanged virtual void (string propertyname)

PropertyChangedEventHandler temp = propertychanged;　　　　　　　　
if (temp!= null)
, {
Temp (this, new PropertyChangedEventArgs (PropertyName));
69 Trace.WriteLine (String. Format (' {0} {1} ceon ', Name, Isceo? ' Is ': ' is not ');
70}
71}
72}
73}
?