Can anyone think of a good explanation for the fact that result of a dialog is a nullable bool in WPF? This has always baffled me. In WinForms it was an enum type and that made a lot more sense to me.
相关问题
- Generic Generics in Managed C++
- VNC control for WPF application
- How to Debug/Register a Permanent WMI Event Which
- 'System.Threading.ThreadAbortException' in
- Bulk update SQL Server C#
相关文章
- .net中MessageBox.Show使用问题
- IdentityServer 报错:"idp claim is missing"
- 在 IdentityServer 中如何给 id token 添加更多信息
- WPF:如何在Trigger里修改Orientation?
- IdentityServer 的 Selector 在哪个 nuget 包
- 使用 IdentityServer 的项目遭遇错误:"IDX20803: Unable to obt
- ASP.NET Core ConfigureServices 中从 appsettings.json
- WPF aforge 怎么做一个 圆形的播放器
IMO this is because DialogResult isn't always used. You see, you can only set DialogResult if the window is called by its ShowDialog() method, if you call it with its Show() method, and try to set DialogResult to anything, it'll throw an InvalidOperationException. So I think that is the reason it's nullable, in case you call the window with the Show() method, it'll be null, if you call it using ShowDialog(), it's up to you.
According to the MSDN documentation:
But I'm not sure how that could happen unless you're dealing with multiple threads accessing the dialog.
The documentation says is false when one of the following things happen:
ShowDialog will always return true or false. DialogResult will only take the null state when the dialog is open. Transitioning from null to true or false will close the dialog and make the original call to ShowDialog return.
In my opinion this was done because in most cases you don't need the generalized specialized options like Retry or Ignore.
If you need more than OK/Cancel, you are supposed to use some kind of task dialog, e.g. with written-out answers. That way, you're not limited to the few enum values someone thought of some decades ago, and the DialogResult is just positive/negative for basic use and you can implement your own property that is specific to your advanced needs. Therefore only true/false is needed, and null indicating that the window has not been closed yet (no value has been assigned to the property yet).
If you have a dialog that is more than just a question the user should answer (e.g. an entry form), you're typically better off with OK/Cancel, so you don't need more values.
The
DialogResult
property is defined on theWindow
class. Not allWindow
s are dialogs. Therefore, the property isn't relevant to all windows. AWindow
that has been shown viaShow()
rather thanShowDialog()
will (presumably, unless you set it for some reason) haveDialogResult = null
.Here's a simple example to demonstrate:
Window1.xaml:
Window1.xaml.cs:
When you close the windows, you'll notice that the dialog has a
DialogResult
offalse
, whilst the non-dialog has anull DialogResult
.