Re: Uninitialized rectangle??
Re: Uninitialized rectangle??
- Subject: Re: Uninitialized rectangle??
- From: Steven Degutis <email@hidden>
- Date: Thu, 4 Mar 2010 14:10:30 -0500
NSStatusItem's -view and -setView: methods are related to your own custom
view, and have nothing to do with the view it internally uses. Thus, it
initially has no view until you give it one. So, giving it a dummy view via
[statusItem setView: [[[NSView alloc] init] autorelease] ] is going to allow
you to access that view's -window and thus the -frame of the NSWindow. Keep
in mind though that this is a hack, and also usually very unnecessary and
bad and against the HIG in the first place.
-Steven
On Thu, Mar 4, 2010 at 2:01 PM, fabian <email@hidden> wrote:
> On Thu, Mar 4, 2010 at 7:47 PM, Steven Degutis <email@hidden>wrote:
>
>> Right. Have you tried the solution I proposed in the /very first reply/ to
>> this thread?
>>
>> -Steven
>>
>>
> Actually, no. I don't have 10.5.8, so I would have to send it to one of the
> end-users to try, and I feel hesitant to bother a customer without having a
> clue _why_ the changes made to the code would make any difference. I did
> send you a reply, though, asking why you think feeding a dummy view to the
> status item would give better results. I'm not questioning your suggestion,
> I'd just like to hear the arguments for it before proceeding.
>
>
>>
>> On Thu, Mar 4, 2010 at 1:05 PM, fabian <email@hidden> wrote:
>>
>>> On Thu, Mar 4, 2010 at 6:50 PM, Steven Degutis <email@hidden
>>> > wrote:
>>>
>>>> Are you sure that your NSStatusBar or NSStatusItem instances are nil,
>>>> and not just what's returned from -view? I see no reason that it should be
>>>> nil, and no proof that it is. (To be fair, I only skimmed this mess of a
>>>> thread.)
>>>>
>>>> -Steven
>>>>
>>>
>>> No, I'm not. It just boiled down to this assumption along the way
>>> somehow. Perhaps to make the thread less messy :)
>>>
>>> But you are absolutely right: all I know for sure is that whatever is
>>> returned from [view frame] is causing the "unitialized rectangle" assertion
>>> failure.
>>>
>>>
>>>
>>>> On Thu, Mar 4, 2010 at 12:05 PM, fabian <email@hidden>wrote:
>>>>
>>>>> On Thu, Mar 4, 2010 at 5:28 PM, Jens Alfke <email@hidden>
>>>>> wrote:
>>>>>
>>>>> >
>>>>> > On Mar 4, 2010, at 12:42 AM, fabian wrote:
>>>>> >
>>>>> > > Right. But why should it matter? The system status bar is not in
>>>>> the nib.
>>>>> > Just curious about what is going on behind the scenes...
>>>>> >
>>>>> > The status bar is in the menu bar, and the menu bar is in the same
>>>>> nib as
>>>>> > your app controller. The status bar probably initializes itself in an
>>>>> > -awakeFromNib method. Whether that method runs before or after your
>>>>> > -awakeFromNib method is completely unpredictable.
>>>>> >
>>>>> > > I can see why it's a bad thing in theory, but I haven't had any
>>>>> problems
>>>>> > with this approach.
>>>>> >
>>>>> > Are you prepared to have your app crash and burn on launch for every
>>>>> user
>>>>> > that installs some upcoming OS revision (perhaps even a minor
>>>>> update)? I'm
>>>>> > serious; this happens. Doing things that shouldn't work, just because
>>>>> they
>>>>> > do work at the moment, is asking for trouble since the underlying
>>>>> behavior
>>>>> > of the system frameworks can change in the future.
>>>>> >
>>>>> > (This is especially painful if you're not on the expen$ive Apple
>>>>> developer
>>>>> > plans that get you access to OS betas, because that means you won't
>>>>> get a
>>>>> > chance to find any of these crashes before your customers do. Instead
>>>>> you
>>>>> > find yourself frantically debugging on the day the new OS comes out,
>>>>> while
>>>>> > your mailbox fills up with crash reports and complaints.)
>>>>> >
>>>>> > > Anyway, back to subject. Perhaps a better approach than using
>>>>> timers,
>>>>> > guesswork and voodoo, would be to check the validity of the frame
>>>>> rect and,
>>>>> > if it's zero or garbage, make my own rectangle.
>>>>> >
>>>>> > Um, no. Check whether the status bar is nil before you ask for its
>>>>> frame,
>>>>> > instead of working around the aftermath of calling a struct accessor
>>>>> on nil.
>>>>> > But doing this is still a hack, for the reason I described above.
>>>>> It's
>>>>> > pretty clear that you shouldn't be doing anything with NSStatusBar in
>>>>> an
>>>>> > -awakeFromNib method in the main nib.
>>>>> >
>>>>> > —Jens
>>>>>
>>>>>
>>>>> But this is not in -awakeFromNib. That's the whole problem :)
>>>>>
>>>>> It's in -applicationDidFinishLaunching. Which works great on all
>>>>> systems (as
>>>>> far as I know), except for on 10.5.8 where NSStatusBar is still nil at
>>>>> this
>>>>> point. That's what I'm trying to find a work-around for.
>>>>> _______________________________________________
>>>>>
>>>>> Cocoa-dev mailing list (email@hidden)
>>>>>
>>>>> Please do not post admin requests or moderator comments to the list.
>>>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>>>>
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>>
>>>>> This email sent to email@hidden
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Steven Degutis
>>>> http://www.thoughtfultree.com/
>>>> http://www.degutis.org/
>>>>
>>>
>>>
>>
>>
>> --
>> Steven Degutis
>> http://www.thoughtfultree.com/
>> http://www.degutis.org/
>>
>
>
--
Steven Degutis
http://www.thoughtfultree.com/
http://www.degutis.org/
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden