WP 34S and 31S bugs and fixes

[Bit]

(01-25-2015 04:32 PM)walter b Wrote:  

(01-24-2015 04:37 AM)Bit Wrote:  After you press the arrow, you can deactivate all shift modes or activate h shift, even though neither makes much sense in 'arrow mode'. The code that handles the arrow (process_arrow() in keys.c) was clearly written to operate in way similar to 'HYP mode' where only the f or g shifts are allowed. It only checks for f shift, thus anything else, g shift, h shift or no shift, all produce the same result: effectively g shift.

I suggest [->]+[h] results in [h] instead. That would be consistent with the prefix rules on p. 70 of 374 of the manual since pressing [->] calls actually [->][g] and there is no h-shifted function which can be combined with [->].

• [->]+[g] results in [->][g][g] = [->] alone - prefixes [f] or [g] may follow then.
• [->] results in [->][g] as mentioned above, allowing for DEG, RAD, GRAD, 8, or 16 following.
• [->]+[f] results in [->][g][f] = [->][f], allowing for H.MS, H.d, 2, or 10 following.
• [->]+[h] results in [->][g][h] = [h] for reasons mentioned above.
  

d:-)

The above is easy to implement.

However, allowing all shifts to be turned off ([->] [g] [g]) isn't a very elegant solution in my opinion as the arrow by itself is useless, any key other than [f] or [g] will just cancel it.

Edit: The reason I don't think it's elegant is because pressing [->] again already turns of both the arrow and the (f or g) shift. Either it should leave the f or g shift alone:
[->] [->] [STO] = [g] [STO] = [DEG]

Or a 'no shift' state shouldn't be allowed with the arrow (my preference).