Disabling acelerators without Alt:
this is nothing specific to a string grid, it is standard Windows
behaviour: if the control having focus does not process character input
then Alt is not needed to have a character act as an accelerator.
To fix this, add a handler for CM_DIALOGCHAR to your form:
private
{ Private declarations }
procedure cmDialogChar( Var msg: TCMDialogChar );
message CM_DIALOGCHAR;
procedure TForm1.cmDialogChar( Var msg: TCMDialogChar );
begin
If ((msg.keydata and $20000000) = 0) Then
msg.result := 1 // alt not down, eat key
Else
inherited;
end;
You can also use the forms OnShortcut event to process keys before the
controls on the form see them.
Peter Below (TeamB) 10011...@compuserve.com)
No e-mail responses, please, unless explicitly requested!
Note: I'm unable to visit the newsgroups every day at the moment,
so be patient if you don't get a reply immediately.
> Disabling acelerators without Alt:
I don't understand the (msg.keydata and $20000000). Also, I would like to
do it in the Onshortcut, as I am not well versed in adding a handler.
The CM_DIALOGCHAR message is an "echo" of a WM_CHAR or WM_SYSCHAR message
Windows send to the application in response to a keystroke. Look at the
topics for these messages in win32.hlp. You will see that the messages
lparam encodes some information about the key (its keyboard scan code for
instance) and bit number 29 (counting from 0) in the 32 bit parameter
encodes the state of the Alt key. That is what the statement is testing, it
performs a bitwise AND of the parameter (which the TWMKey record type
cointains in the field named Keydata) with a value that has only the 29th
bit set. The result is <> 0 only if the bit was also set in msg.keydata.
If you look at SendMessage in win32.hlp you see that a message on the API
level consists of a message ID, two parameters (wparam and lparam, both 32
bits in Win32) and an optional result (also 32 bits) which the receiver of
the message can return to the sender. The "bottommost" layer of the VCL that
sits directly on top of the API packages a message into a record of type
TMessage, which is declared in the Messages unit:
TMessage = packed record
Msg: Cardinal;
case Integer of
0: (
WParam: Longint;
LParam: Longint;
Result: Longint);
1: (
WParamLo: Word;
WParamHi: Word;
LParamLo: Word;
LParamHi: Word;
ResultLo: Word;
ResultHi: Word);
end;
In the 0 case you see the interpretation of parameters and result as 32 bit
values, the 1 case interprets the same data as a collection of 16 bit
values, which is sometimes useful. Even more useful are the message records
the Messages unit declares for most of the commom Windows messages. The
messages often encode several values into one of the parameters, which the
messages receiver has to laboriously pick apart again. The message records
do this for us automatically, e.g.
TWMKey = packed record
Msg: Cardinal;
CharCode: Word;
Unused: Word;
KeyData: Longint;
Result: Longint;
end;
You can see this as another view of a TMessage record, it has the same total
size and just takes the wparam field apart into two 16 bit fields.
> Also, I would like to
> do it in the Onshortcut, as I am not well versed in adding a handler.
Come on, surely you can copy and paste the code from my message <g>. It
would not be totally straightforward to do the same in OnShortcut.
OnShortcut fires in response to a CM_KEYDOWN message (an echo of WM_KEYDOWN
or WM_SYSKEYDOWN), so at this point Windows has not yet performed the task
of separating keys that create characters from those that do not. Only the
former will generate an additional WM_CHAR/WM_SYSCHAR message, which in turn
create CM_DIALOGCHAR. We have to detect characters ourselves in OnShortcut,
but fortunately there is an API function we can use for that:
procedure TForm1.FormShortCut(var Msg: TWMKey; var Handled: Boolean);
var
res: Integer;
begin
res := MapVirtualKey( msg.CharCode, 2 );
If res > 0 then
Handled := (msg.keydata and $20000000) = 0;
end;
There is one major difference between using CM_DIALOGCHAR and OnShortcut you
need to be aware of: CM_DIALOGCHAR is only send to the form when the active
control does not process character input, so it does not collide with text
input in an edit control, for instance. OnShortcut, on the other hand, is
fired for *every* keystroke, regardless of what the active control may be.
So having an onShortcut handler like the above would disable all character
input into edit controls and the like!
"Peter Below (TeamB)" <10011...@compuXXserve.com> wrote in message
news:VA.00007a1...@antispam.compuserve.com...
> Thanks, I think..
Would you mind minimizing the amount of quoted text you include from the
previous poster to the least necessary for intelligible continuation of
conversation? Thanks.
-- Barry
--
If you're not part of the solution, you're part of the precipitate.
Team JEDI: http://www.delphi-jedi.org
NNQ - Quoting Style in Newsgroup Postings
http://web.infoave.net/~dcalhoun/nnq/nquote.html