开发者

Delphi 7 - Why doesn't VK_RETURN work for me?

开发者 https://www.devze.com 2023-02-25 20:27 出处:网络
procedure TfrmProgress.FormKeyDown(Sender: TObject; var Key: Word; Shift: TShiftState); begin if key = VK_RETURN then
procedure TfrmProgress.FormKeyDown(Sender: TObject; var Key: Word;
 Shift: TShiftState);
begin
    if key = VK_RETURN then
    begin
        Self.Close;
 开发者_开发百科   end;
end;

And then I press Enter and nothing happens...


I can't tell you what your problem is from this information, but I can tell you how to work it out.

Create an event handler and attach it to Application.OnMessage. This will get called whenever any queued message is pulled of your apps message queue. Keyboard messages are input messages and thus queued so the WM_KEYDOWN message will arrive in this event handler.

Implement the handler like this:

procedure TMyForm.ApplicationMessage(var Msg: TMsg; var Handled: Boolean);
begin
  if Msg.Message=WM_KEYDOWN then
    Handled := False;
end;

Enable Debug DCUs and then set a break point on the Handled := False line. Run your app, select the spin edit and press ENTER. The code will break and you can now step through to see where the WM_KEYDOWN message is routed.

After the event handler returns you should step until you find a call to DispatchMessage. Press F7 to step into this and keep following the trail until you can find out where it lands and why it doesn't land in your intended event handler.


The focus may be in an edit control, so in order for the Form to get its hands on the keyboard input, you need to set the KeyPreview property to True. Did you do that?


After you press Enter and the form does not close, does it close eventually when the processing has finished? I.e., does it close with a "delayed effect"?

It might be that your form is not processing messages while the operation you're showing progress for continues.

One solution is to periodically call Application.ProcessMessages within your main processing routine. However, do not close the form in the OnKeyDown event. Instead, set a flag such as "AbortRequest := true", and check that flag in your processing routine, and if it is set, exit from there, and then close the form. This will allow you to do any necessary cleanup before aborting.

Other than that, is the spinedit enabled and focused? If you put a breakpoint in the event, is it triggered?

Another possibility: VK_RETURN could be consumed by another control or component on the form. For instance, if you already have a TAction on the form with Enter as its shortcut, the spinedit will never see that key. Or you might have a TButton with its Default property set to True - same result.

All in all, we probably do not have enough information to know for sure.


I personally do not like that you close the form within the editor's KeyDown event handler. I would suggest that you do this at some other moment, at least delay this call by posting a custom message to the form and call the Close method within this message handler. Anyway, such code works fine on my machine. I only do not know what are you doing by calling the Progress method. I would suggest that you put a breakpoint in this event handler and check how the program works. If you are interested in the post message approach, just let me know and I will post the code here.

0

精彩评论

暂无评论...
验证码 换一张
取 消