Numeric keypad hotkeys no longer work

[GoogleCodeExporter]

What steps will reproduce the problem?
1.  Try using the numeric keypad to send a numeric hotkey.

What is the expected output? What do you see instead?
The hotkey should activate the script or phrase, but does not.

What version of the product are you using? On what operating system?
AutoKey v0.70.2 on Ubuntu Hardy

Please provide any additional information below.
In earlier versions, the numeric keypad could be used for setting numeric
hotkeys, e.g. <alt>+<super>+1, and for sending them.  Now, when setting or
sending a hotkey, the numlock state is ignored, and keys like <np_end> are
recorded and detected instead.  So new hotkey settings will work, but
existing ones need to be reset to be used from the numeric keypad.

Version 0.70.1 did not have this issue.  It looks loke the change is in the
interface module in v0.70.2.

It's nice being able to detect the numeric keypad numbers distinctly from
the main keyboard numbers.  It provides additional unique hotkey
combinations.  But then I would rather also see it distinguish between the
numlock states, so there might be something like <np_1> vs. <np_end>.  For
one thing, it would make it recognizable as a feature rather than a bug.

A further improvement might be to add an option in Preferences for whether
the numeric keypad keys should be distinguished.  For example, <end> and
<np_end> or 1 and <np_1> could either be treated as distinct or as
interchangable.  That would allow for hotkey behavior consistent with
previous versions.

Original issue reported on code.google.com by dv8box-...@yahoo.com on 17 Apr 2010 at 3:28

[GoogleCodeExporter]

This is not a bug. Hotkeys are now working correctly - the previous behaviour 
was
perhaps convenient but not correct. Hotkeys work on the base, unshifted, 
unlocked
state of a key. This means they work irrespective of the current caps or numlock
state. This also means that you can't have a hotkey 'key' give different 
characters
depending on whether numlock is on.

Original comment by cdekter on 17 Apr 2010 at 11:32

• Changed state: WontFix

[GoogleCodeExporter]

As I described the issue, I started thinking this might be the case, and it 
makes
sense.  A circumstance deserving numlocked versus un-numlocked hotkeys doesn't
readily come to mind, and I can imagine how it's a much cleaner process to not 
try
doing that.

I'll just have to reset a few of my hotkey assignments.

Original comment by dv8box-...@yahoo.com on 17 Apr 2010 at 11:49

[GoogleCodeExporter]

Correct :) I always favour uniform behaviour over allowing special cases that
complicate the code

Original comment by cdekter on 18 Apr 2010 at 3:29

[GoogleCodeExporter]

With the update to v0.70.4, the '1' of the numeric keypad is again read as '1',
rather than '<np_end>'.

Original comment by dv8box-...@yahoo.com on 28 Apr 2010 at 9:55

[GoogleCodeExporter]

That doesn't seem possible... I didn't change anything even remotely related to 
that.

Original comment by cdekter on 28 Apr 2010 at 11:52

[GoogleCodeExporter]

Maybe because the Numlock state is detected accurately now?

Original comment by dv8box-...@yahoo.com on 28 Apr 2010 at 11:57

[GoogleCodeExporter]

You are correct, that is the cause for the change. Not sure what, if anything I 
will
do about it - hope it doesn't inconvenience you too much.

Original comment by cdekter on 28 Apr 2010 at 12:05

[GoogleCodeExporter]

It's just a return to the previous behavior, so it's no problem for me.

Original comment by dv8box-...@yahoo.com on 28 Apr 2010 at 12:09

[GoogleCodeExporter]

So if you turn numlock off, does it detect the keys as <num_blah>?

Original comment by cdekter on 28 Apr 2010 at 12:12

[GoogleCodeExporter]

Yes

Original comment by dv8box-...@yahoo.com on 28 Apr 2010 at 12:13