> On 16 Mar 2015, at 11:58 am, Patrick J. Collins > <patr...@collinatorstudios.com> wrote: > > The problem is, there is quite an obnoxious lag between spinner being > hidden and table view contents actually updating. I am assuming because > this is a 13 column x several hundred rows,
That's a big table... sure it's the right UI here? > NSTextField *result = [tableView > makeViewWithIdentifier:kFrameDataTableViewIdentifier owner:self]; > if (!result) > And guess what? result is always false... Which means you've probably missed something. View-based tables recycle their views by default and only update those that are actually visible. The result should not be false if the view is able to be fetched from the recycle queue. To be honest getting that all right is a bit tricky and it's not helped by the confusion that results from trying to set it up in IB, a process that is far from crystal clear. > Which makes me wonder why in their > documentation do they suggest that result == nil check? But, I am confused > why > it's recreating views from scratch anytime the table content changes? That's > certainly going to most likely be the performance lag I am seeing. Getting the table view working correctly is likely to be the key to this, but... > But that's what my original question was regarding, if say that lag was not > nothing that could be removed, how could I make my progress bar hide not when > the table content updates, but when the table has completed it's updating > (hence the delay is over), because right now I get the spinner, it disappears, > but there is roughly a 0.75 second pause before the table data changes ...if all else fails, you could just request that the spinner is hidden after a delay. It's right that your controller is turning off the spinner, because it is in charge of managing the various views here, in response to your data model finishing loading. The slow redisplay of the table is a problem, but the solution is to fix the table. If the table is huge then you may not be able to improve it beyond a certain point (though it sounds like you could here). If your controller has a -hideSpinner method, it can just call it like this: [self performSelector:@(hideSpinner) withObject:nil afterDelay:1.0]; and that might be adequate. An alternative would be to put a spinner in each table row view and move the responsibility for it to the row's view controller, where each one can be hidden as it gets the row's data. A much faster table would probably be greatly preferable though. --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
