我正在考虑通过使用一个传递 AppState 参数的单一方法来集中此功能，它处理基于此参数更改所有 GUI 元素的属性。每次应用程序更改其状态（准备好、忙碌、正在下载部分忙碌等）时，都会使用适当的状态（或者可能是位字段或其他东西）调用此函数，然后它就会发挥作用。
如果我在各处分散更改 GUI 元素的状态，那么很容易忘记当应用程序处于某种状态时，那里的其他小部件也需要被禁用，等等。
还有其他方法可以处理这种事情吗？
【问题讨论】：
标签： c# winforms user-interface
埃姆拉，
你的想法不错。您需要限制状态结构，这是确保 UI 可靠的唯一方法。另一方面不要严格遵循“一个功能”的想法。而是通过创建一个函数，然后逐步将所有属性重构为单个“setter”函数，不断地遵循它的方向。途中需要记住几件事：
仅使用单向通信。不要从控件中读取状态，因为这是万恶之源。先限制属性读取次数，再限制属性写入次数。
您需要结合一些缓存方法。确保缓存不会将属性读取注入主代码。
不要理会对话框，只要确保所有对话框通信都在打开和关闭期间完成，而不是在两者之间（尽可能多）。
在最常用的控件上实现包装以确保严格的通信框架。不要创建任何全局控制框架。
除非你的 UI 真的很复杂，否则不要使用这种想法。在这种情况下，使用常规 WinForms 或 JavaScript 事件将导致您的代码更小。
代码越少越好。除非你松了线，否则不要重构。
祝你好运！
【讨论】：
是的，这是 GUI 工作中最耗时的部分，以制作用户友好的应用程序。禁用这个，启用那个，隐藏这个，显示那个。确保在插入/更新/删除/选择/取消选择事物时所有控件都具有正确的状态。
我认为这就是你区分好程序员和坏程序员的地方。一个糟糕的程序员会在没有任何更改要保存时启用“保存”按钮，一个优秀的程序员只有在有东西要保存时才启用“保存”按钮（只是众多示例中的一个）。
我喜欢为此目的使用 UIControlstate-handler 的想法。
Me.UIControlStates=UIControlstates.EditMode 或类似的东西。
如果有这样的对象，它可能会在状态发生变化时引发事件，我们将代码放在那里。
Sub UIControlStates_StateChanged(sender as object, e as UIControlStateArgs)
if e.Oldstate=UIControlStates.Edit and e.NewState=UIControlStates.Normal then
rem Edit was aborted, reset fields
ResetFields()
end if
select case e.NewState
case UIControlStates.Edit
Rem enalbe/disable/hide/show, whatever
Case UIControlStates.Normal
Rem enalbe/disable/hide/show, whatever
Case UIControlStates.Busy
Rem enalbe/disable/hide/show, whatever
Case Else
Rem enalbe/disable/hide/show, whatever
end select
end sub
【讨论】：
@斯特凡：
我认为我们的想法是相同的，即一段代码可以修改所有小部件状态，而其他所有人都必须调用它来进行此类更改。除了，我正在描绘一个直接的方法调用，而你正在描绘引发/捕获事件。与简单的方法调用相比，使用事件有什么优势吗？
【讨论】：