I re-uploaded PostCheck 2.0.4 as a universal binary (Power PC, Intel, 32/64-bit).
The problem turned out to be that I upgraded my older Mac to Xcode 3.2.6 yesterday and it wiped out all my PowerPC settings. (Great job there Apple.) I found enough references to the problem through Google to know it wasn’t just my mistake.
If anyone is actually using PostCheck 2+ on a PowerPC Mac, I’m sorry, my Xcode somehow stopped building PowerPC universal binaries. I just realized that the last two updates to PostCheck are Intel-only. This will be fixed as soon as I can figure out what’s going on…
I hate to have to put up an update so soon after I already announced another one. But a PostCheck customer brought this to my attention.
In certain cases, PostCheck might apply a “neighborhood” name to an address instead of the city name . For example: “Ohio City” instead of “Cleveland”, which is not a valid USPS address. This update fixes this.
Implemented a work-around for a bug in Apple’s Address Book in Mac OS X Lion.
I was able to track down the root of the problem that I reported on yesterday with PostCheck and Mac OS X Lion. (I would imagine it could affect any Address Book plugins.) This bug is only present in Lion (at least as of 10.7.1), all previous versions of OS X behave as expected.
Here’s how to reproduce the problem:
The result is that any previously added addresses will be erased, leaving just the newly added address. (It can be reversed using Address Book’s undo, luckily.)
All Apple Address Book plugins get called with this method after a user selects the plugin’s menu item from the context menu:
- (void)performActionForPerson:(ABPerson *)person
identifier:(NSString *)identifier
If I use NSLog() to display the details of “person”, in Lion it does not list any of the existing addresses as being part of the record, just the newly added one. In all previous versions of the OS, it properly lists all the addresses.
The work-around that I came up with is to re-lookup the person from the Address Book database:
NSString *uniqueID = [person uniqueId]; // kABUIDProperty
ABPerson *foundPerson = [[ABAddressBook sharedAddressBook] recordForUniqueId:uniqueID];
“foundPerson” will contain all the addresses, unlike the “person” object that is passed to the plugin to begin with. I don’t understand why this works this way but I’m glad it does until the bug is fixed.
I’ve run across a reproducible bug with PostCheck 2.0.2 and Lion. If you add a new address to a contact that already has an address and then use PostCheck to check the new address, Address Book will erase the previously existing address for some reason. I cannot reproduce this in older versions of Mac OS X.
If this happens, you can use Address Book’s undo to revert the change. The temporary work-around is to add the address and quit Address Book so that it saves the changes. Then you can use PostCheck.
I’m looking into the problem now to see if it’s something that I can control.
I don’t know if this is common knowledge, but it took me a while to figure out and I didn’t find anything obvious about it online.
I’ve been writing an Objective-C (Cocoa) front end for a Javascript API and it involved a lot of two-way communication and passing WebScriptObjects around. (A WebScriptObject just being an Objective-C instance of a Javascript object.)
Anyway, my “discovery” is how to properly return a useful value using evaluateWebScript: instead of always using callWebScriptMethod:withArguments: with pre-made Javascript functions.
The simplest example is if I want to call evaluateWebScript: to return a WebScriptObject representation of a new Javascript object literal:
NSString *myObjectDef = @”{ property1: 10; property2: 12 }”;
NSString *script = [NSString stringWithFormat:@”var newObj = %@; newObj;”, myObjectDef];
Passing that script to evaluateWebScript: will return the value of “newObj” as a WebScriptObject that can be passed to other Javascript functions or inspected with valueForKey:.
PostCheck 2 is fully Lion compatible.
Fixed a bug where PostCheck may return Michigan (and corresponding ZIP Code) for addresses in Minnesota. I’m not aware of this bug affecting any other states at this time.
Turns out this bug was reproducible in PostCheck 1.9.2 as well. If ‘Minnesota’ were spelled out as the state - under certain conditions ‘Michigan’ would be returned as the new state. I’m guessing that the USPS saw the ‘Mi’ at the beginning of ‘Minnesota’ and just ignored the rest in cases where there was a matching street address. (There’s lot of little issues like this with the USPS APIs.)
I hope this bug didn’t affect too many users or cause too many problems.
Fixed a bug where a ZIP Code might not be looked-up on the first try.
