Re: NSProgressIdicator Image Problems
Re: NSProgressIdicator Image Problems
- Subject: Re: NSProgressIdicator Image Problems
- From: Glen Simmons <email@hidden>
- Date: Mon, 30 Jun 2003 12:15:42 -0500
On Monday, June 30, 2003, at 11:30 AM, Thomas Finley wrote:
On Monday, June 30, 2003, at 11:04 AM, Duncan Oliver wrote:
[snip]
is that the picture I grab is grayed out, and I can't figure out why.
Grabbing an image for a static progress indicator via a outlet
produces a proper picture, so I can't figure it out. Here's some code
for creating the picture.
The reason is simply that what you call the static progress indicator
was in the active view hierarchy. Like many controls, PIs display
themselves differently depending on whether they're part of the
frontmost window or not. The progress bar you have dynamically
created is not in the hierarchy -- is in no hierarchy at all, in fact
-- so it is drawn as though it were in a background window.
While you might be able to fool it somehow, there's an much cheaper
way. In fact, you've already said what you should do: get the image
from a progress bar that's already in the window where the outline
view is. Make it an outlet of your outline view data source.
Position it outside the visible region of the window, and no one will
no better. This has several advantages: when you get the image, it
will automagically correctly draw its enabled/disabled version based
on whether the outline view is in the top-level window or not. You
also avoid the overhead of continually allocating progress bars.
Incidentally, that code has a lot of memory leaks. You never released
your progress bar, you create one whether you'll need it for that
column of the outline view or not, and you should autorelease the
image before you return it.
Now, that's an answer to your question, but I am not sure I like this
whole image thing; it would probably be pretty slow. Couldn't you
create your own custom cell subclass for use in your outline view, and
when drawing the cell simply pass off the drawing to a progress bar?
That's a bit harder, but it would probably be worth it if you have a
lot of these things.
That's the way I did it, and it works great, except for a couple of
things. First, NSTableView / NSOutlineView apparently cache whatever is
drawn in a cell instead of repeatedly calling the NSCell's
-drawWithFrame:inView: method. This is fine for static data, but for a
progress indicator, you end up with jitter as the progress indicator is
increasing. My guess is that the PI draws itself and then the TV/OV
draws the cached, stale image. Just a theory. Also, artifacts are left
behind when the column is moved or resized, apparently because the PI
is drawing when the table/outlineview is not expecting it to. But, the
cell is not notified when it's about to be moved or resized.
Second, (and this is related to #1) your subclass of NSCell is told
when to draw, but it's not told when *not* to draw. i.e. when an
outlineview item is collapsed, the outlineview doesn't notify the
cells, it just redraws the view the way it thinks it ought to be. Once
again, great for static info, not so good for actual subviews like a
progress indicator. You end up with a PI in the wrong spot or just
hanging in space, merrily doing it's thing. This seems solve-able, but
only in fairly hacky ways. As a lightweight object, it just seems wrong
for an NSCell to have to know about the inner workings of an
outlineview that it happens to be part of.
I'd be happy to hear any suggestions.
Glen
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.