Brian Toth

PostCheck 2.2

Tue, 06 Mar 2012 21:44:15 -0500

Stopped trying to merge Google results with the USPS results. It was proving to be too unreliable. Now, only USPS results are used to standardize addresses (like in PostCheck version 1). If an address cannot by found in the USPS database, possible suggestions are still provided.
Added preferences for controlling street and city abbreviations. You can individually unabbreviate USPS standard street abbreviations. You can also apply your own custom unabbreviations for city names.

Google Maps Plugin 2.8

Sat, 28 Jan 2012 20:23:29 -0500

My first Google Maps Plugin update in three years. I had to implement a work-around for a bug in Apple’s Address Book Framework in Lion. The same work-around I did for PostCheck 2.0.3. Now the directions window should select the correct address that you clicked on.

PostCheck 2.1.2

Fri, 04 Nov 2011 20:25:12 -0400

PostCheck 2.1.2

PostCheck 2.1.1

Thu, 27 Oct 2011 12:17:31 -0400

PostCheck 2.1.1

Steve Jobs.

Wed, 05 Oct 2011 23:09:56 -0400

I could spend a long time writing all the Apple-related stories that have impacted my life. It’s amazing to think about how much would be different if Steve hadn’t accomplished all he has.

PostCheck 2.1

Tue, 04 Oct 2011 19:48:02 -0400

PostCheck 2.1:

Includes a proper (I hope) bug fix for the city name issues. Also includes the previously mentioned new feature where PostCheck will suggest possible matches for your address if there’s more than one possible. I felt this warranted a more noticeable version number.

Please report any bugs, they’re very helpful in tracking down special cases with certain addresses. And thanks to everyone that has submitted addresses for testing.

I know there’s a few bugs with city abbreviations in the...

Mon, 03 Oct 2011 22:12:33 -0400

I know there’s a few bugs with city abbreviations in the current version of PostCheck. The upcoming update should take care of that issue once and for all. I’ve also implemented a new feature…

PostCheck 2.0.6 Put Back Up

Sun, 02 Oct 2011 14:54:35 -0400

2.0.7 didn’t accomplish what I wanted, I found a copy & paste error that would lead to it’s own problems. Fix coming…

PostCheck 2.0.7

Sun, 02 Oct 2011 13:10:32 -0400

PostCheck 2.0.7:

PostCheck 2.0.4 didn’t completely fix the issue with “neighborhood” names showing up instead of proper city names. This should take care of that. (Please report if it doesn’t.)

Sorry for the back-to-back bug fixes. I’d rather get the fixes out as soon as possible as they come in.

PostCheck 2.0.6

Fri, 30 Sep 2011 20:43:04 -0400

PostCheck 2.0.6

PostCheck 2.0.5

Fri, 16 Sep 2011 19:21:55 -0400

PostCheck 2.0.5:

The main fix with this is improving performance for group lookups. Tested successfully with 12,000+ contacts. Before, it was just way too slow to be useful.

The technical reason behind this is that I was using NSCollectionView, which has horrible performance. For this version I’ve replaced it with a classic NSTableView, which performs great.

PostCheck 2.0.4 Universal Binary

Sun, 11 Sep 2011 18:28:58 -0400

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.

Where'd My Universal Binary Go?

Sun, 11 Sep 2011 17:53:24 -0400

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…

PostCheck 2.0.4

Sun, 11 Sep 2011 13:18:56 -0400

PostCheck 2.0.4:

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.

PostCheck 2.0.3

Sat, 10 Sep 2011 15:15:59 -0400

PostCheck 2.0.3:

Implemented a work-around for a bug in Apple’s Address Book in Mac OS X Lion.

Lion Address Book Bug in Detail

Sat, 10 Sep 2011 15:13:01 -0400

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:

Create an Address Book record with one or more addresses.
Quit Address Book.
Open Address Book to that same record.
Add a new address.
Use PostCheck on that new address.

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.

PostCheck & Lion Bug

Fri, 09 Sep 2011 22:13:38 -0400

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.

Returning from WebScriptObject evaluateWebScript:

Sun, 28 Aug 2011 19:46:09 -0400

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.

Wed, 20 Jul 2011 11:52:08 -0400

PostCheck 2 is fully Lion compatible.

PostCheck 2.0.2

Wed, 15 Jun 2011 15:13:00 -0400

PostCheck 2.0.2:

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.