• Options
• Login
• Register
• Desktop Style
• Accelerated Mobile Pages Theme

V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

• Index

  • Jean Lalonde Support Forum
  • QUICK ACCESS POPUP FORUM
  • QAP SUPPORT
  • V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"
• V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

• V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  emp00 > 2023-06-03 14:30

  Dear Team,  just testing today's V11.6.2 release.
  
  Clearly, the "< > hotkey bugfix" remains buggy, unfortunately: For me, it only fixes the ability to enter "<" as a hotkey, entering ">" still does not work and there are more problems as follows.
  
  1.) Testing "Win <" 
  Symptoms: after setting the hotkey "<" is not displayed in the final display and pressing the hotkey does not work (error beep) - see screenthots below.
  
  2.) Testing "Win >"
  Symptoms: it's not even possible to set ">" as hotkey, pressing ">" does nothing, the text "None" remains.
  
  Sorry, but looks there's another remaining bug... Workaround: Manual input SC056 for ">" still works but gives a rather "ugly looking" hotkey display. Most humans prefer the short ">" instead of a scancode :-)
  
  Thanks for a 2nd look!  
  
  Sceenshots:
  
  Step1: Open "change shortcut"
  
  
  Step2: Choosing "Win" and pressing the "<" key 
  Now "<" appears (did not work before!) but ... see next pic what happens after clicking "OK" ...
  
  
  Step3: The hotkey display is still missing the "<" and pressig the hotkey only "beeps"... Does not work!
  

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  Jean Lalonde > 2023-06-03 15:01

  Hum... Too bad it was not reported during the beta tests. I'm leaving home for a few weeks. ll rework on this when I'm back. Fortunately, this is not a show stopper.

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  emp00 > 2023-06-03 15:09

  Next time I will participate in the beta test - just had no time in the past week, sorry for that!! Safe travels and happy holidays Jean!

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  Jean Lalonde > 2023-07-05 13:05

  This is fixed in release v11.6.2.1:
  https://forum.quickaccesspopup.com/showt...p?tid=2528

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  emp00 > 2023-07-05 14:13

  Thanks for the fixes @Jean - "unfortunately" I'm on holidays starting "in 1 hour" so I will test the new release only in 2 weeks... No worries, keep up the great work!

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  emp00 > 2023-07-17 08:34

  Der Jean, I have just installed the latest QAP Version: 11.6.2.2 which is supposed to fix the above discussed bug regarding the "<" and ">" hotkeys.
  
  Hereby I'm reporting that it's apparently only fixing the bug partially - Symptoms as follows:
  - Pressing "<" and ">" in the "change shortcut" box now works correctly, those keys are registered!
  - Example: Using "Ctrl" as modifier and pressing "<" registers and correctly shows "Ctrl+<" as hotkey (this did not work before, see thread above); note that checking "manual input" now shows "^<" which is probably the root cause of the remaining bug, since AHK does not recognize this as desired in this case but instead as "Use the left key of the pair. e.g. <!a is the same as !a except that only the left Alt will trigger it." (Source: https://www.autohotkey.com/docs/v1/Hotkeys.htm)
  - Remaining bug: Testing the hotkey by pressing "Ctrl+<" on my keyboard does "nothing" - the desired function is NOT called. No error message, no warning sound, nothing. Yes, I restarted QAP after registering the new hotkey.
  - Possible bugfix: Program-internally convert "<" to SC056, this scancode definitely works when used in "manual input" and I think this is the only way for AHK to recognize the "<" key as hotkey (?)
  - only the hotkey display then shows the ugly "CTRL+SC056" as mentioned above already --> it should continue to show "CTRL+<" for user-friendlyness as it does in the current release...
  
  Sorry for reporting this again (late) - was on holidays and could not test earlier ... Hoping this can be fixed, just let me know if you need me to test a beta release. I have a Swiss/German keyboard with the "<" key in the bottom left corner, see https://commons.wikimedia.org/wiki/File:KB_Swiss.svg making combinations with "<" a very convenient hotkey, I actually use this as main QAP keyboard shortcut!
  
  Let me know if you have questions to my bug report - thanks for your efforts!!

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  Horst > 2023-07-17 10:56

  I can't confirm this bug.
  I have a German keyboard with the <> on your place.
  There is no problem for me to set Ctrl+< as hotkey for a favorite.
  It also is displayed fine as Control+<
  
  
  ______________________________________________________
  Windows 11 Home x64 Version 22H2 (OS Build 22621.1992)
  QAP 11.6.2.2  x64

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  emp00 > 2023-07-17 13:55

  @Horst: Can you please show your display when clicking on "manual input" of your "Ctrl-<" hotkey on the "Change shortcut" menu? In my case it shows "^<" ... For me, therefore it's clear that this cannot work since AHK is interpreting the "<" as a special modifier, see my explanation above.
  
  On my system this is a bug -> at least with CTRL and pressing the "<" key when setting up the hotkey --> the hotkey is indeed displayed correctly but simply does not work. Does it really work in your case, thus the hotkey function is really executed?! Have you tested this? Im my case, for the main QAP Keyboard shortcut, see my screenshots -> pressing CTRL-< in order to activate QAP I have no reaction. Nothing happens.
  
  Are you using the same version? Anything else which could explain our different system's behavior? I'm running Win10 x64 Professional, not Win11 - but this should not cause such effects, right?
  
  
  

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  Jean Lalonde > 2023-07-17 14:33

  Hi all,
  
  I saw your bug reports. I won't have much time for this before I leave in vacations for a few weeks. Hoping you can find workarounds until I'm back on this.
  
  Thanks.
  Jean

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  emp00 > 2023-07-17 15:10

  My workaround is using CTRL+SC056 in "manual input" - no hurries. Have a great holiday (again) Jean! :-)

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  Horst > 2023-07-19 11:17

  Sorry, I didn't read your description enough.
  My answer was based on using Ctrl+< for favorites, which works fine.
  For the manual input of the pop-up hotkey, I can't enter any Ctrl based hotkeys.

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  emp00 > 2023-07-19 12:40

  @Horst: So you're saying using the "<" hotkey for "Favorites" works for you? Sorry, but also this does not work here. See screenshot, tested with the Favorite "Recent files" applying CTRL-SHIFT-< as hotkey. Same symptom: The hotkey is shown nicely as CTRL-SHIFT-< but it simply does not execute the (favorite) command.
  
  For me the reason is clear, this is a bug - in this case the hotkey is registered as "+^<" (click on manual input) - and AHK does not execute this hotkey, see my explanation above. Do we now agree or do you still say "no bug"? Please test pressing the (favorite) hotkey containing "<" and show us some proof that it works, if possible. Maybe it's caused by my Win10 system but I doubt that. Thanks for your efforts, Horst.
  
  

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  Horst > 2023-07-20 02:01

  Quote:@Horst: So you're saying using the "<" hotkey for "Favorites" works for you? Sorry, but also this does not work here. See screenshot, tested with the Favorite "Recent files" applying CTRL-SHIFT-< as hotkey. Same symptom: The hotkey is shown nicely as CTRL-SHIFT-< but it simply does not execute the (favorite) command.

  Here, Ctrl-Shift-< works fine and is displayed correct.
  See this screenshots

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  emp00 > 2023-07-20 08:28

  @Horst: Thanks, that's interesting?!! Could you please also show which code is displayed when clicking on "manual input" in the menu of your second screenshot?
  
  Just to be sure: "works fine" means FreeCommander is starting when pressing CTRL-SHIFT-< ?

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  Horst > 2023-07-22 08:36

  (2023-07-20 08:28)emp00 Wrote: @Horst: Thanks, that's interesting?!! Could you please also show which code is displayed when clicking on "manual input" in the menu of your second screenshot?
  
  Just to be sure: "works fine" means FreeCommander is starting when pressing CTRL-SHIFT-< ?

  Yes, Free Commander is starting when I press Ctrl-Shift-<
  
  I don't need manual input, also it's not possible to enter such a combo in the manual input.
  The dialog in my screenshot is all I need to configure such a combination for any favorite item.

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  emp00 > 2023-07-22 16:48

  @Horst: I know, you don't need "manual input" but this is where you can see, how QAP has registered the hotkey. In case of CTRL-SHIFT-< in my case it shows "+^<" and this is a non-valid AHK hotkey code ... That's why I'm very sure, this is the root cause why it does not work in my case. It only works if I change this in manual input to "+^SC056" which is a correct AHK hotkey code. AHK = Autohotkey, this is the interpreting language behind QAP (just in case you don't know).
  
  There must be some difference in our systems and the "manual input" code is the only thing which we haven't compared yet. You're not supposed to enter/change anything - just show us what's existing in this entry field for your CTRL-SHIFT-< hotkey. Thanks!
  
  In the end I hope that Jean can fix this or maybe he knows what else could be the problem on my system. Maybe we also find another user who's willing to test this - currently we're 50 : 50 --> you're saying "no problem" and I'm saying "bug" :-)

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  Horst > 2023-07-23 02:30

  In manual input I can't enter a code like Ctrl-Shift-<
  There is no display at all if I try.
  
  Btw. I write AHK scripts myself since a long time 

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  emp00 > 2023-07-24 13:39

  Thanks for feedback. This is really strange! You're saying there's no display at all (nothing shown) under manual input?!
  
  I just did this to re-start from scratch (tested with the QAP Keyboard shortcut) : 1.) Cllicked on "Reset default hotkey" ==> it sets "Win-W". 2.) Clicking then on "manual input" it shows "#w" which is the correct AHK code for this hotkey, as you know! So this input box is never empty in my case. How can it be empty for you if the actual AHK hotkey combination is obviously always stored+shown here?
  
  I did another test, now even deleting the "manual input" first, then restarting QAP and now again set my hotkey to "CTRL-<" by ticking CTRL and regularly pressing the "<" key (without entering anything under "manual input") --> after that, it again shows "^<" when clicking on "manual input"... This all makes sense to me, it's very conclusive and that's why I'm saying this is a bug! Period. If you have any other idea what I can do, let me know.

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  Jean Lalonde > 2023-08-09 10:00

  Horst > I don't need manual input, also it's not possible to enter such a combo in the manual input.
  
  In the "manual input" dialog box, you enter modifiers using symbols. You probably know these symbols as you know AHK: "^" (Control), "!" (Alt) or "+" (Shift). For example, for "Ctrl + Shift + <" the manual input is "^+<".
  
  emp00 > The hotkey is shown nicely as CTRL-SHIFT-< but it simply does not execute the (favorite) command.
  emp00 > In my case it shows "^<" ... For me, therefore it's clear that this cannot work since AHK is interpreting the "<" as a special modifier, see my explanation above.
  emp00 > In case of CTRL-SHIFT-< in my case it shows "+^<" and this is a non-valid AHK hotkey code.
  
  Sorry but this is wrong. "+^<" is a valid shortcut in AHK and it works both in AHK and QAP. In AHK, try:
  
  ^+<::MsgBox, This worked
  return
  
  In this case, the "<" is not considered as a modifier but as a key. ">" and "<" are interpreted as a left/right modifiers only when they precedes a modifier (like in "<^a" for (Left-Control + a).
  
  "Ctrl + Shift + <" also works on my system. Could it be an issue specific to your system or keyboard layout?

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  Horst > 2023-08-09 10:53

  I don't know anything special on my German keyboard.
  As I said, there is no reaction if I try to directly enter "Ctrl+Shift+<" in the manual input
  but I can enter "^+<" here.
  
  For me, there is no need to use manual input
  as I have no problems to select the combination in the normal way.
  This shortcut works as Favorite or Pop-up hotkey and is correctly displayed as Ctrl+Shift+<

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  Jean Lalonde > 2023-08-09 11:19

  > As I said, there is no reaction if I try to directly enter "Ctrl+Shift+<" in the manual input
  
  I understand. My point was to explain that it is normal that pressing "Ctrl+Shift+<" in the manual input dialog box does nothing. This dialog box only accepts a string containing AHK hotkey trigger codes like "^+<".

• RE: V11.6.2 remains buggy: "fix bug preventing the use of < and > as hotkeys"

  emp00 > 2023-08-09 14:31

  @Jean - somehow this discussion drifted, please let me recap (just tested this all, again):
  
  - You're correct about ^+< being a correct AHK hotkey, my bad assuming the modifier not working at the end (it works)
  - Just tested with AHK (after closing QAP, no conflicting scripts running): all these combinations indeed work fine with latest AHK-v2 !
  +^<:: MsgBox "SHIFT-CTRL-< works"
  +^SC056:: MsgBox ""SHIFT-CTRL-< works (with ccancode)"
  ^<:: MsgBox "CTRL-< works"
  ^SC056:: MsgBox "CTRL-< works (with ccancode)"
  #<:: MsgBox "Win-< works"
  #SC056:: MsgBox "Win-< works"
  
  - Now I terminated my AHK script and started QAP, testing the same hotkeys, code copied from "manual input"
    none of the above combinations using "<" instead of "SC056" worked!
  
  But now comes a surprise, I got it working!
  - Actually I had three hotkeys defined for 3 different tasks: CTRL-<; CTRL-SHIFT-< and ALT-<
  - In the previous QAP release "<" combinations never worked, thus I used SC056 as workaround
  - After removing "SC056" from ALL THREE hotkeys and changing all to "<" it finally worked!
  
  Learning: Somehow there seems to be an internal conflict in QAP when using mixed "<" and "SC056" combinations in at least two hotkeys preventing those "<" combinations to work! I tried reproducing this with pure AHK, but no success. No conflicts detected in AHK, at least in the few combinations tested.
  
  Anyway, guys, long-story-short: Now all works fine in QAP for me as well, please close this issue (hopfeully for good) :-)
  
  Damn! Please trust me, I have not made this up! Really! :-)
• Next Oldest Next Newest