Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000467TunixGeneral Featurespublic2011-12-06 16:112012-04-07 00:02
ReporterFred 
Assigned ToToxicGumbo 
PrioritynormalSeverityminorReproducibilityalways
StatusassignedResolutionreopened 
PlatformApple MacOSOS XOS Version10.6
Product Version0.9.24-SNAPSHOT 
Target Version0.9.24Fixed in Version0.9.24-SNAPSHOT 
Summary0000467: Page Up/Down Events Not Consumed When Values Railed
DescriptionIn the VE table in MS2E 3.1.1, which I assume is the same in FreeEMS and other stuff, when you use Page Up/Down to inc/dec by large amounts, and you hit zero or 250 (why not rail it completely with the next event after that?, IE, 10, or whatever we can, not 10 or do nothing) the Page Up/Down events should still be consumed by the cell so as to not scroll the whole window up and down when that was not the user's intent.

Same thing happens with - and = but they end up in the text box and the = symbol being in there results in zero instead of 255 in the field, which is also unhealthy, and worse than the page up/down issue.

arrows do it too, depending upon which column you do it in, when you go off the end of the column you can end up stuck in random places of the UI unable to get back out with the opposite arrow keys.

These three behaviours are all symptoms of the same practice of ignoring the event when you can't do something useful with it. It should be captured and consumed in almost every case such that behaviour is always consistent.

Tested on Mac on an oldish version 9a3b90 but likely still the same in current ones.
TagsNo tags attached.
FirmwareVersion
Attached Files

- Relationships
related to 0000466assignedFred Consider some changes to the table manipulation key map 

-  Notes
(0000928)
dandruczyk (viewer)
2011-12-06 23:12

fixed in hash 5ee0b9c5d9deafbb7a36b9cd0db22112301701f9
User avatar (0000929)
Fred (administrator)
2011-12-06 23:54

page up/down is good, = is good, arrows are good, but - now doesn't decrement and only puts - into the field, the opposite of what is required, tested in 5ee0b9c5d9deafbb7a36b9cd0db22112301701f9
(0000930)
dandruczyk (viewer)
2011-12-07 00:43

against WHAT FIRMWARE on WHAT TABLE?
User avatar (0000931)
Fred (administrator)
2011-12-07 00:44

Shouldn't this be universal write once, use everywhere? Same stuff I started on, all done offline on the mac in the living room away from freeems hw. If it's wrong/not detailed I can try to add more detail, but it seems correct to me.
(0000932)
dandruczyk (viewer)
2011-12-07 00:55

nope, some tables ALLOW negative values, other's don't
(0000933)
dandruczyk (viewer)
2011-12-07 01:52

fixed in hash 7284a978bff6e5097ee6231062186aa702b97eb0
User avatar (0000934)
Fred (administrator)
2011-12-07 12:16

Tested in the hash provided and it still behaves the same way.

Mac OS X 10.6
MS2 3.1.0 series and same of ecu data
VE tables work fine, Spark tables just enter - symbols.

Need to only accept - as negate when already editing, not the rest of the time. IE, it shouldn't enter edit mode even on tables that have the possibility of being negative. Instead . or 0-9 should be used to enter the edit mode (along with some hot key of some sort as another option to enter the mode) and once in that mode, then the - should cause a negate.

However, even in that mode, it shouldn't just flood the text area with - symbols. It would be better if it negated whatever was in there, so made 6 change to -6 and -7 change to 7 etc. then you'd never get something non sensical in the cell causing it to parse to zero.

Perhaps Ben can articulate it better, passing to him for comment.
(0000935)
dandruczyk (viewer)
2011-12-07 13:05

When in a spreadsheet, navigating to the cell puts it into edit mode DIRECTLY, hence if the field is capable of negative numbers '-' is a valid charactor NOT a hotkey.

> However, even in that mode, it shouldn't just flood the text area with - symbols. It would be better if it negated whatever was in there, so made 6 change to -6 and -7 change to 7 etc. then you'd never get something non sensical in the cell causing it to parse to zero.

That requires way too much special case code craziness to even consider. Be smart, use q/w instead. It is much easier on a keyboard anyways to use arrows (or hjkl) in combination with q/w to increment/decrement, because it lines up better with peoples left and right hands, than forcing the user to crowd their hands to use +/-, esp since those are dual purpose keys, and not always in the same spot on everyone's keyboard.
User avatar (0000936)
Fred (administrator)
2011-12-07 13:20

What? It requires _less_ special case code! You never need to check what type of data it is, - will always decrement. You only need to always check if you're in edit mode or not, and if in edit mode listen for a different set of keys, totally different.
(0000937)
dandruczyk (viewer)
2011-12-07 13:33

there is no "edit mode" if you interact ITS EDITING!
User avatar (0000938)
Fred (administrator)
2011-12-07 13:41

I know, but there needs to be, as discussed in the other ticket.
User avatar (0000958)
BenFenner (reporter)
2011-12-10 16:30
edited on: 2011-12-10 16:31

I know it might be painful, but I think it might be time to change the increment/decrement keyboard shortcuts to use something other than the plus and minus keys. Since the negative character is valid for some maps, it should immediately invoke edit mode and place a negative character in the cell. That behavior is correct. But doing that on some maps (where negative values are allowed) and doing different behavior on other maps is way too inconsistent.
New keys for increment/decrement need to be found.
Can use "U" and "D" for up and down. Or can use "Page Up" and "Page Down" although I think those are already in use. Could use "=" and "]" since on most keyboards they are above and below each other and the "=" key also has "+" printed on it.
Could use "," and "." because they usually also have "<" and ">" printed on them.
Could use "P" and "M" for plus and minus. Could use "I" and "D" for increment and decrement.

Lots of options.

If "-" and "+" are the only things you want to use for increment/decrement, then IMO you can't have the "-" character enter edit mode on any maps.

(0000973)
dandruczyk (viewer)
2011-12-10 21:50
edited on: 2011-12-11 16:32

I disagree regarding the minus key. the only thing mtx current messes up regarding minus, is that for negative allowed value it allows multiple minus signs, which is a typo, but that is minor/trivial and AFAIK handled reasonably gracefully.

The problem with using letters is that they may mean drastitically different things in other languages are be nonintuitive there. MegaTunix has the FOLLOWING key mappings

Large increment: PageUp
Large Decrement: Page Down
Small Increment: +,=,q,Q, Number pad + and =
Small Decrement: W,w, for all controls, - and Number pad - for controls that do NOT have negative values, in the case of negative valued controls it allows the minus sign to be entered as part of the entry's text.

Hotkeys send value immediately!, editing the cell (i.e. highlight and type over, DOES NOT send until either enter is pressed (to send it), or escape to abort and revert to original value

Navigation:
Move to left cell: H,h,left arrow, number pad left (typically 4)
Move to right cell, L,l, right arrow, number pad right (typically 6)
Go Down one cell: J,j, down arrow, number pad down (typically 2)
Go up one cell: K,k, up arrow, number pad up (typically 8)

Oddballs:
F,f enables tracking focus, cell focus changes to most "influential" vertex.
Escape reverts currently edited value to previous value
Enter/Return sends current edited value (if previous value was typed over and NOT modified with hotkey)

User avatar (0001409)
Fred (administrator)
2012-04-06 23:53

Jeff, no activity on this for a while, thought I'd throw it your way for commentary. Thoughts?


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker