C# winform程序,UI界面锁死。如何处理？

Posted 2023-04-11

程序“未响应”。有时候是程序未响应，有时候是什么都动不了（死机）。
Timer中的方法是在主线程执行的，如果执行时间长，会锁UI界面，表现为鼠标不可控，任务管理器程序显示“未响应”。
处理方法：1.优化Timer控件中Tick事件中的方法，减少方法执行时间
2.加大Timer的Interval，如果要求不高，1000毫秒以上就好。这个Interval最好不要低于200
3.多线程处理，将消耗大的业务放在子线程中，这样UI不会锁死。请问还有别的方法处理吗？
请问在Tick事件中开始加入时钟禁止，当事件代码执行完再使能时钟，可否？

Winform 程序，要想保证 UI 不卡死，只有将长耗时任务放到非UI线程运行这一个办法。而且现在早已进入多核时代，软件上多线程设计的思想要是要有的，不然的话，CPU的性能是不能充分利用的。

楼主说的方法1与2，如其他回答所说一样，治标不治本。关于多线程编程，楼主可以参考下 Task 。这个类库在线程上又多封装了一层，让开发者可以不直接接触线程来实现并行运算。用 Task 来处理楼主的问题用不了几行代码的。 参考技术A 1和2按你的情况都是没用的，如果你所说的那个执行是个循环的话，可以在循环中加一行Application.DoEvents() 这个可以让UI不卡死，但加入这个会极大的降低你的循环执行效率。所以一般情况下还是要用多线程的。追问

加Application.DoEvents()，几分钟后就卡死了。
不加反而可以使用几个小时。

参考技术B 不要用定时器 开个线程 后天处理数据 然后UI填充 等动作。

你以上设置 定时器 1秒执行一次 无限在触发。。 参考技术C 一般情况都是放在子线程中运行。这样既保证效率，方便管理 参考技术D 没有没有没有没有

针对 SQL Server 的自定义 winforms 身份验证：如何处理密码过期？

【中文标题】针对 SQL Server 的自定义 winforms 身份验证：如何处理密码过期？

【英文标题】：Custom winforms authentication against SQL Server: how to handle password expiration?

【发布时间】：2011-12-14 14:29:46

【问题描述】：

我们有一个基于 Winforms 和 Entity Framework 4.2（代码优先）和 SQLServer 2008 R2 构建的项目。

在这个项目中，用户必须使用他们的用户名/密码（从登录屏幕）对 SQL Server 进行身份验证。

因此不会有“主”或“系统”用户，也不会有检索/比较用户名/密码的查询：该过程已经通过登录 SQL Server 完成。 用户将拥有自己的 SQL 用户帐户，并且应该在应用程序中进行处理。

但是，我们遇到了密码过期政策，这让我们陷入了困境。 我们该如何处理呢？具体来说，如果账号已经过期，我们该如何处理？

我们已经处理了异常，但我们根本不知道如何远程更改用户的密码。

这不是关于用户 A 更改 B 的密码。而是关于 A 更改自己的密码，因为它已过期（我不能要求用户登录 SQL Server Management Studio 来执行此操作）。

【参考方案1】：

您可以使用ALTER LOGIN 语句

但是，请注意，理论上这允许任何用户更改任何其他用户的密码，只要他们具有 ALTER LOGIN 权限，因此您应该确保让用户也提供旧密码（我相信这是默认密码）。

出于兴趣，您为什么不使用 Windows 身份验证？这样，登录到期和密码处理对您来说是透明的。

【讨论】：

更改登录需要我登录并拥有 ALTER LOGIN 权限。使用 EntityFramework 我无法登录，因为密码已过期，因此无法运行该语句。这是一个问题。其次是用户不能拥有 ALTER LOGIN 权限。我需要这个系统，因为将有 3 种类型的身份验证：仅系统（使用“主”用户）、此（sgbd）和 Windows 身份验证。客户必须能够选择。

您可以以 sql 用户身份运行 ALTER LOGIN，该用户仅具有更改登录权限且不会过期。由于用户仍然需要知道自己的密码，因此不会让您面临任何额外的风险。

它破坏了应用程序的设计（用户应该对数据库进行身份验证，仅此而已）。我知道这样做是可能的（某种“主”用户，即使特权减少），这可能是这样做的唯一方法，但我正在研究其他方法。我想到了一些与连接字符串相关的东西（可能是一种发送新密码和旧密码的方法）或来自 SQLClient 的 API 可以帮助......

不幸的是，除非您以新用户身份运行，否则该 API 将无济于事。旧登录名过期后，您根本无法以他们的身份连接 - 因此建议以其他用户身份连接。 SQLDMO API 也是如此——你将作为谁进行身份验证？您可能会争辩说，通过提供他们的旧密码，用户仍在验证自己，因为帐户重新启用并且密码更改不会发生，否则不会发生。

是的，这就是问题所在。无论如何我不得不问它。 AFAIK 应该是这样做的，但如果根本没有，我只需要为日志（只写）和密码策略（仅更改登录）创建一些“管理帐户”。想知道这种方法是否安全... =) 无论如何谢谢。