Eric Roller's blog

Thursday, September 17, 2015

Auto-generating the Storyboard.strings File

This is what I now use to auto-generate the default Main.strings file for my “Base”-localized storyboard.

Basically, whenever the storyboard file is updated, I re-generate the strings file. Most of the time, the resulting strings file doesn’t change, but when it does, I use Xcode’s version editor to highlight the changes since my last (version control) check-in. I can then make the appropriate changes to the other strings files for all the languages that the project supports.

Here is the build-phase script to Xcode: [Read More…]

Monday, February 14, 2011

Mac OS X 10.4 SDK: crt1.o w/o -mlong-branch

Compiling an application for the MacOX10.4u SDK (with Xcode 3.2.4, GCC 4.2.1) results in this linker warning:

ld: warning: object file compiled with -mlong-branch which is no longer needed. To remove this warning, recompile without -mlong-branch: /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/crt1.o

This is not a critical issue and can be ignored. However, it can also be fixed as shown by an answer from Bernhard Baehr on lists.apple.com:

What needs to be done is to recompile the Csu package which can be found on Apple’s opensource archive, e.g. the one for 10.4.11 x86 where the -mlong_branch flag has already been removed:

Then it’s just a question of recompiling it:

cd ~/Downloads
tar zxvf Csu-71.tar.gz
cd Csu-71
make RC_ARCHS="ppc ppc64 i386 x86_64"

Then we can replace the (stripped) object file in the SDK:

cd /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/
sudo mv crt1.o{,.org}
sudo strip -S ~/Downloads/Csu-71/crt1.o -o crt1.o
sudo chmod 644 crt1.o

Thursday, March 5, 2009

Illegal NSTableView data source error when using content binding

On Mac OS X 10.5 (Leopard) it appears to work fine, but when I quit my app, on a machine running 10.4 (Tiger), these messages appear in the Console:

2009-03-03 21:49:10.680 MyApp[6793] *** Illegal NSTableView data source
    (<MyApp: 0x1b1b8b0>). Must implement numberOfRowsInTableView: and
2009-03-03 21:49:23.139 MyApp[6793] *** -[NSCFString count]:
    selector not recognized [self = 0x1bc7f00]
2009-03-03 21:49:23.140 MyApp[6793] Exception raised during posting
    of notification.  Ignored.  exception: *** -[NSCFString count]:
    selector not recognized [self = 0x1bc7f00]

The interesting fact is that the MyApp class is the delegate of the NSTableView since it implements support for drag & drop. However, it is not designed to be the data source for the NSTableView. Instead, I use an NSArrayController through a binding in the NSTableView instance. This works fine until one quits.

What I suspect is happening (on Tiger) is that the NSArrayController is purged before the NSApp, which suddely remains as the only data source of the NSTableView, but without the access methods implemented.

The solution would be to implement dummy methods in the MyApp class for numberOfRowsInTableView: and tableView:objectValueForTableColumn:row: where one returns 0 and nil, respectively.

Thursday, August 2, 2007

NSUserDefaults does not synchonize?

The goal is to access the preferences of a second application and to be able to change those preferences. I thus tried:

theDef = [[NSUserDefaults standardUserDefaults] retain];
[theDef addSuiteNamed:MyHelperAppDomain];

However, when a setting was changed and when I instruct the NSUserDefaults class to synchronize, the changes are not saved in the MyHelperAppDomain. This is because addSuiteNamed: only adds the settings from that domain; it does not change the domain!

How did I find the mistake? Tried this command in the Terminal:

> defaults find DateFormat
Found 1 keys in domain 'se.tredje.myapp': {DateFormat = "%+"; }
Found 1 keys in domain 'MyHelperApp': {DateFormat = "%F"; }

To change the preferences for a different application domain, I have found this alternative:

CFPreferencesSetAppValue( (CFStringRef) DefaultDateFormat,
    (CFStringRef) DefaultDateFormatDefault,
    (CFStringRef) MyHelperAppDomain );
CFPreferencesAppSynchronize( (CFStringRef) MyHelperAppDomain );

Wednesday, August 16, 2006

SenTestingKit/SenTestingKit.h: No such file or directory

Encountering the above Xcode error when trying to build a Unit Test Bundle target usually means one of two things:

For the latter case, a possible solution is to set SDKROOT to "" (an empty string) for the testing target. Alternatively, one may add a link to the framework inside the/Developer/SDKs/<version>/System/Frameworks directory. However, trying that only triggered the next problem:

…MyApp: [NSBundle load] … EXC_BAD_ACCESS (0×0001)KERN_INVALID_ADDRESS (0×0001) at 0xfffffffc
/Developer/Tools/otest exited with error code 11 (it may have crashed)

It turns out that one should not try to run a unit test framework with settings other than ARCHS=$(native_arch), i.e. on a MacBook Pro, it should be “i386”.

A follow-up problem is that one cannot test items with third-party libraries that do not support the same architecture (e.g. libeSellerateObjC.a, version 3.6.3, is only “ppc”).