On Thu, Mar 4, 2010 at 7:47 PM, Steven Degutis <steven.degu...@gmail.com>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 <cocoadevl...@gmail.com> wrote: > >> On Thu, Mar 4, 2010 at 6:50 PM, Steven Degutis >> <steven.degu...@gmail.com>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 <cocoadevl...@gmail.com> wrote: >>> >>>> On Thu, Mar 4, 2010 at 5:28 PM, Jens Alfke <j...@mooseyard.com> 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 (Cocoa-dev@lists.apple.com) >>>> >>>> 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: >>>> >>>> http://lists.apple.com/mailman/options/cocoa-dev/steven.degutis%40gmail.com >>>> >>>> This email sent to steven.degu...@gmail.com >>>> >>> >>> >>> >>> -- >>> Steven Degutis >>> http://www.thoughtfultree.com/ >>> http://www.degutis.org/ >>> >> >> > > > -- > Steven Degutis > http://www.thoughtfultree.com/ > http://www.degutis.org/ > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
