Splasm Software Discussions

When entering a new transaction the first field to be filled in is the date. A minor irritation is that entering dates can sometimes be awkward.

For instance, when entering a transaction today the date will be pre-filled as 02/09/2015 (2nd September 2015). However, if the debit was on 31 August 2015, then entering 31 in the first two digits produces only an error beep and the date (31) can not be entered because Checkbook realises that there are only 30 days in September. The user therefore has to skip ahead and change the month first before going back and setting the date.

I'm note sure how US English dates are affected because presumably the month is entered first. If there is already '31' in the date field then can '9' be entered for the month?

The top item appearing in a new debit or credit field is DATE. Set it up there before you enter the details. Yes, it's a pain because you can't set DATE to be the first automatic field for entry.

Sorry, isn't that what I wrote? "When entering a new transaction the first field to be filled in is the date."

The issue for me is that the date is pre-filled, either with the current date or the last entered date. If the month of the pre-filled date has fewer days than the date of the transaction to be entered, then the date can not be entered without first changing the month. This is a bit counter intuitive. Couldn't the checking of the date wait until the complete date has been filled in and only then indicate an error if applicable?

Checkbook Pro/Preferences/Entry/Select Date First

The awkwardness when the day is before the month and you need to backdate to the end of the previous month is an artifact of Apple's date picker design.

The date picker automatically updates its date value as the user moves from one component to the next. This allows the date picker to instantly communicate with other interface elements and code, which works well in locales where the month comes before the day - Apple constrains the day component according to the month - but can't elegantly handle things the other way around, as the constraining date component, the month, is already there in plain sight, so when a day value exceeds the constraint, the date picker has no reliable way of knowing the user's intention.

I guess one way we could work around it is to provide a simple text field with date formatting instead of a date picker where the components are separated. Seems like that'd end up requiring more work in the end - users would have to enter entire dates with every Entry, recover from keystroke errors, particularly with date component separators, plus remember the date in the first place.

The way it behaves in this situation would annoy me, as well. Thankfully, it's only right around the beginning of the month, and not all months. It might be easier to live with if you're quick with Tab and Shift-Tab, or using the arrow keys. Left/right arrows switch between components and up/down arrows adjust values, so right arrow, down arrow, left arrow, enter day. If your preferences are set to use the last entered date instead of the current date, the rest of the Entries you create will automatically pick up the date so you may only have to do this a handful of times a year.

_________________
Keith Gugliotto
Primordial Sea Captain
Splasm Software
https://www.splasm.com

Thanks for the explanation Keith - I had assumed that date entry was Splasm code and didn't realise it was a built-in Apple feature.

As I wrote, it's only a minor irritation and as you explained it would probably be more awkward any other way. You'd think in the 21st century the world could agree upon a way of entering dates

Do it my way.

See, we agree!

Great. Now can we agree to use the metric system and rename the program to ChequeBook?

Hear-hear!