Eye candy feature added to ReceiptWallet!

In order to add some “bling” to ReceiptWallet, I used Apple’s CovertFlow example code to create a CoverFlow like view in ReceiptWallet. At this point, I’m not sure how useful it is, but it sure looks cool!

It’s in the latest beta of ReceiptWallet (and DocumentWallet), so go ahead and grab it and let me know what think!

CoverFlow.png

Relented on beta warnings

Well, my attempt to keep people from shooting themselves in the foot when upgrading to the beta version of ReceiptWallet has back fired. I’ve had few people download it (partly because of mistakes I made) and others have had problems reading the text. So, I’ve relented and now allow automatic updates. However, the first time a new beta version is run, the user is presented with a warning that hopefully makes things clear.

BetaWarning.png

I’ll see how this pans out in terms of people trying the beta.

Time Machine saved me again!

I’m quite religious about my backups, but luckily haven’t had to use them except for a whole hard drive failure several years back. However, today, QuickBooks 2007 for the Mac ate my data file and required me to use Time Machine again. I lost 1 invoice and 1 payment which I just entered, so restoring wasn’t bad. This is twice in 1 week that I’ve had to use Time Machine. I’m glad it is there, but am a bit nervous that I’ve had such bad luck this week.

Furthermore, QuickBooks has some problems with Cocoa bindings as demonstrated by an error in the console log:

2/2/08 7:03:18 PM QuickBooks 2007[36756] An instance 0x17820a30 of class QBCompanyFileDoc is being deallocated while key value observers are still registered with it. Observation info is being leaked, and may even become mistakenly attached to some other object. Set a breakpoint on NSKVODeallocateBreak to stop here in the debugger. Here’s the current observation info:
(
Context: 0x148b42a0, Property: 0x179987a0>
)

I ran into this the other day with ReceiptWallet, but using my binding debug object, I was able to solve it. I guess Leopard got more strict on things like this and is now logging errors. Will Intuit fix this and make QuickBooks more stable? There was recently reported a huge data loss issue with the product which I didn’t think affected me. I hope this isn’t another data loss issue. Of course, I can’t reproduce it (nor would I want to), so reporting it to Intuit is probably useless.

Do I ask for too much?

For my latest beta version of ReceiptWallet, I’ve specifically disabled the auto update mechanism by putting in a bogus link in the Sparkle feed for the actual update. Instead, in the text of the dialog, I tell people that clicking the Install Update button will fail, to read the text, and then have the real link in the text. I’ve done this on purpose as the new beta has some major changes and I really, really want people to back up their data before installing. If they can’t install the update, then their data can’t get hosed. This seems to be working. So far I’ve had 3 reports that people couldn’t install the update. This means that they didn’t read the text and just hit “Install Update”. Furthermore, whatever text I put in the dialog, no matter how large, it won’t be read. I even made the text real large as shown below. Even in the smallest window size, I think the large text would get people’s attention and then maybe they’d scroll down.

Update.png

Hmmm. Is there any use in putting text in the update dialog if people just hit Install Update? Maybe not. It’s cool that I can put whatever I want in the dialog, but maybe all I need (for normal updates) is “See our website for information about this update.”

Should I abandon my over zealousness for caution and just let people install the update without reading? If I do, there could be data loss. If I don’t, the chances of people testing will decrease.

ReceiptWallet 1.6.0 b2 Ready to Go

I’m extremely pleased to say that ReceiptWallet 1.6.0 b2 (and DocumentWallet 1.2.0 b2) are now ready for testing (b1 had 2 bugs in it). This version brings a huge change to the product in that you now can have more than 1 library. For users that don’t want more than 1 library, there will be few changes.

While the changes on the surface may look minor, I think it will bring a huge amount of flexibility to the products. People have been asking for the ability to start fresh with the new year. The multiple libraries feature will make that a reality. Each Library is actually a file package that contains the main database as well as folders for the receipts and thumbnails. Furthermore, you can copy the libraries onto a read only volume or burn to a CD and then be able to open up the library simply by double clicking.

ReceiptWallet Screenshot

I have gone to great lengths to ensure that everything works, but I’m sure I missed stuff. I’ve done most of my testing on Leopard, but done basic testing on Tiger.

If you want to give it a whirl, make sure you have the latest released version of the product, go into Preferences and change the Look for popup (in the lower right) to be Beta versions and Releases and then do a Check for Updates. When it says that there is an update, read the text CAREFULLY. You’ll have to click a link to download the beta; clicking Installing Update will fail as I want people to read. So far, the 2 people that I have had try the new version, failed to read the text which says to backup, so I think this is wise for now; a bit inconvenient, but better than losing data.

Feel free to send me feedback. I have a few more tricks up my sleeve, but they’ll wait for the next release.

UI Feedback needed

I’ve spent a significant amount of time working on the new version of ReceiptWallet. One of the changes is that information about a Library is now in a floating panel. However, I’m not happy with the buttons/look of the panel. I’m looking for ideas that people may have. Please feel free to post comments on send me email with ideas. Thanks!

Here’s what it looks like:

ReceiptWalletScreenSnapz001.png

Love/hate relationship with Cocoa Bindings

I have a love/hate relationship with Cocoa Bindings. On the surface, bindings look really cool. Write less code and get a program running faster. This is great in theory, but in reality, it can be tricky. Bindings in Interface Builder work OK (however, there seems to be annoying Interface Builder bugs that change the focus when you try to bind an object). The problem arises when you remove an object from a nib, run the app and find out that your get an exception that the object is not key/value compliant. So, you have to search through the nib looking for the bindings that are no longer relevant. If you have a lot of objects, this can be time consuming and problematic.

On the love side, I can more easily bring up a user interface and then have things update automatically when something else changes.

In order to help troubleshoot these loose bindings, I found a cool debugging technique. First, in your app’s initialize method, add the following:

+ (void) initialize
{
	[BindingDebugObject poseAsClass:[NSObject class]];
}

then add the debugging object:

@implementation BindingDebugObject
- (void)bind:(NSString *)binding toObject:(id)observable
	withKeyPath:(NSString *)keyPath options:(NSDictionary *)options
{
	NSLog(@"Binding: %@ %@ %@ %@", binding, observable, keyPath, self);
	[super bind:binding toObject:observable withKeyPath:keyPath options:options];
}

- (void)unbind:(NSString *)binding
{
	NSLog(@"unbind: %@ %@", self, binding);
	[super unbind:binding];
}

Paying to watch ads

My wife and I have now managed to get out of the house to watch a few movies without our son (we left him with a babysitter) and while it is good to get out, it reminds me of how annoyed I get at movies. We pay our money (we’ve gone to matinees so the cost is reasonable) and then have to sit through about 20 minutes of ads. It’s worse if we get there early as they have the “20 before the movie”. My wife calls it, the “20 before the 20 before the movie”. Why should we have to pay money to see all the ads? The cost of movies has gone up so much in the last few years it is unbelievable. So the cost has gone up, the ads have increased, and the industry makes more money. We have to put up with it if we want to goto movies. I guess renting movies on my AppleTV is looking better and better.

Time Machine saved my butt!

I’m a bit paranoid about backups, so when Leopard came out, I started using Time Machine to backup in addition to doing my daily SuperDuper! backup. I started using it as an experiment to see how it would work. The one issue I see with Time machine is having to have a drive connected all the time (which I’m looking forward to 10.5.2 for the supposed ability to use Time Machine to an Airport Extreme connected drive). The other day I as working in Interface Builder modifying some nibs and it crashed. This wasn’t surprising as Interface Builder doesn’t handle issues such as trying to remove objects with existing connections, so I wasn’t worried. However, when I launched Interface Builder again, I found that it corrupted my file. Worst case, I’d have to restore from my Subversion repository, but I would have lost a day’s worth of work. I checked my Time Machine backup and bingo, a copy of the file was there from about 10 minutes before. I’m pleased that Time Machine saved me. It’s kind of ironic that an Apple technology saved me from an Apple bug.

Document based ReceiptWallet is a reality!

I wrote almost 2 weeks ago about changing ReceiptWallet into a document based application. I’ve been hesitant to do so because there are lots of things involved. For instance, I have to lock out scanning when one window is scanning, I have to deal with each window having a Reports item, etc. I decided that the time was now to implement it, so a few days ago, I started the journey to switch ReceiptWallet to document based. Based on some work that others have done in making NSPersistentDocument work with packages, I created a test application last Wednesday or Thursday and proved that it was viable. So, I’ve been working like a mad man to get things done. I’m down to about 20 “items” on my list to work on and then I’ll start my own testing. I had to rip ReceiptWallet apart in order to do this, but I’m gradually putting it back together. I’m at least at the point where I can start using ReceiptWallet again; a bunch of pieces still don’t work, but I figure over the course of the next few days, I’ll have everything working and then can start external testing. Yeah! (Some things in the UI aren’t final; I’m not sure I’m going to keep the drawer for the details…I might goto a floating panel.)

ReceiptWallet