Re: toolbar in a sheet drawing issues
Re: toolbar in a sheet drawing issues
- Subject: Re: toolbar in a sheet drawing issues
- From: Ryan Stevens <email@hidden>
- Date: Wed, 19 Jun 2002 09:27:26 -0700
Short answer: No.
More detail?
The behavior of a toolbar in a window without a title bar is undefined -
assuming you can even get it to work at all. I have no clue if Apple
will allow us more freedom with toolbars at some point but one can hope
(and hack until ;-).
I'm surprised you're allowed to put a toolbar on a sheet in the first
place. I would've thought you'd get the same "can't be done" message.
I've tried to put a toolbar in a drawer with varying degrees of success.
Of course, it's nothing but a hack - to get around the "can't be done"
message - but you might try fooling with it a bit more.
Try setting the contentView of the sheet to [yourToolbar _toolbarView]
then adding your other components to that. Past that, you're on your own
(unless you'd like to talk off-list). :-)
HTH!
On Tuesday, June 18, 2002, at 09:47 AM, Chris Giordano wrote:
The short question: Can one use a toolbar in a window being used as a
sheet?
Some more detail:
If I try to use a toolbar with a window that is used as a sheet, the
toolbar is drawn what appears to be the height of the titlebar below
the top of the sheet, overlapping the content view of the sheet. The
space at the top of the sheet starts out as just white, but upon
changing the size and content of the sheet, I'll get strange artifacts
of the previous content in that blank space. All of my attempts to
clear that space to date have been unsuccessful.
The obvious (to me, at least) solution was to create a window with no
titlebar so that the OS wouldn't try to account for that space when
drawing the toolbar. Unfortunately, that doesn't work. I've tried
creating the sheet window with many different style masks (via
NSWindow's initWithContentRect:styleMask:backing:defer: method). I get
one of two results: either I get behavior like that described above, or
I get console messages like the following (when the style mask doesn't
include NSTitledWindowMask or NSResizableWindowMask) :
ERROR: Can't have a toolbar in a window with <NSNextStepFrame:
0x19c1a80> as it's borderview
*** -[NSNextStepFrame _setSheet:]: selector not recognized
*** -[NSNextStepFrame _setSheet:]: selector not recognized
So, am I just missing something? Is this a bug in the window drawing
code? Or are you just not supposed to use a toolbar in this way, and
I'm left rewriting the toolbar code in my own view if I want that
functionality? The answer to the first questions is very possibly yes,
but I have gone through the documentation more than a few times. I've
even gone through Apple's HI guidelines to see if I really shouldn't be
doing that, but didn't see anything that prohibited it.
(And in case anyone is wondering, I'm doing this to implement
document-specific settings using a framework that I can share between
document and application settings. At the app level, I can define the
application defaults, but these can be overridden at the document
level. I've accounted for the overlapping of the content view by just
increasing the height of the content view. However, there is still the
space above the toolbar that ends up with odd artifacts
And yes, I do know about Omni's Preferences framework. I discovered it
shortly after starting on my own. And writing my own was a really good
exercise, so I've been doing what I can to build and bullet proof that.
Nevertheless, I've recreated the same results in a test application
with little more than a window and some code to create a toolbar. I
can pretty confidently say that the issue is likely not mine, but
that's part of why I'm asking.)
_______________________________________________
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.