[Known Issue] Bug with Hot Key: Num *

[jpuziano]

Hi Marcus,

I am running Macro Scheduler Pro 10.023 here on Win XP SP 2.

Please see if you can reproduce this:

- create a new macro, doesn't matter what, this for example:

Code: Select all

MDL>Hot Key Bug?

- save the macro

- double click the macro from the main window

- click the "Hot Key" tab

- click into the "Type a Hotkey:" field

- hit the * key on the numeric keypad

- now the "Type a Hotkey:" field should show: Num *

- click OK button to save the Hot Key

- double click the macro from the main window

- click the "Hot Key" tab

- for me, the "Type a Hotkey:" field now shows: Prnt Scrn

Can you (or anyone else out there) reproduce this?

[jpuziano]

Hi Marcus,

Not sure if you've seen the above post but here's something else going on with Hot Keys. We now have two ways in which to specify a Hot Key.

• 1) original: "Assign the following Windows HotKey To This Macro."
  - two dropdown boxes used to specify the key and possibly modifiers
  
  2) new: "Type a HotKey:"
  - a field where if you click into it and type a key or key combination, it will detect and show what you chose
  
  A checkbox by each selects that method (and deselects the other).

I've been using a certain macro for a long time that uses the Hot Key NP- which was chosen with method 1... the minus symbol on the numeric keypad.

I made a new macro and using method 2, I was surprised to see it let me assign the exact same Hot Key to it. Further, in the "Type a HotKey:" field, it only shows: - (just a minus sign) while in the main Macro Scheduler window in the Hot Key column, it shows up as: NUM -

If the Hot Key has already been assigned using method 1, shouldn't it be unavailable to assign using method 2 and visa versa?

Could you please let me know if you can duplicate the above effects?

Thanks

P.S. After playing with it for a bit, I found two more things I'm curious about:

- Method 1 now allows us to make use of the Windows key (thanks for adding) however Method 2 does not detect the Win key... should/could it?

- Method 2 now lets us select a Hot Key with three modifiers and a letter like SHIFT-CTRL-ALT-U whereas method 1 does not have SHIFT-CTRL-ALT as a choice in the first dropdown field... should/could it?

Again, not complaining because I remember you once said this bit of code was quite challenging. I think its great we now have two methods of selecting a Hot Key and the fact that Method 1, once you've selected modifiers, now only shows available (as yet unassigned) keys... that's a great feature... wouldn't want that to go away.

Take care

[Bob Hansen]

Just to let you know, I could not duplicate the problem, I got Shift 8 vs num *. But no surprise, I was using a laptop without separate numberic keypad, so test is invalid. I will try to see if I can test with a normal keypad.


Wait one min..... just rtried with the function key to use the alternate keypad. This did come up as Num *. And when I reopened it did show Prnt Scrn, just as you pointed out.

So, I can confirm your problem on my laptop. Using 10.015.

[jpuziano]

Hi Bob,

Thanks for taking the time to try this and posting here to confirm the above can be duplicated... much appreciated.

Take care

[Marcus Tettmar]

Something you need to realise about the number pad keys is that their function changes drastically depending on whether the "Num Lock" key is pressed or not. E.g. With Num Lock off NP7 is actually Home. So what you see when you type a num pad key in the hotkey box will vary depending on whether num lock is on or off.

However, that doesn't explain why * is being interpreted as Print Screen. I'll look into that.

- Method 1 now allows us to make use of the Windows key (thanks for adding) however Method 2 does not detect the Win key... should/could it?

Because if you "type" Win key the windows menu will appear. So you can't really type it into a box. That's why it is in the method 1 box instead.

- Method 2 now lets us select a Hot Key with three modifiers and a letter like SHIFT-CTRL-ALT-U whereas method 1 does not have SHIFT-CTRL-ALT as a choice in the first dropdown field... should/could it?

No, the reason for adding the second method was to facilitate the entry of more hotkeys. Ideally I would have preferred to replace the drop down entry boxes with the new "type a hotkey" method. But found that there are some sequences which don't lend themselves well to being typed into a box. So there are cases where one method is better than the other. And the simplest way to provide backward compatibility was to keep the old one in place.

So you now have two methods which between them cover many possibilities.

[/quote]

[jpuziano]

Hi Marcus,

However, that doesn't explain why * is being interpreted as Print Screen. I'll look into that.

I see this bug is still in version 10.1.15... have you looked into this yet?


Also, in the above posts, I didn't see a reply from you to this question:

If the Hot Key has already been assigned using method 1, shouldn't it be unavailable to assign using method 2 and visa versa?

That functionality would be nice as assigning the same Hot Key to two different macros isn't a good thing. Would this be possible or is it already on the wish list?

Thanks

[jpuziano]

Finally, while testing Hot Keys, I noticed this one is still an issue in 11.1:

• [Open] Bug with Hot Key: Num *
  http://www.mjtnet.com/forum/viewtopic.php?t=4533

If I remember correctly, you had said (in a separate note) that maybe with the next version of the compiler, a solution could be found for it. If not that's fine, just wondering if there was anything new on this one.

Anything new on the above old bug?

No, sorry, I looked at this in some detail and was unable to find a cause or fix. It seems deep inside Delphi's code base and the work involved to find someone to figure it out and recode the Delphi libraries cannot be justified.

Updated this post to show Marcus' response above. Also updated Subject from Open to Known Issue.

Take care