是否有从 Windows 窗体中的自定义对话框返回值的标准方法?
-
09-06-2019 - |
题
所以现在我的项目有一些自定义对话框,可以执行诸如提示用户生日等操作。现在他们只是做一些事情,比如设置一个 this.Birthday
一旦他们得到答案(其类型为 DateTime?
, ,其中 null 表示“取消”)。然后调用者检查 Birthday
它创建的对话框的属性,用于确定用户的回答。
我的问题是, 有没有更标准的模式来做这样的事情? 我知道我们可以设置 this.DialogResult
对于基本的“确定/取消”内容,但是 Windows 窗体中是否有更通用的方法来指示“这是我收集的数据”?
解决方案
我想说的是,在自定义对话框上公开属性是惯用的方法,因为标准对话框(如 Select/OpenFileDialog)就是这样做的。有人可能会说,使用 ShowBirthdayDialog() 方法返回您正在寻找的结果更明确,也更能揭示意图,但遵循框架的模式可能是明智的选择。
其他提示
有没有更标准的模式来做这样的事情?
不,听起来您正在使用正确的方法。
如果对话框返回 DialogResult.OK,则假定对话框中的所有必要属性均有效。
对我来说,坚持使用对话框返回标准对话框响应,然后通过属性访问结果是正确的方法。
从我的立场来看,有两个很好的理由:
- 一致性 - 你总是通过对话做同样的事情,并且问题的本质表明模式是好的(-:尽管同样的问题是这是否是一个好的模式?
- 它允许从对话框返回多个值 - 好吧,这里也有全新的讨论,但是应用实用主义意味着这是人们在某些情况下想要的,将值打包起来以便您可以将它们传回并不总是合适或可取的一气呵成。
逻辑流程也很好:
if (Dialog == Ok)
{
// Do Stuff with the entered values
}
else
{
// Respond appropriately to the user cancelling the dialog
}
这是一个很好的问题——我们应该提出这样的问题——但对我来说,当前的模式是一个不错的模式。
墨菲
对于模式输入对话框,我通常会重载 ShowDialog 并传递我需要的数据的参数。
DialogResult ShowDialog(out datetime birthday)
我通常发现,与将我的属性与 Form 类公开的 100 多个属性混合相比,更容易发现和理解。
对于表单,我通常有一个控制器和一个使用只读属性传递数据的 IView 接口。
我一直都是按照你描述的方式做的。我很好奇是否有更容易接受的方法。