> I don't understand the (msg.keydata and $20000000).

> > I don't understand the (msg.keydata and $20000000).

> 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)  100113.1...@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.