Shift-tab acts like tab in desc
When in the Description field in a new transaction, shift-tab goes to the next field instead of the previous field. When in all other fields, it goes to the previous field, as it should.
Edward
Moneydance 2011 (790)
Sun Java 1.6.0_25
Windows Vista with latest updates
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
1 Posted by Ben Spencer on Jun 08, 2011 @ 07:24 PM
I have tested this on Mac, Linux and Windows and in all cases shift tab in the description field moves the focus to the previous field rather than the next field. Perhaps you are doing something slightly different. Can you double change that you can reproduce this problem.
Ben Spencer
Moneydance Support
2 Posted by paleolith on Jun 08, 2011 @ 08:26 PM
Hmm ... obviously the circumstances are much more restricted than I thought when I wrote that.
I can reproduce it in one case: new transaction, tab to description, type two or more letters so that auto-complete is invoked, then shift-tab. Cursor moves to Category field. After that shift-tab works correctly; in particular, hitting shift-tab two more times moves back to the description and then to the check number. I find this to be completely consistent.
I distinctly remember shift-tab failing multiple times while I had a new transaction open. But my memory isn't always distinct enough, and I can't reproduce that now. I'll try to remember what I was doing ... or whether I can trust my memory.
Edward
3 Posted by paleolith on Jul 24, 2011 @ 03:41 AM
Has this been placed on a bug list? I realize it's minor. I just want to know it's in the queue so I can stop worrying about it.
Edward
4 Posted by Ben Spencer on Sep 21, 2011 @ 07:22 AM
I am not certain this is a bug nor am I certain what the correct behaviour should be,
The reason shift-Tab is acting differently is because you have been presented with an auto completion option. Leaving the description field while there is an auto-completion option accepts the auto-completion. This this then sets the category field automatically. I think there is some benefit to moving the focus to the category field after it has be automatically set, it both highlights that this field has changed and gives the user the shortest path to changing it again if they don't like the auto-completion.
Never the less I have field a bug ticket so that we do not forget about the issue.
Sincerely
Ben Spencer
Moneydance Support
5 Posted by paleolith on Sep 21, 2011 @ 03:08 PM
Thanks, Ben.
I understand your argument about "what would the user be doing next". Yet at the same time, it takes quite a bit of effort, and knowledge of how keyboard shortcuts work, to use shift-tab. It isn't something that anyone hits accidentally. So if I type shift-tab, it's pretty certain that I wanted the previous field.
So if you really feel shift-tab should not go to the previous field in this situation, then I would prefer that it be disabled entirely and do nothing. That at least would clue the user that the context is interfering with the normal function of the key combo.
I now see there's a similar situation with clicking the mouse. If I type in the description to invoke auto-complete and then click on the Payment field, the Category field is selected! That's just totally contrary to the way every computer users expects a mouse click to work. And it's a lot more likely to cause errors than the shift-tab anomaly, since everyone uses the mouse. I can easily see someone positioning the mouse, clicking, and proceeding to type without examining the results of the click. OTOH, though everyone uses the mouse, not nearly as many understand all its nuances anyway.
Personally I always leave the description field by tab or enter -- except for that one time when I noticed that shift-tab didn't work as I expected. (I don't remember now, but probably I realized I needed to change the date or check number.) But if I actually clicked on another field -- which I've probably never done until a minute ago when I thought to test it -- I would want that field selected, period. Second-guessing my selection always annoys me. (There are other cases where the selection changes without warning, but that's getting off topic.)
I could even see that shift-tab, or clicking in a field other than the category, might trigger a dialog box, much as clicking on another transaction before taking action to save the current transaction does. This would be annoying if it happened often of course, but the whole point is that this is a rare case.
Also related is the fact that while typing in the description field, auto-complete only fills that field, and the other fields are only filled when leaving the description field. (There's an argument that the user should be shown everything that's going to happen before accepting the auto-complete, though I think I would find such behavior much too confusing.)
Anyway, thanks again. And it's still low priority, and now I'm not totally sure what the best answer is either.
As I was going to St Wiles
I met a man with seven files.
Every file had seven forms.
Every form had seven fields.
I filled in each field seven times
And filed the filled-in forms of fields.
Files, forms, fields, fills,
How many were filing at St Wiles?
System closed this discussion on Mar 31, 2015 @ 03:35 PM.