Tag: Programming

Posted on

Does anyone at Apple actually care about us developers?

I fired up ReceiptWallet beta on a Tiger machine today to check out a problem and it didn’t launch. Huh, I looked at the crash log and it said there was a problem with a symbol not found using the dynamic linker (I’m not sure why my testers on Tiger didn’t find this as it clearly doesn’t work). So, I look at my code and I have:

	[pictureTaker setValue:[NSNumber numberWithBool:NO]
		forKey: IKPictureTakerAllowsFileChoosingKey];

This code only executes on Leopard, so it should be fine. However, whoever decided to define this constant decided to define it as such:

	extern NSString *const IKPictureTakerAllowsFileChoosingKey;

instead of something smart like:

	#define IKPictureTakerAllowsFileChoosingKey	@"IKPictureTakerAllowsFileChoosingKey"

Why is the second one smarter? Because it allows people to compile in features that work on 10.5 while still supporting 10.4. I have checks in my code to not execute this chunk of code on Leopard, so that isn’t a problem. The problem with this is that while everything compiles and links, it crashes on Tiger.

Apple wants us to use new technology, but most of us can’t abandon Tiger users, so we compile against the 10.5 SDK with a Mac OS X Deployment Target of 10.4 as indicated we should do in the Core Data Release Notes.

Apple, please fix this!

Posted on

Another set of bugs in Leopard

A number of weeks ago, I fought with Leopard to be able to use a magnetic stripe reader in one of my apps. The Apple sample code worked on Tiger, but broke on Leopard. OK, I reported that as a bug. Next, I looked at some new USB code in Leopard and that failed as well. After opening an Apple DTS incident, buying a magnetic stripe reader for them, and going round and round, they acknowledged the first bug and the second bug which was a workaround to the first one. DTS did send me code that finally did work.

This week, I fought with Leopard (or maybe it is Tiger) dealing with the Keychain. The Keychain (along with System Configuration) are some of the most confusing frameworks to write code. This weeks’ issue dealt with using the Keychain framework to get a password out of the System keychain (like for PPP passwords). If the user clicks on Always Allow, the method returns a -61 error which is a write permissions error. What’s the workaround? Well, if I get a -61 error, I put up the request again. While this gets me to the end goal, it really confuses the user.

Today was another bug dealing with the Image Capture. I wanted to add supporting Image Capture in addition to TWAIN as it might be more reliable. I got as far as implementing the UI and all the code, only to find out that if I scan once, when I close the scanner session, I get an error and then I can’t scan again. All that I’ve read indicates that the Image Capture Framework (ICA) doesn’t work properly when compiled against 10.5. This doesn’t surprise me as someone changed the TWAIN header files in Leopard so that UInt32s were changed to void * or vice versa. This, of course, causes lots of warnings that have to be typecasted. Scanning is one of those areas in the OS that doesn’t seem to get touched and no one seems to care. The scanner vendors write crappy drivers so they don’t complain and no one else is big enough to get Apple to care. Maybe things will change.

Posted on

Bit by a linker issue

Apple has some great code to handle adding and removing items as login items called LoginItemsAE which uses AppleEvents to talk to System Preferences. I’ve used it on a number of projects and found it to work well. That was until today. A client complained that my install code wasn’t working that added it as a login item. I couldn’t reproduce this on my Mac Mini (Intel) and I use the same piece of code in another app in the same bundle and it worked fine. After a bit of fighting with the system and remembering that sometimes Carbon framework needs to be linked, I linked it in and the problem went away. Why, oh why, didn’t I get a linker error?

Posted on

Merging ReceiptWallet and DocumentWallet

After a bit of mental wrangling and taking some email to heart, I decided to merge ReceiptWallet and DocumentWallet. This means that ReceiptWallet can now open DocumentWallet libraries in addition to ReceiptWallet libraries. When you create a library, you choose for it to be a receipt or a document library. This now makes a lot more sense since multiple libraries can be open at once. The libraries still have a few things different (number stuff doesn’t make sense in a pure document library).

What does this mean for DocumentWallet? Well, DocumentWallet serial numbers will now work in the new version of ReceiptWallet. This will be a free update for all users. When this new version comes out, I will be raising the price as I have added a significant amount of functionality with the last few updates. My current price was meant to be an introductory price, but I never got around to raising it. Now is a good time to do so.

One kind of weird thing is that DocumentWallet users can’t automatically update to ReceiptWallet using the auto update mechanism because the applications are named differently and the application identifiers are different. So, users will have to download ReceiptWallet and update through that.

The new ReceiptWallet beta is available in the standard way.

Posted on

CoverFlow view in ReceiptWallet is now complete!

My last piece in the CoverFlow view in ReceiptWallet was to add a horizontal scrollbar. This is much easier said than done. So I managed to create my own NSControl and have it act like a scrollbar. It might be a little hard to tell in this screenshot, but look at the bottom of the view and look at the scrollbar. Coo!

ReceiptWalletScreenSnapz002.png

After a little more testing, ReceiptWallet 1.6.0 will be ready to go!

Posted on

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

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

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