bdunagan

fill the void

I’ve been looking for an elegant way to implement progress indicators in an NSCell for an app I’m working on. This is definitely the cleanest way I’ve seen yet. Nice work.

Thanks a ton dear! You have saved hours of time for me.. now this is the real contribution to the world..nice work! Please keep helping people like me who switch to mac from windows..:)

Very clean and tidy code. If only all code examples could be as clear as this.
I like it very much!

Can it be done with bindings instead of a datasource?

[...] Cocoa object; those objects only display the spinning lines for isIndeterminate:YES (see my NSProgressIndicator example from last year). Instead, that nice UI feedback is created through home-brewed [...]

If you remove row, progress still remains in table. You have make own tableview with redefined reloadData method with code something like this

while ([[list subviews] count] > 0)
{
[[[list subviews] lastObject] removeFromSuperviewWithoutNeedingDisplay];
}


Thanks a lot for this solution. I managed to use bindings and added a UI category to the data model, so the MVC design is still in place.

I’ve just noticed, when you have about 10 of these in a
table view at once, their animation performance is rather bad.
Sometimes, it seems as if an entire frames are skipped. What could
I do about that, since I’d like to let the user have nice-looking
progress bars, not choppy ones that they’ll get angry at

I’m actually implementing this in a downloads window, so I probably won’t have more than 4 or 5 showing at once for the average user, but I’m worried about the crazy people that want to download 20 things at once from my server. I was thinking of doing the thing that the table views do with their data, and loading it lazily, as in removing the progress bars when they are not visible, or at least not having them re-draw and waste cycles, and only drawing the ones that are actually visible. Possibly a custom table view subclass to handle that, or could a delegate be useful in this case?

But besides the rather obvious issues that every code has, I love you for this. Saved me quite some time trying to code my own cell subclass.

You have a retain cycle on BDObjects in the code. Easily broken by invalidating the timer, not in dealloc, but just before the BDObject is removed from the objects array.

It was news to me that timers retain both their object arguments.

http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSTimer_Class/Reference/NSTimer.html