Re: Panel items failing to draw
Re: Panel items failing to draw
- Subject: Re: Panel items failing to draw
- From: "Louis C. Sacha" <email@hidden>
- Date: Wed, 28 Apr 2004 14:55:33 -0700
Hello...
Generally, these kinds of things tend to happen when you are doing
one of two things:
1) Drawing in your view outside of the drawRect: method
or
2) Have views which overlap at the same point in the view heirarchy
If you haven't already, it might be a good idea to read through the
Cocoa Conceptual topic on "Drawing and Views":
http://developer.apple.com/documentation/Cocoa/Conceptual/DrawViews/index.html
The "Displaying Views" and "The View Hierarchy" subtopics are
probably the most relevant to your problems.
Specifically, you normally do not draw in your view outside of the
drawRect: method. In the past, you may have used Quickdraw to draw
into a graphics port wherever and however you liked, but in Cocoa you
would instead just tell the view that it needs to be drawn by using
setNeedsDisplay: or a similar method, and wait for the drawRect:
method to be called. All of your drawing commands would be contained
in the drawRect: method, and your view would know how to draw itself
(and/or contain subviews or use cells that knew how to draw
themselves).
Instead of having the code which draws in the view spread throughout
your other code, it is located in the NSView subclass in the
drawRect: method. The drawRect: method should know how to draw the
whole view, but you can make optimizations so that it only draws the
specific parts that are necessary.
If you are using some sort of "background" view in your panel, and
you have placed the buttons or text labels on top of that view, the
normal drawing/invalidation procedure does not always work correctly.
From the "View Hierarchy" subtopic:
"For performance reasons, the Application Kit does not enforce
clipping among sibling views, or guarantee correct invalidation and
drawing behavior when sibling views overlap. If you want a view to be
drawn in front of another view, you should make the front view a
subview (or descendant) of the rear view."
InterfaceBuilder should allow you to place the buttons as subviews of
the other view (in fact, if you tried to drag an NSButton on top of a
view which is a "custom view" NSView, the button would become a
subview of the NSView automatically). You can still set up
connections in interface builder normally to both the view and the
NSButton subviews, so it terms of interacting with them using
IBOutlets it generally wouldn't make a difference to your code.
If you are using NSQuickdrawView, NSMovieView, or NSOpenGLView, then
it is not quite as easy. I don't know if there is a technical reason
behind it or if it's just that the "container" code is only
implemented specifically for NSView in IB, but you can get around
this limitation fairly easily.
You can drag the normal NSView "Custom View" from the IB Pallete and
into your window instead of the NSQuickdrawView (or other type). Then
just select the appropriate view class in the custom class pane of
the inspector, the same way you would have done before if you were
subclassing NSQuickdrawView (there are quite a few more choices, but
all the known view types will be in the list). Now, when you drag a
new NSButton from the IB pallete and drop it inside the view you just
added, it will automatically become a subview of the view. If you
look at the outline view of your nib, it should show the button as a
child of your QDView.
If you drag an existing view from somewhere else on the window, it
does not automatically become a subview of the NSView, so you either
need to create a new object or do a copy drag. Either way you will
need to redo the connections.
Hopefully some of that helps,
Louis
> If you just open a window with
some controls from a nib file, you shouldn't have to do anything like
that.
That's all I am doing in the windows I've seen the problem in.
Try to isolate a small reproducible case and post it to the list.
I wish I could, but as it is, I only see the problem maybe once out of
dozens of tries.
Thanks for you input,
Eric
_______________________________________________
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.