Comments on: NSProgressIndicator in NSTableView or NSOutlineView

By: bdunagan

bdunagan — Thu, 18 Aug 2011 10:42:54 +0000

@Jonathan Ah, thanks for pointing that out.

By: Jonathan

Jonathan — Wed, 17 Aug 2011 14:21:01 +0000

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

By: Tristan

Tristan — Sat, 08 Jan 2011 17:16:34 +0000

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.

By: bdunagan

bdunagan — Sat, 08 Jan 2011 17:01:35 +0000

@Tristan Completely agree. I’ve meant to update that code for years, but still haven’t gotten around to it. I’ll take a look at it soon.

By: Tristan

Tristan — Sat, 08 Jan 2011 16:30:41 +0000

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

By: cristik

cristik — Tue, 26 Jan 2010 14:27:27 +0000

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.

By: Vladimir Solomenchuk

Vladimir Solomenchuk — Sun, 24 Jan 2010 23:05:57 +0000

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]; }

By: bdunagan

bdunagan — Sun, 11 Oct 2009 18:39:46 +0000

You can make bindings work in this case, but I still find I need to compose the progress into the model rather than into the cell. The problem with cell composition is there is only one progress object because of cell reuse, and multiple cells try to draw it at the same time. Please post a comment if you know how to do it. Thanks!

By: fill the void – Syncing Arrows in iTunes

fill the void – Syncing Arrows in iTunes — Sat, 26 Sep 2009 05:54:17 +0000

[...] 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 [...]

By: Simon Ward

Simon Ward — Mon, 14 Sep 2009 04:11:33 +0000

Can it be done with bindings instead of a datasource?