[WPF Bug list] (6) -- The IsCancel attribute of the Button is invalid

In the previous article, the hidden modal dialog box is described and the Bug becomes non-modal. Many people reply that this is not a Bug and I also understand it. Bugs are meaningful only when they are needed. Different requirements have different definitions of bugs. As a Framework,. NET can only meet the needs of the widest group in most cases, so it can be said that it is qualified. However, I would like to consider the problem described in the previous article.

 

Show and ShowDialog of Window are used to display the form (I didn't use display), while Close is used to Close the form. After Close, you cannot use Show or ShowDialog to display the form again. Otherwise, an exception is thrown. Therefore, gboxcc on the fifth floor returns an error. I am very sorry for this gboxcc because he thinks that the wrong sentence is exactly what I wrote for code verification.

 

If you want to hide a form without closing it, it is obvious that you cannot use Close. In addition, all Close events can be canceled to ensure that the form is not closed, and the form can only be hidden with Visibility. After hiding it, if you want to display the form again, Visibility is used first, but it cannot be found.

 

From this perspective, Show/Close is called only at the beginning and end of the Window class, because they cannot be called alternately. After the Show form, use Visibility to control its Visibility, because visibility can be set randomly. I think this is a very natural thing. However, the actual situation of the Window is that the Visibility setting will change the value of the isShowingDialog variable. This is not a requirement. So I mentioned it as a Bug. Colin Han believes that this is a dedicated design for better user experience .", I also disagree. Moreover, I feel that the communication between Microsoft's UX team and the development team is still inadequate. For example, the WPF Window I mentioned in another article, no attribute is provided to set whether an Icon is displayed for a form. This is not in line with Microsoft's own UX Guide.

 

The respondent agreed that ShowDialog should also be used to display the form again. Well, this article was born for the next time. The problem is also caused when the form is displayed again using ShowDialog. You don't need to change the code. You can use the previous code to reproduce this problem. Use the ShowDialog method to convert a formAgainAfter it is displayed, the "Hide Self" button on the form becomes invalid. Note that the behavior is normal when ShowDialog is released for the first time.

 

Here, by the way, we will introduce the IsCancel attribute. The description on MSDN is as follows:Gets or sets a value that indicatesButtonWhether it is a "cancel" button. You can press ESCKey to activate the "cancel" button.In fact, I feel that this sentence is of no help to new users. It seems that this property is to add an ESC key to the Button as the shortcut key. It must be combined with many documents on MSDN to know what the IsCancel button plays in different environments. In fact, it is better to write a code by yourself to give it a try.

 

For the code in the example, IsCancel is equivalent to closing the current form. This is the easiest way to add a close button to a form (none ). This Bug uses the previous code. So I won't give you a texture. Run it on your own. The logic is as follows:

 

1. Click the Show Model Dialog button in the example to display a modal Dialog box.

2. You can use Hide Self to close the pop-up box.

3. Use Show Model Dialog to bring up this Dialog box.

4. The Hide Self button no longer works.

 

Other articles in the same series:

[WPF Bug list] (sequence) and (1) -- multiple choice ListBox

[WPF Bug list] (2) -- The IsChecked binding of RadioButton is invalid.

[WPF Bug list] (3)-dialog box for opening a file for secretly creating a file

[WPF Bug list] (4) -- click RadioButton to return Blank

[WPF Bug list] (5) -- hide the modal dialog box and convert it to non-modal Mode

[WPF Bug list] (7) -- stubborn Error Template

[WPF Bug list] (8) -- MaxHeight in RowDefinition fails under certain conditions

[WPF Bug list] (9) -- disappears the cursor

 

I am a MS Fan.But I will still look at it with a discerning eye, just because I am a MS FanThe reason is that from the perspective of most development and entertainment and applications, MSIs currently the best choice. If one day LinuxWhich of the following releases exceeds MS in most respects?I will invest in Linux without hesitation. It's just a platform, not a girlfriend, or a "known already", and you don't have to keep yourself in touch.