Tag: ReceiptWallet

Posted on

Paperless in MacUpdate Promo!

Another bundle deal, another set of great apps! This time, however, Paperless (formerly ReceiptWallet), is part of the bundle. MacUpdate is offering a bunch of great apps. You’ve probably heard of most of them. This is the first time that one of my applications has been offered as part of a bundle.

I have a strange hobby of collecting software, so I’ll probably bite on this deal despite owning a few in the collection. It’s hard to go wrong for the price. If you decide to buy the bundle, click on the link on the right side of the page advertising the bundle to support my blog (running this blog isn’t free :-)).

Posted on

Paperless on sale until Sunday!

Paperless, the new name for ReceiptWallet, is on sale until Sunday (5/17) for $34.95. It has the new branding on it, but it’s still my beloved ReceiptWallet! Additional features will be coming and this is a great opportunity for those that haven’t already committed to becoming organized to start.

Posted on

Paperless 1.0 Shipped

Mariner Paperless (the new name for ReceiptWallet) 1.0 shipped last week! I’m quite happy to see ReceiptWallet moving forward. While this 1.0 version of Paperless has mostly cosmetic changes, I’m sure that more changes will be coming soon.

There is so much that can be done, I just didn’t have enough time to dedicate to it.

Congratulations, Mariner!

Posted on

Bye, Bye ReceiptWallet

Today brings to an end my active involvement in ReceiptWallet. As readers of my blog know, Mariner Software bought ReceiptWallet. Today was the official passing of the baton. We initiated the domain transfer that could have taken up to 6 days, but within an hour, receiptwallet.com was in the hands of Mariner Software. All email, support, sales, etc. is now handled by Mariner. I’m not going away and will be available to Mariner as needed and I hope that they tap into my wealth of knowledge every now and again (I have learned something in the last 2 1/2 years of doing receipt/document management).

Now it’s time for me to close my PayPal account associated with ReceiptWallet, purge stuff off my virtual private server, and do some more housekeeping.

I’m not sure if I’m happy or sad. I have very mixed emotions; ReceiptWallet has been part of my everyday life for a long time now. I’ll no longer be answering support tickets everyday and won’t be getting the “I love your software” email messages. However, I won’t be doing support which will be a big relief. Now I have to figure out what to do with my newly found free time.

Posted on

The end of an idea

Ever since the iPhone SDK came out, I had planned to write ReceiptWallet for iPhone as it seemed like a logical thing to do. A few users asked for it, so I thought it was a good idea. However, today is the day that ReceiptWallet for iPhone ends. I’ve toyed with it for the last few months, but just don’t have my heart into it as it isn’t something that I see myself using. As much as I wanted to do this product to answer the needs of the public, it just isn’t going to happen. I was going to finish it to get it out the door, but then I’d have a crappy product that wasn’t my best work.

In addition, there are some serious issues that have to be overcome before it could become usable.

First off, the camera on the iPhone can’t focus close enough to get quality images. As you can see, these pictures are awful. I’m not sure they would be acceptable for any form of documentation. (Who knows, maybe the IRS would accept something that can’t be read.)

IMG_0065_thumbnail.pn

Second off, the synchronization mechanism with the desktop would not be seamless; you would have to launch ReceiptWallet on the iPhone, click on sync and run ReceiptWallet on the desktop. Apple has not provided a plugin mechanism (like Palm did with HotSync Manager) for third parties to sync data.

Third, I’m not happy with the data entry mechanism. ReceiptWallet on the desktop uses combo boxes to allow you to type a few characters and then a dropdown menu shows everything close; nothing like this exists on the iPhone.

The future may change things with ReceiptWallet for iPhone, but ending this today takes a huge weight off my chest and will let me move on.

Posted on

Lovely HP Scanner

My dad has some random HP Photosmart scanner and keeps running into problems with it and ReceiptWallet. His messages imply that it is an issue with ReceiptWallet and that very well may be the case. I looked at his ReceiptWallet log today and saw:

               XResolution: 200.0000
               YResolution: 200.0000
        imageInfo:
                ImageWidth: 616
               ImageLength: 1528
           SamplesPerPixel: 3
             BitsPerSample: 5605
              BitsPerPixel: 16815
                    Planar: 0
                 PixelType: 2
               Compression: 0
got the image info 0...
setupMemXfer.MaxBufSize: 16777216
setupMemXfer.Preferred: 1048576
bytesPerRow: 0
Getting image via memory based transfer...
totalMaxDestBytes : 0
rc: 1
Got image via memory based transfer: 1

This means that the scanner says that it has 16815 bits per pixel! Most scanners do 24 bits per pixel. His scanner must be so advanced that it can capture color 800 times better than the average scanner! OK, so the scanner reported an error and somehow ReceiptWallet didn’t properly handle this (I think I fixed this). The better question is why oh why do HP scanners report bogus information? It seems like the HP scanners are the ones that randomly screw up scans the most. I worked on an issue last week with a different HP scanner doing something similar. Did I mention that the scanner logs debug message to the Console? This is very bad form in a shipping app. ReceiptWallet’s debugging information is turned on via a hidden switch and logs it to its own file to make it easier to troubleshoot. I’m hoping that someday the drivers get better.

Posted on

New features for newer operating systems

I’ve written a number of times (I think) about how long should I support an older OS. I’ve also said that I’m not abandoning Tiger users, quite yet, but I may have mentioned that new features are likely going to be Leopard only as required to make things easier. In the recent past, I’ve implemented 2 Leopard only features; the first is support for Image Capture scanners. Image Capture seems like a broken framework that might be fixed someday. In the meantime, the only way for me to reliably test and get things working is to require Leopard.

The other feature (which I just finished today) is allowing a library to be encrypted. The approach I took was to create an encrypted disc image and shove everything in that. Encrypted disc images are supported on Tiger, but one of the slick features in Leopard is a sparsebundle. What is a sparsebundle? Well, it is a growable disc image that has “bands”. This means that if you modify a few files in the disc image, only the necessary bands are updated. This is absolutely necessary for backups otherwise each time a user touched a ReceiptWallet library, he’d have to backup the entire disc image (backup apps do the right thing; it isn’t a manual process to copy the bands). With one of my libraries approaching 1 GB, that would be a complete waste of time. Time Machine uses sparsebundles for the Time Capsule and if it is good enough for Apple, it’s good enough for me! So, I’ve disabled encryption on Tiger. I’m sure that some people won’t be too happy about this, but doing encryption another way would have taken significantly longer with no true reward.

Everyday, I look at the statistics I collect on what operating systems users run. The large majority run Leopard. In the graph below, you have to make one big assumptions as the data is anonymous so users that check for updates all the time (more than the default once a day) will get recorded more than once, and that is that Tiger and Leopard users check for updates at the same rate. The actual numbers are irrelevant; it is the trends I look at and the ratio of Leopard to Tiger users. The blue and red lines represent the most recent versions of Leopard.

UserData.png

Posted on

Supporting ancient OS versions?

I had a user today purchase ReceiptWallet and then complain that it doesn’t work on Mac OS X 10.2.8! First off, people should download the demo prior to purchasing as I have a big “agree to this” section when purchasing that tells people to try before they buy and says we don’t offer refunds. (I did give this guy a refund as I don’t want to fight chargebacks because people can’t read.) Second off, 10.2.8 came out in October 2003! This guy said that he stays 2 OS versions back (apparently major versions). How can anyone expect developers to support such old OS versions? Apple stopped providing security updates to 10.2.8 a long time ago!

Based on usage statistics I started gathering a few months back (anonymously, of course, which requires me to make some assumptions), Leopard (10.5) users outnumber Tiger users (10.4) 4 to 1. Since ReceiptWallet uses CoreData, it requires 10.4 as CoreData was introduced in 10.4. Based on these statistics, going forward, I have to really decide if I will continue with 10.4 support. For now, I’ll keep supporting it, but some features will require 10.5 (or even 10.5.3) and higher.

Posted on

Hacking ICA – NEAT Receipts scanner working with ReceiptWallet

After a lot of work today, I managed to get the NEAT Receipts scanner to work with ReceiptWallet. It wasn’t easy as there are issues with ICA and the driver that NEAT Receipts ships is quite buggy (if I tell it to scan the entire width, it fails; I have to divide by 3 to get it to work). I suspect that they just got the scanner working with their software and called it a day. Some comments in their forums seem to back this up as the scanner works quite poorly in Image Capture. I’m only going to be supporting 10.5.3 (which was just released) and higher for using Image Capture and this scanner. A large number of ReceiptWallet users are using Leopard, so this isn’t a huge problem.

I’ll be posting a beta probably tomorrow with preliminary support for the scanner. I’m sure I’ll have to keep tweaking the support when they fix/change their drivers. If you don’t have a scanner, I wouldn’t recommend their scanner as the drivers still need work; I’d recommend the Pentax DS Mobile 600 or the ScanSnap S300M. If you already have the scanner, now you can use it with a stable, mature product.

Posted on

EPSON, grumble, grumble, grumble

This weekend I finally had a chance to sit down with the EPSON CX9400 I picked up on Thursday. After hours upon hours of attempting to debug ReceiptWallet and figure out the problem, I finally came up with a workaround. It appears that the EPSON TWAIN data source doesn’t close a few of its resources when the data source is closed. Then when the data source is opened again lots of stuff has taken place since the last scan potentially causing the data source to lose track of its resources (or maybe Carbon doesn’t like trying to open the same resource more than once by the same plugin). In any case, I worked around this by not closing the data source for any EPSON scanner. I really, really dislike this solution, but I went through a lot of my code and tried removing chunks to see if they caused the issue and then eventually discovered that if I started a scan, closed the scan, then showed the thumbnail view (I normally show the list view), it would crash. So all the code I tested to see if it caused the crash really led me no where.

So, this proves to me (beyond a reasonable doubt) that the EPSON scanner driver is a piece of junk and causes lots of problems for ReceiptWallet users.

While I’m beating on EPSON, I decided to grab a screenshot of their latest user interface. This is 2008, not 2000 when I bought my last EPSON scanner. Can we at least get the buttons to be nice OS X buttons and use fonts that don’t look like crap? This UI is completely unacceptable; it’s kind of interesting that the Apple store doesn’t sell any EPSON scanners or all-in-one devices (at least the online Apple store).

I recommend that Mac users stop buying EPSON devices (unfortunately I had to buy one to test) until EPSON decides to spend some money and fix the drivers. They are in such sorry shape, it isn’t even funny.