On Thu, Mar 4, 2010 at 8:10 PM, Steven Degutis <steven.degu...@gmail.com>wrote:
> 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 > Well, I'm kind of desperate, so I'll give it a try. And file a radar. Thanks. F. On Thu, Mar 4, 2010 at 2:01 PM, fabian <cocoadevl...@gmail.com> wrote: > 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/ >> > > -- 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
