保持用户界面最新的最佳方式？

问题描述

这个问题是我的问题的改进。

我的C ++应用程序中还有很多类，或者可以在复杂的数学例程和复杂的业务逻辑中频繁地更新。

如果我采用观察者方法，我有2个很大的风险：

• 发送通知本身可能会严重拖慢应用程序


• 如果用户界面元素需要通过更改进行更新，则会随每次更改而更新，从而导致例如




一些问题可以通过添加缓冲机制来解决（其中，发送通知，当你要开始一个算法，当算法完成时），但由于业务逻辑可能在软件中的许多地方执行，我们最终添加缓冲几乎无处不在，在每个可能的行动选择





而不是'observer'aproach，我也可以使用'mark-dirty'方法，只标记被修改的实例，





再次，业务逻辑可以从应用程序中的任何地方执行，因此在实践中，我们可能必须添加一个额外的调用（告诉所有窗口，他们应该更新自己）几乎每一个用户执行的操作。





这两种方法似乎有相似，但相反的缺点：






• 使用观察者方法，我们有更新用户界面的风险太多次了








这两个缺点都可以通过嵌入来解决每个应用程序在附加逻辑中的动作（对于观察者：发送开始 - 结束通知，对于标记脏：发送更新自己通知）。





窗口应用程序这可能不是一个问题。您可以使用标记脏方法，只有当一些计算需要数据时，它可能需要做一些额外的处理，以防数据是脏的（这是一种缓存方法）。





然而，对于窗口化应用程序，没有用户正在查看您的屏幕的信号，并且窗口应该更新。所以没有真正的好时机，你必须看看脏数据（虽然你可以做一些技巧与焦点事件）。





什么是好的解决方案解决这个问题？你在应用程序中如何解决这样的问题？





请注意，我不想在我的应用程序的计算/数据模型部分中引入窗口技术。如果需要窗口化技术来解决这个问题，它只能在我的应用程序的用户界面部分使用。





任何想法？

$ b $我使用的一种方法是使用大型Windows应用程序几年前是使用 WM_KICKIDLE 。所有可更新的东西都使用一个抽象的基类 IdleTarget 。 IdleTargetManager 然后拦截 KICKIDLE 消息并调用注册客户端列表上的更新。在你的实例中，你可以创建一个更新的具体目标的列表，但我发现注册的客户列表足够了。




我打的唯一的是一个实时图。使用只是kick idle消息，它会尖峰CPU 100％由于图的不断更新。





如果您需要更多帮助 - 我可以合理的价格...： - ）




This question is a refinement of my question http://stackoverflow.com/questions/3161392/different-ways-of-observing-data-changes.

I still have a lot of classes in my C++ application, which are updated (or could be updated) frequently in complex mathematical routines and in complex pieces of business logic.

If I go for the 'observer' approach, and send out notifications every time a value of an instance is changed, I have 2 big risks:

• sending out the notifications itself may slow down the applications seriously
• if user interface elements need to be updated by the change, they are updated with every change, resulting in e.g. screens being updated thousends of times while some piece of business logic is executing

Some problems may be solved by adding buffering-mechanisms (where you send out notifications when you are going to start with an algorith, and when the algorithm is finished), but since the business logic may be executed on many places in the software, we end up adding buffering almost everywhere, after every possible action chosen in the menu.

Instead of the 'observer' aproach, I could also use the 'mark-dirty' approach, only marking the instances that have been altered, and at the end of the action telling the user interface that it should update itself.

Again, business logic may be executed from everywhere within the application, so in practice we may have to add an extra call (telling all windows they should update themselves) after almost every action executed by the user.

Both approaches seem to have similar, but opposite disadvantages:

• With the 'observer' approach we have the risk of updating the user-interface too many times
• With the 'mark-dirty' approach we have the risk of not updating the user-interface at all

Both disadvantages could be solved by embedding every application action within additional logic (for observers: sending out start-end notifications, for mark-dirty: sending out update-yourself notifications).

Notice that in non-windowing applications this is probably not a problem. You could e.g. use the mark-dirty approach and only if some calculation needs the data, it may need to do some extra processing in case the data is dirty (this is a kind of caching approach).

However, for windowing applications, there is no signal that the user is 'looking at your screen' and that the windows should be updated. So there is no real good moment where you have to look at the dirty-data (although you could do some tricks with focus-events).

What is a good solution to solve this problem? And how have you solved problems like this in your application?

Notice that I don't want to introduce windowing techniques in the calculation/datamodel part of my application. If windowing techniques are needed to solve this problem, it must only be used in the user-interface part of my application.

Any idea?

解决方案

An approach I used was with a large windows app a few years back was to use WM_KICKIDLE. All things that are update-able utilise a abstract base class called IdleTarget. An IdleTargetManager then intercepts the KICKIDLE messages and calls the update on a list of registered clients. In your instance you could create a list of specific targets to update but I found the list of registered clients enough.

The only gotcha I hit was with a realtime graph. Using just the kick idle message it would spike the CPU to 100% due to constant updating of the graph. Use a timer to sleep until the next refresh solved that problem.

If you need more assistance - I am available at reasonable rates...:-)

这篇关于保持用户界面最新的最佳方式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！