非阻塞消息框和DllImport 的缺点
我目前是一名开发人员，正在开发一个特定于任务的应用程序；用户经常同时处理多项任务，因此他们在输入数据时经常会出错。任务的性质使得通知他们这些估算错误非常重要。目前，我们使用面板和标签的组合和/或应用程序底部的小标签来通知他们正在发生的事情。在不久的将来，我们将负责更新应用程序的界面。
最近在查找一个不相关的问题时，我遇到了以下问题： 点击此处获取链接 答案引起了我的注意，将所有者的句柄设置为零（空）确实按照作者的要求做了。
由于我最近才开始在 C# 中导入和使用非托管代码，我想知道使用此方法是否有任何“副作用”。我当然意识到用户可能会导致应用程序打开大量消息框。我过去曾尝试使用线程安全的消息框，发现我们的应用程序始终位于顶部的要求是一个问题（消息框的位置被应用程序隐藏了）。
我能够根据要求测试代码，它似乎与我发现的方法有类似的问题，但似乎我们可以解决这些问题。我确实想到了一些可以做的事情，我确实需要弄清楚如何确定消息框将在屏幕上的哪个位置显示。
为了解决吉姆的担忧，我们必须了解正在运行的应用程序正在不断地处理数据。因此，目前锁定主线程的任何操作都可能导致处理此数据时出现问题，这是任务关键型的。我们使用标签来解决这个问题，但在未来的任务中，我正在寻找一种更简化的方法来呈现这些错误消息。主要问题是该解决方案还不能给应用程序带来额外的开销。一些额外的信息是该系统在封闭网络上使用。
我想简短的问题是，使用这种特定方法在 C# 中显示非阻塞消息框是否有任何负面影响？
I am currently a developer working on a very task specific application; the user(s) are often multitasking so they can often make errors inputting data. The nature of the task makes notifying them of those imputation mistakes important. We currently use a combination of panels and labels and/or a small label at the bottom of the application in order to notify them of something happening. In the near future we will be tasked to update interface for the application.
Recently while looking up an unrelated question I came across the following question:
click here for link the answer caught my eye and setting the owner’s handle to zero (null) did indeed do what the author asked.
Since I have only recently started working with importing and working with unmanaged code in C# I was wondering if there were any “side effects” of using this method. I of course realize that the user could cause the application to open a ton of message box(s). I have in the past attempted to use a thread-safe message box and found the requirement of our application always being on top was an issue (the location of the message box was hidden by the application).
I was able to take to test the code against the requirement, and it appears to have similar issues as the method I found but appears we could work around those issues. I did think of something that could be done, I realy need to figure out how to determine where on the screen the message box will be displayed.
In order to address Jim's concerns one has to understand that the application that is running is processing data continously. So currently anything that locks the main thread, can cause problems processing this data, which is task critical. We get around this problem using labels, but with our future task I am looking for a more streamline approach to present these error messages. The main problem is the solution also must not additional overhead to the application. Some additional tid-bits of information is that the system is used on a closed network.
I suppose the short question would have to be, are there any negatives of using this particular method, to show a non-blocking messagebox in C#?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通过将窗口句柄设置为 null 来显示模式消息框不存在特殊的技术问题。我质疑它作为 UI 错误消息指示的用途，因为它不会阻止用户在遇到错误时继续操作。
模态消息框让用户点击“确定”，然后纠正错误，这导致用户界面非常笨拙。但是，一个可能被隐藏并让用户继续前进的弹出窗口也同样糟糕。有更好的解决方案，其中一些在 Windows 窗体（大概还有 WPF）的验证示例中显示。
There's no particular technical problem with displaying modal message boxes by setting the window handle to null. I question its use as a UI error message indication, because it doesn't prevent the user from continuing in the face of error.
Modal message boxes that make the user hit OK and then correct the error make for a terribly clunky user interface. But a popup that might be hidden and lets the user keep going is just as bad. There are much better solutions, some of which are shown in the validation examples for Windows Forms (and, presumably WPF).