In the late stages of my current project with PB/DOS 3.5, I support eight function keys (F1-F8) using the
predefined KEY values for function keys. I was intending to add support for an additional eight hot keys
using the user defined KEY traps 15-22. The new hotkeys were to be Ctrl-F1 to Ctrl-F8, but when I tried to
add them with the KEY statement, I found that the new hotkey routines were never called - the predefined
F1-F8 keys seem to take priority. I tried redefining the predefined KEY statements so they wouldn't be called
if the CTRL key was also pressed, to no avail (the compiler appears to ignore that approach), and I also tried
moving the order of my KEY statements around to see if the order they were defined in made any difference.
No difference that I could find. It appears that using the predefined function key traps trumps user defined
function key traps using the same keys.
I'm trying to decide my next step here. Because I have 16 keys to trap and only ten user definable key traps,
I can't just define them all as user definable keys. I could throw away the traps and trap the keys myself
with INKEY$, but I have polling events that might keep an INKEY$ statement from being executed for several
seconds, which would be an irritation my user base. Changing the hot keys would also irritate the users, as
they are already used to using these keys from earlier applications. I could write a keyboard interrupt handler
to take care of all this, but that would require a larger investment of time than I have available.
I couldn't find anything about this contention in the manuals or through a forum search.
I'm hoping somebody here has a workaround, but even a few "nope, sorry, you're toast" comments from users
more experienced with key traps than I am would at least let me know that I've exhausted this approach and it's
time to move on.
Thanks in Advance,
Jerry
------------------
predefined KEY values for function keys. I was intending to add support for an additional eight hot keys
using the user defined KEY traps 15-22. The new hotkeys were to be Ctrl-F1 to Ctrl-F8, but when I tried to
add them with the KEY statement, I found that the new hotkey routines were never called - the predefined
F1-F8 keys seem to take priority. I tried redefining the predefined KEY statements so they wouldn't be called
if the CTRL key was also pressed, to no avail (the compiler appears to ignore that approach), and I also tried
moving the order of my KEY statements around to see if the order they were defined in made any difference.
No difference that I could find. It appears that using the predefined function key traps trumps user defined
function key traps using the same keys.
I'm trying to decide my next step here. Because I have 16 keys to trap and only ten user definable key traps,
I can't just define them all as user definable keys. I could throw away the traps and trap the keys myself
with INKEY$, but I have polling events that might keep an INKEY$ statement from being executed for several
seconds, which would be an irritation my user base. Changing the hot keys would also irritate the users, as
they are already used to using these keys from earlier applications. I could write a keyboard interrupt handler
to take care of all this, but that would require a larger investment of time than I have available.
I couldn't find anything about this contention in the manuals or through a forum search.
I'm hoping somebody here has a workaround, but even a few "nope, sorry, you're toast" comments from users
more experienced with key traps than I am would at least let me know that I've exhausted this approach and it's
time to move on.
Thanks in Advance,
Jerry
------------------
Comment