Nobody learns if nothing is brok3n

Here's my solution (WARNING SPOILERS):

http://boredzo.org/blog/archives/2007-01-18/weekly-cocoa-app-challenge-3-solution

I started this challenge like normal when I had the thought: this app doesn't need a nib! (ok, so no app needs a nib, but this one really doesn't need one, with the lack of a main window/menu and all) So it took me a while longer than normal to finish because I had to learn how to build an application without having a nib.

I also missed the instructions to start using #pragma... I'll read the directions better next week, I promise.

http://myztik.katan.com/?page_id=149

Where are the toolbars?!

Myztik: You don't need a nib, but if you use one, your code gets a lot shorter (the .nib can store the menu, bind events to actions and you don't need to write code for the 'close' menu entry).

Furthermore, you shouldn't call release on your NSStatusItem in your dealloc method. See the following comment from Peter's solution:

Calling -[NSStatusItem release] for the last time will cause a crash on quit. Reference: , , and my own personal experience.

Reference: http://marc2.theaimsgroup.com/?l=osx-cocoa-dev&m=105701123832261&w=2, http://trac.growl.info/ticket/295, and my own personal experience.

(seems no automatic < -> &lt; conversion takes place :-( )

Here's my attempt:

http://gtdexchange.com/source/Dude%20Package.zip

I also forgot the #pragam markers. Woe is me.

I admit I did cheat a little by snooping at the info.plist file to determine the background UI flags, sorry =o(

When I click it, it doesn't do anything (I checked activity monitor for clues). Is the challenge to make an app that doesn't do anything when it is clicked? (In general, I'm finding the context to these challenges a little too sparse).

Sorry.

It took me two evenings to figure out that the app name could be suppressed from the menubar with another key-value pair in the plist. I decided to go the route of using interface builder. The code is much shorter that way.

What did we need to use NSBundle for? You can use it to load the icon for the status bar, but imageNamed: on NSImage worked fine for me.

@rich

It's a menu item. I'm leaving the context sparse in general so that you have to actually dig around.

I just realized (after reading your comment, Norman Richards) that I probably did not use NSBundle for the purpose that Chris intended. Oops.

I suppose we'll find out on Wednesday. :)

nico,

True, using a nib would have saved a lot of coding, but I was somewhat curious as to how one could run an app without a nib. Plus, I think Chris' solution is nib-less as well.

And my app doesn't crash with the final NSStatusItem release, nor does Peter's when I run it. Perhaps the bug was fixed? Does my app crash on quit on anyone's machine?

Myztik,

One of the things I found while developing is the App delegate may not get the dealloc message called. I found an enormous debate on CocoaDev as to whether this is a bug or not. You can try it yourself in debug mode.

Just put a breakpoint on the App delegate's dealloc method. It won't get called. If you're trying to confirm nico's suspicion, try calling release earlier and see if the app crashes during close.

I... want... TOOLBARS!!! (pweeze?)

Ricky, very interesting... dealloc never gets called.

I wonder if that's because this class is the application's principal class and deallocating it would leave the app without a way to effectively quit. If I manually tell my object to dealloc in applicationShouldTerminate:, I immediately crash with

objc: FREED(id): message replyToApplicationShouldTerminate: sent to freed object=0x310860

I also read most of the prolonged debate on CocoaDev and I think the idea that non-memory resources should get cleaned up in applicationWillTerminate: and memory should be removed in dealloc is most likely correct (assuming that dealloc indeed doesn't get called on principal or nib-instantiated classes). The OS doesn't need to run your dealloc at quit because it knows its going to get back everything allocated anyways. I can see why there would be confusion.

That being said, I still can't get my app to crash by releasing the NSStatusItem, no matter where I put the release. It simply removes the menu from the statusbar when I do. And Peter's app doesn't crash because his dealloc never gets called either.

Mytztik:

I guess I should clarify about releasing the NSStatusItem. I didn't try to actually make the program crash, so I can't verify nico's suspicion. Maybe Apple patched the issue?

As far as the dealloc issue being a bug, I can understand the viewpoint that the OS recollects all memory on exit, but I have two gripes:

1.) Convention. Why not call the dealloc method? This alone just doesn't make sense.

2.) A poster in the CocoaDev thread said the dealloc call used to work in previous versions of OSX. That especially sounds fishy to me.

Anyway, just my thoughts. I was trying to go NIB-less with my code at first as well, but I couldn't quite cut it. Thanks for posting a solution taking this approach.

Once again late to the party, but I seem to have caught up. It's rather irrelevant now, I don't think I can add anything to the discussion which has not already been said, but for anyone interested in the source for my solution:

http://angrymen.org/2007/01/29/weekly-cocoa-app-challenge-3/

I just noticed this great site and wanted to post my try at it. A bit late but I am catching up.

www.blurimage.com/cocoa/DudeMenu.zip