On Apr 14, 2011, at 00:42, Peter Lübke wrote: > This is of course true if the changes are made in the main thread. > I should have mentioned that I'm changing the data in separate worker threads. > > Actually, it's possible that there are several worker threads changing data > of different tables in different windows at the same time, while the > associated windows display attached sheets showing progress. Permanently > redrawing the tables's cells at this stage is confusing and also undesirable > for performance reasons.
This *seems* to be wrong at several levels, although perhaps that's just because there's information missing. If processing in background threads is causing table views to update directly, then your application design is very seriously broken. All drawing should be done from the main thread, which means that KVO notifications must be issued on the main thread, which means that the data model must be updated on the main thread, as far as KVO compliance is concerned. You cannot bind UI elements to objects whose KVO-compliant properties are updated directly by a background thread. It's possible that you mean that the updates *are* happening on the main thread, and you have a mechanism that the background threads use to pass the updates to the main thread. But if not, you're going to have to invent such a mechanism. Avoiding refreshes of the table views is a different issue. By binding your table columns to an array controller, which is in turn bound or connected to your data model, you have *opted in* to a mechanism (KVO) that is explicitly designed to push updates as and when they occur. So, complaining that refreshes occur as and when updates are pushed seems a bit misguided. You're going to have to either opt out of that mechanism, or you're going to have to modify its behavior: -- You can use a data source instead of bindings. With a data source, nothing gets updated till you tell the table view to display or to reload (or till something a user does triggers redrawing). You'll lose some of the free functionality that array controllers provide (if you're using it), but it shouldn't be hard to implement for yourself. -- You can invent a mechanism for deferring changes to your data model, until a point where UI refreshes are appropriate. It doesn't sound like you can take this approach, because it sounds like your background threads depend on the current state of the data model being generally available. -- You can use a mediating controller, for example the window controller, to capture the KVO notification data from data model updates, and to withhold it from the UI until a suitable refresh time arrives. In this case, your array controller's content can't be the data model, but has to be a intermediate data model or a proxy data model in the mediating controller. _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
