That’s all! Building OpenSSL from within Xcode should now work as expected.

Have fun!

People still using older Versions of Xcode 4, may read on …

Finally Xcode 4 is here and the days of Version 3 are almost part of history.

There was one nifty feature that I liked very much in Xcode 3. It’s “Focus follows selection”. This feature was supposed to be in Version 4, since it can be found in the “Editor Menu” of Xcode 4, but oddly it’s always disabled. Even in Xcode 4.1 and 4.2 (beta).

So far for the bad news, but now for the good news: This feature is still available and functional in all Versions of Xcode 4. But you just can’t use the Menu to activate it. You have to open “Terminal” to do so. At the command prompt type the following:
defaults write com.apple.dt.Xcode DVTTextCodeFocusFollowsSelection -bool yes

Before you do so, make sure Xcode 4 is not running, because the setting may be overwritten when Xcode quits. After restarting Xcode “Focus follows selection” should work until you disable it with following command:
defaults write com.apple.dt.Xcode DVTTextCodeFocusFollowsSelection -bool no

With “Focus follows selection” enabled you can now fully concentrate on the block of code you’re working on – Even with Xcode 4!

[aView setHidden:YES]; // Hide the view
// very important code....
[aView setHidden:NO]; // Un-Hide the view

To do the same thing with a short and smooth animation, you just have to change the above code to the following:

[[aView animator] setHidden:YES]; // Hide the view with animation
// very important code....
[[aView animator] setHidden:NO]; // Un-Hide the view with animation

(For some animations, like subview transitions, aView has to be layer-backed which can be accomplished with a call to [aView setWantsLayer:YES];)

So far so good. But what, if aView is a custom subclass of NSView, NSBox or whatsoever?

Normally, this is not a problem, since the object returned by [aView animator] is a proxy object for the original object and can be treated as if it was the original object itself.

But, there is a difference! If you call setHidden:YES on the original object, it gets called, regardless of the actual “hidden-state” of the view. If you call it on the proxy-object, it gets called only, if the value really changes. So calling setHidden:YES on an animator-proxy, which original-object is already hidden, has no effect at all.

This behavior can be ignored, as long as you do not overwrite any of the methods that change animateable properties, like setHidden:. But if you do, keep in mind, that your overwritten method may not be called while using the animator-proxy. In some cases, were you depend upon the fact, that your method gets always called, this can be a problem e.g. if you always want to do something in your setter, regardless of what the actual state or value is.

Even if you don’t subclass, there are side effects you’d never thought possible.

A few days ago I ran into a tricky problem while working on my iTunes-Controller Playwatch. After spending some time debugging I came to the conclusion that only multiple calls to the “initialize-method” could cause the problem.

Apple’s documentation states, that initialize is called only once. If you create subclasses of your class, initialize gets called for each subclass. If the subclass does not implement it, the call is forwarded to the superclass. This is the exception to the rule. If you subclass, initialize of your superclass maybe called more than once. To avoid double initialization, the documentation recommends to check the class-instance and do initialization only if it’s the correct one.

Here’s the code:

@implementation MyClass
+ (void)initialize
{
	if(self == [MyClass class]) {
		// Do initialization here....
	}
}
@end

Since I did not have any subclasses, I thought I could run without this check. Far wrong! To find out what was going on, I set a breakpoint at initialize. The debugger stopped once, and a second time. Even with no subclasses. How could that be? A look at the Variable “self” shed some light on this miracle.

The first time the stack and the variable looked like this: (Click on the images to see full resolution)

The second time the result was as follows:

The first call to initialize is on the class “PWCoverArtAndTracks”. The second one is on the class “NSKVONotifying_PWCoverArtAndTracks”.

All right! The AppKit did create a subclass because I use the tracks-array of “PWCoverArtAndTracks” as the content binding for a NSCollectionView. As you can see at the picture below.

This is an implementation detail of CocoaBindings. I can remember reading something about this detail in the Apple Docs. But that remembrance was almost vanished at the time I wrote the initialize method.

Here’s my advice: Always check the class within initialize. Even if you don’t have subclasses.