Quote

>Hi,
>There are a few bitbuttons on a panel on a form for Close, Help and
>Print, and the captions of these are : &Close, &Help, and &Print.
>These accelerator keys are supposed to work from the keyboard Alt-C
>etc keys.
>So help me, if the user presses a P key while the focus is on the
>dbgrid, the print routine is started. Similarly, to get a name
>starting with C, the query does not find the names starting with C,
>the form is closed.
>Accellerator keys are supposed to work with the Alt keys.
>I cannot catch this keystroke anywhere.
>What am I doing wrong please?
>Thank you
>Johan Smit

Quote

"Johan Smit" <smi...@lantic.net> wrote in message

Quote

> Hi,
> There are a few bitbuttons on a panel on a form for Close, Help and
> Print, and the captions of these are : &Close, &Help, and &Print.
> These accelerator keys are supposed to work from the keyboard Alt-C
> etc keys.
> So help me, if the user presses a P key while the focus is on the
> dbgrid, the print routine is started. Similarly, to get a name
> starting with C, the query does not find the names starting with C,
> the form is closed.
> Accellerator keys are supposed to work with the Alt keys.
> I cannot catch this keystroke anywhere.
> What am I doing wrong please?
> Thank you
> Johan Smit

Quote

>It seems to me that the focus is on your grid, but you are not in edit mode.
True
>The accellerator keys will function as they do. Example: Copy files in a
>folder to a new folder. Then select the files again and copy again - a
>dialog will pop up aksing you if you want to overwrite the files. You do not
>have to press Alt - only the key. The focused control will have the first
>choice of what to do with a key. If it cannot use it, then the parent (form
>or panel) will typically handle it. Did you write OnKeyDown and OnKeyPress
>event handlers for the grid? If so, was the function called? If the
>OnKeyPress event handler is called, then set the Key parameter to #0 if the
>grid can use the key.

Quote

Johan Smit wrote:
> The DBgrid onkeypress do not catch the key event if there is an
> accelerator that will catch it.(if the dbgrid is not in edit mode)
> In DBGrid.OnKeyUp:
>  qM.Locate('Name',char(Key),[loPartialkey]);
> That scrolls the grid to the first name that starts with the pressed
> letter. The form key preview is set to false.
> Now I changed the DBGrid option dgEditing to true, and that prevents
> the accelerator from handling the key event, but leaves that ugly edit
> focus in the dbgrid.
> Then I changed DBGrid.OnKeyUp to:
>  qM.Locate('Name',char(Key),[loPartialkey]);
>  keybd_event(VK_Return,0,0,0);
>  keybd_event(VK_Return,0,KEYEVENTF_KEYUP, 0);
> Now it works the way I would like it to.
> I am not sure if that is the best way to do it.
> Thank you for your help, any further comments will be welcome.

Quote

>DBGrid descends from TCustomGrid, and that's where the root of your
>troubles is. Windows sends the grid a wm_GetDlgCode message, which asks
>the control which keyboard events it wants to handle. Unless it include
>dlgc_WantChars, Windows won't event send the grid key-down or key-press
>messages about the alphabetic keys, which is why you haven't had success
>handling the OnKeyress event.

>TCustomGrid only return dlgc_WantChars if the goEditing flag is in the
>Options property, and I think the presence of that flag is directly
>related to the dgEditing flag in the DB grid. (Forgive me if I'm low on
>details; I've never used databases or grids.)

>You can declare your own grid descendant that handles wm_GetDlgCode how
>you want it to. In fact, you could probably incorporate all of your
>cell-finding code into that new grid component.

>procedure TTypeAheadDBGrid.WMGetDlgCode(var Message: TWMGetDlgCode);
>begin
>   inherited;
>   Message.Result := Message.Result or dlgc_WantChars;
>end;

>This alone shouldn't cause any problems. However, if you go ahead and
>decide to incorporate your "type-ahead find" code into the component,
>there could be conflicts with the existing in-place-edit code.

>--

Quote