Re: Uninitialized rectangle??
Re: Uninitialized rectangle??
- Subject: Re: Uninitialized rectangle??
- From: Steven Degutis <email@hidden>
- Date: Thu, 4 Mar 2010 13:47:56 -0500
Right. Have you tried the solution I proposed in the /very first reply/ to
this thread?
-Steven
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/
_______________________________________________
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