musicwind95 wrote:
The icon is not changing, even though I've added the image and set it in the .plist.
OS X apps like .icns files. For best results, follow the instructions under [Create an Icon File|http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjC Tutorial/08Configuring/08Configuring.html#//apple_ref/doc/uid/TP40000863-CH10-SW 16] in +Cocoa Application Tutorial+. Be sure not to skip step 5 under "To add the icon to the project:". When you enter the icon file name in Target Info->Properties, Info.plist will be populated correctly (It might be best to start with a blank value for the Icon file key in that plist).
How would I know if the class name is already taken?
Normally you should get a compiler error if one of your class names conflicts with another class name or some other type identifier.
Is there a global class-name search function in XCode?
Well Xcode will search for identifiers of many kinds (see [Searching in a Project|https://developer.apple.com/mac/library/documentation/DeveloperTools/Co nceptual/XcodeProjectManagement/150-Searching
Files_and_Projects/searching_files_and_projects.html#//appleref/doc/uid/TP40002669-BABFCHDJ] in the +Xcode Project Management Guide+, but it's essential for the compiler to rule out an ambiguous class name, so that search is done automatically as part of the build.
To be clear on this point, the problem you experienced with 'Zone' should never have occurred without a compiler warning. If you're interested in pursuing this, try to build the smallest possible project which will exhibit the problem, then either file a bug yourself or post that code in a new topic here and maybe also in the [Apple Mailing Lists|http://lists.apple.com>. Either Eric Meyers or Mark Szymczyk could probably tell you why there was no warning and whether a bug should be filed.
What does 64-bit have to do with it?
Referring to the excerpt from MacMemory.h in my last post, the Zone type declared in that file is switched out when
_LP64_ is defined. That macro is one of the switches used to make the SDK support 64-bit operation. Therefore I assume the declaration I posted wasn't seen by your compiler. Yet your results were consistent with an ambiguous identifier. Could there, for example, be a missing
_LP64_ switch in an implementation file? I suggested changing the name of that class, not because I knew what was going on, but because I assumed you were in a 64-bit environment, and here was a 64-bit compiler switch that was controlling the visibility of something that could explain the problem. Does that make sense?
I think I"ve covered everything you asked except for the question about Shark. If it doesn't startup and analyze your code as advertised, I guess we can assume it's not installed correctly or not installed at all. Maybe another thread on that topic would find someone with direct experience.
\- Ray
