Scott Gruby's Blog

I had a user send me email the other day indicating that his copy of ReceiptWallet was already registered and he couldn’t enter his newly purchased registration code. He sent me a screenshot of the about box which shows the registration code and I ran the code through my database to discover a) it was never issued and b) it is in the wrong format to be a valid code. Hmmm. When I was at Macworld, I spoke to an engineer at eSellerate who indicated that their serial number library was updated to be more secure as there have been some cracks out there of it; I still use the library as some of my users purchased way back when I used eSellerate to process my sales. So, it would appear that there is a cracked serial number for DocumentWallet (and now ReceiptWallet) floating out there.

Should I be concerned? Not really. I know that software is pirated and just take that as a given. If I spent huge amounts of time building in super-duper code to handle piracy, I couldn’t spend time on the stuff people care about. I worked for a company way back when that spent so much time on anti-piracy, that they neglected to fix issues in the product and had few customers to show for it. I have blocked the serial number from use in future versions, but I’m sure it will get cracked again.

(Yes, I know I could do server side validation of registration codes and block them, but this gets people a bit paranoid if I go out of business, their software stops working. So, I’ll live with piracy.)

Back to the user; I’m not sure if I’ll hear from him again. While I didn’t accuse him of piracy, I did ask him questions about how long he’s been using the product as his original email indicated he had problems upgrading from DocumentWallet. Since he purchased ReceiptWallet last week, he either wasn’t using the product for the last 3 weeks (since ReceiptWallet 2.0 came out) or he was using DocumentWallet with a hacked code.

I find that a majority of the crash reports that come in for ReceiptWallet have the following for the description:

Yes, they are blank! While I appreciate people sending in crash reports (I read everyone of them and try to figure out the problem), having no description makes it much harder to figure out the problem. Today I received a blank description, but in reading the report, I was able to “reproduce it” (hard to reproduce when I wasn’t told what happened) and quickly fixed it. I’m contemplating making description a required field for the report; this could reduce the reports which I don’t want as it would give me a false view of how many crashes people are getting.

Thanks to Jim Correia of Bare Bones Software, I have a slightly different method for filtering NSTextFields based on an NSFormatter. While my older method worked, this is a bit cleaner.

Like my old filter, this also has three methods:

- (void) setAcceptableCharacterSet:(NSCharacterSet *) inCharacterSet;
- (void) setMaximumLength:(int) inLength;
- (void) setMaximumValue:(int) inValue;

However, they’re called differently. You’d do something like this:

NSMutableCharacterSet *characterSet = [[NSMutableCharacterSet alloc] init];
[characterSet addCharactersInString:@"0123456789"];
[secondaryTextField setFormatter:[[[PartialFormatter alloc] init] autorelease]];
[[secondaryTextField formatter] setMaximumValue:65535];
[[secondaryTextField formatter] setAcceptableCharacterSet:characterSet];
[characterSet release];

Note that the formatter is based on NSFormatter and not NSNumberFormatter. I actually am using this for a number field as I want the number field to give me back a string instead of a number, so that’s why I put in the setMaximumValue and didn’t base it on NSNumberFormatter.

As always, feedback is welcome.

The attached code can be freely used in commercial and non-commercial projects. While I’d like some credit in the about box, it isn’t necessary. This code has no warranty and you assume all risk for using it.

Download source

I love Cocoa, but it seems that some simple things are missing. For example, NSTextField doesn’t have the ability to filter text input as the user is typing. A friend reminded me that this is a feature that PowerPlant had ages ago. Cocoa has NSFormatters which allow the field to be validated after text is input, but in many cases, the right way to restrict input is to prevent it from being typed. I like NSFormatters and have created a very complex one to handle multiple currencies in ReceiptWallet, but I realized I needed something else.

So, I present FilteringTextField. The attached code can be freely used in commercial and non-commercial projects. While I’d like some credit in the about box, it isn’t necessary. This code has no warranty and you assume all risk for using it.

The subclass of NSTextField, has 3 methods.

- (void) setAcceptableCharacterSet:(NSCharacterSet *) inCharacterSet;
- (void) setMaximumLength:(int) inLength;
- (void) setMaximumValue:(int) inValue;

The first lets you set the characters that can be typed; anything that isn’t in the set is eaten. The second, only allows x characters to be typed and the last limits the value if the user is typing in a number. This class can easily be extended to handle other constraints. Pasting in text is also filtered.

If anyone finds problems with this code, please let me know.

Download source