When I try to save a method in the script editor by
using the shortcut Alt+F S the character 'f' is added to
the source code at the position of the cursor.
I'm using VAST 6.0.2
Configuration map : Code Colouring CS7.NFR.17.
Bringing up a menu via <ALT> + <First letter of menu
name> works fine provided you release the <ALT> key
before pressing the menu key. If you hold down both keys
at once, the menu comes up but (in Windows) the letter is
also added to the coloured code. Thus the workaround is to
be in the habit of typing <ALT> and then the letter, not both
at once.
If this proves a hard habit to learn, a fix that suppresses
adding the letter appears possible. However as it raises the
possibility of subtle UI interactions, I will be testing it further
before releasing it.
The problem arises because OSWIdget>>wmSyschar:with:
does not suppress its modified character's unmodified
keydown event if it is keydowned before the ALT key is
keyuped. CwText does nothing of significance when it gets
this event, but with code colouring, a CwDrawingArea
receives the event, instead of a CwText, and it has a handler
that responds to it by adding the letter. This handler is
exactly how the CwDrawingArea gets the letters that the user
types into the widget, so it can't just be junked.
The keydown message can be suppressed by adding the line
MnemonicKeyHit := true
in the middle of
OSComposite>>callWindowProc:with:with:
This will cause it to be true at the appropriate point in
OSWidget>>wmSyschar:with:, which will then reset it but
suppress the keydown message. This appears to be the
intended pattern for handling this (why else would
MnemonicKeyHit exist?) and it works for me, with no side-
effects observed so far.
However I am not sure I have the right pattern (the base
image and documentation have no examples). My code
makes _every_ OSComposite>>callWindowProc:with:with:
set the class var. That wmSyschar:with: resets it before, as
well as after, the call suggests that this may be what is
expected, but the call'ss setting makes no test that a menu
mnemonic was in fact invoked. It is not clear to me that
some other hook of the ALT key might not be corrupted by
this, possibly in very unobvious ways. (There is also the
question of simultaneos calls in parallel threads.) Hence I
will test it more and run it past the VAST newsgroup before
releasing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=753646
Bringing up a menu via <ALT> + <First letter of menu
name> works fine provided you release the <ALT> key
before pressing the menu key. If you hold down both keys
at once, the menu comes up but (in Windows) the letter is
also added to the coloured code. Thus the workaround is to
be in the habit of typing <ALT> and then the letter, not both
at once.
If this proves a hard habit to learn, a fix that suppresses
adding the letter appears possible. However as it raises the
possibility of subtle UI interactions, I will be testing it further
before releasing it.
The problem arises because OSWIdget>>wmSyschar:with:
does not suppress its modified character's unmodified
keydown event if it is keydowned before the ALT key is
keyuped. CwText does nothing of significance when it gets
this event, but with code colouring, a CwDrawingArea
receives the event, instead of a CwText, and it has a handler
that responds to it by adding the letter. This handler is
exactly how the CwDrawingArea gets the letters that the user
types into the widget, so it can't just be junked.
The keydown message can be suppressed by adding the line
in the middle of
This will cause it to be true at the appropriate point in
OSWidget>>wmSyschar:with:, which will then reset it but
suppress the keydown message. This appears to be the
intended pattern for handling this (why else would
MnemonicKeyHit exist?) and it works for me, with no side-
effects observed so far.
However I am not sure I have the right pattern (the base
image and documentation have no examples). My code
makes _every_ OSComposite>>callWindowProc:with:with:
set the class var. That wmSyschar:with: resets it before, as
well as after, the call suggests that this may be what is
expected, but the call'ss setting makes no test that a menu
mnemonic was in fact invoked. It is not clear to me that
some other hook of the ALT key might not be corrupted by
this, possibly in very unobvious ways. (There is also the
question of simultaneos calls in parallel threads.) Hence I
will test it more and run it past the VAST newsgroup before
releasing.