从 DLL 更新 WPF GUI
这似乎是一个非常常见的任务，但我没有运气寻找答案。
我有一个 WPF/C# 应用程序，它严重依赖 dll 来执行数据库例程。我希望 dll 更新一些 GUI 元素，即进度条。
到目前为止，答案似乎在于 System.ComponentModel 和创建后台工作者中的某个地方。但这是我所能得到的。
有人可以就如何完成这项任务提供建议吗？链接、示例代码、鼓励的话表示赞赏！
非常感谢，
杰瑞
This seems like it would be pretty common task, but I'm not having any luck searching for an answer.
I have a WPF/C# application that relies heavily on a dll for database routines. I would like the dll to update some GUI elements, i.e. a progress bar.
So far, it seems that the answer lies somewhere in System.ComponentModel and creating a backgroundworker. But that's as far as I can get.
Can someone please offer suggestions on how to accomplish this task? Links, sample code, encouraging words appreciated!
Many thanks,
Jerry
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
最好的办法是对其进行设置，以便 UI 在调用数据库 DLL 时传递回调函数。数据库 DLL“定期”调用该回调，然后 UI 中实现的回调会更新 UI 元素。
最好不要让数据库 DLL 与 UI 混在一起。一方面，它会使 DLL 非常依赖于 UI 的具体情况，以至于该 DLL 无法真正被任何其他 exe 使用。
Your best bet is to set it up so that the UI passes in a callback function when calling into the database DLL. The database DLL calls that callback "periodically", and the callback implemented in the UI then updates the UI elements.
It would be best not to let your database DLL muck around with your UI. For one thing, it would make the DLL very dependent upon the specifics of your UI, to the point that the DLL would not really be usable by any other exe.
现在很难准确地告诉你的代码是如何工作的，我认为答案取决于你当前的实现是否阻塞了 UI（即，通过对 DB DLL 进行同步调用）。
现在，如果您对 DLL 的调用是同步调用并且它阻塞了 UI，那么您可能需要考虑使用 BackgroundWorker 来完成这项工作，并允许您的主 UI 线程避免挂起。您可以参考如何实现进度C# 中的 bar？ 以获得一些答案。
但是您仍然需要某种机制来了解数据库调用的进度，而且听起来 DLL 还没有公开类似的内容。
只是从你的问题的字里行间看出来，听起来你有一些修改 DLL 的能力。如果是这样，那么您应该尝试使用一种模式，在提供进度信息时保留 DLL 和 UI 应用程序之间的解耦。您的 UI 代码实际上应该负责根据 DLL 可以以松散耦合方式提供的某些数据来更新自身。我建议使用以下任一种：
某个班级在
动态链接库；或
定期监视 DLL 中实现的某些数据对象
基础（例如，在计时器滴答期间
处理程序）。
无论哪种方式，您都希望通过编写 DLL 来深入了解 UI 层，从而避免将两层紧密耦合在一起。在大多数情况下，上述两种可能性都应该允许您将 UI 更新代码保留在应用程序可执行文件的主 UI 线程上，如果您想避免多线程问题，这一点很重要。
It's a little hard to tell exactly how your code works now, and I think the answer depends on whether or not your current implementation is blocking the UI (i.e., by making a synchronous call to your DB DLL).
Now, if your call to the DLL is a synchronous one and it's blocking the UI then, yes, you might want to consider using a BackgroundWorker to do that work and allow your main UI thread to avoid hanging. You can refer to How do I implement a progress bar in C#? for some answers.
But you still need some mechanism for knowing the progress of your DB call, and it doesn't sound like the DLL exposes anything like that yet.
Just reading between the lines of your question, it sounds like you have some ability to modify the DLL. If so, then you should try to use a pattern that preserves decoupling between the DLL and your UI app when providing progress information. Your UI code should really be responible for updating itself based on some data that the DLL can provide in a loosely coupled way. I would suggest using either:
an event published by some class in the
DLL; or
monitor some data object implemented in the DLL on a periodic
basis (e.g., during a Timer Tick
handler).
Either way, you want to avoid tightly coupling the two layers together by coding the DLL to have intimate knowledge of your UI layer. Both of the aforementioned possibilities should allow you to keep your UI updating code on the main UI thread of your app executable in most circumstances, which is important if you want to avoid multithreading issues.
BackgroundWorker可以工作，就像Task对象一样（我个人更喜欢Task）。我的博客有一个示例这两个操作后台工作，全力支持取消和渐进进度。您可能不需要这种级别的复杂性（例如取消）。A
BackgroundWorkerwould work, as would aTaskobject (I preferTask, personally). My blog has an example of both of these doing background work, with full support for cancellation and incremental progress. You may not need this level of complexity (e.g., cancellation).