BCPP 3.1 - Trapping the Enter key

Hi, I could not recall the exact name of Key Down message in BC++
3.1. Anyway, you have to handle WM_KEYDOWN message and check
if it is VK_RETURN in your window callback, then call the same
function to handle tab key.  Check out the RTMessage structure and SDI, same semantics for WPARAM and LPARAM.

BTW, better to move to OWL2.0, and it is only cost 50$ in most
of stores to get BC++4.52, which is pretty good.

Hope this helps
gary xie

I certainly do appreciate the response.  However, I don't think that the answer is valid.  I've tried overriding the wm_keydown routine in order to grab the Enter key.  However, wm_keydown is never called in response to the Enter key in a dialog.  The actual winsight message trace upon pressing the Enter key is:

31D0 "Enhancement"  WM_USER+0x0000  Sent  wp=0000  lp=0000:0000
31D0 "Enhancement"  WM_USER+0x0000  Returns 1397424129 (534B:0001)
31D0 "Enhancement"  WM_COMMAND  Sent  Notify BN_CLICKED  from hwnd 3634  id 1

Perhaps the key is in catching the second WM_USER message.

As I said I do not have bc3.1 here. Check your comments, WM_USER
gives me a little hint. If memory serves me, you should have
these in .h file.

  virtual void  WMKeyDown(RTMessage Msg)
                = [WM_FIRST + WM_KEYDOWN];

In case you are not using WM_FIRST.

If you write in SDK Window API, in your window procedure, you have to catch WM_KEYDOWN message, I see no reason, BC3.1 would alter that.
 
If it still does not do what you want, reject me again

good luck

Hello,

My declaration is as you proposed, WM_FIRST included.

virtual void WMKeyDown(RTMessage Msg)= [WM_FIRST + WM_KEYDOWN];

In a derived TWindow, this function catches all key presses.  In a dialog however, the keypresses are directed to the child elements of the dialog or they are translated into button commands.  If I run Winsight and watch the message flow starting from the moment before the Enter key is pressed, I will never see a WM_KEYDOWN message.  This leads me to believe that I am not failing to catch the WM_KEYDOWN message.  Rather, I think that is not being sent.  Something is translating the Enter key into a BN_CLICKED message before I get a shot at it.  I can show you the entire Winsight log if it might help.

I do appreciate you thoughts on this!

-Keith

I haven't used OWL in over 6 months and 3.1 in over 3 years:-)

But, from what I recall,  the WM_KeyDown message could not be proccesed at all. What you had to do was to use Borland controls and process BBN_SETFOCUS messages, these messages indicate that a given control gained focus by an action that was not generated by a mouse. You could then trap the standard behaviour of the Default push button to send a WM_KEYDOWN message if a given flag, controlled by the BBN_SETFOCUS message, has been set.

As I said erlier, I'm rather rusty with OWL, so I'm not even sure if I'm mixing OWL versions here so I'm posting as a comment.

Please let me know if I remembered correctly.

Thanks for the BBN_SETFOCUS suggestion.

However, I think that we're talking different versions of OWL.  You can trap the WM_KEYDOWN message.  In fact, I rely on this to accomplish other tasks.  And, there is no BBN_SETFOCUS message.  The message flow is WM_USER, WM_USER and BN_CLICKED.  Perhaps there is a way to examine the WM_USER messages for a clue as to whether the BN_CLICKED message was generated by Enter or the mouse.  Why are these WM_USER messages sent anyway?  And why is there no WM_KEYDOWN message generated?  It appears that Windows is translating the Enter key into a BN_CLICKED message without giving me a change to intercept it.  Again, the messages generated upon pressing the Enter key are:

WM_USER+0x0000 Sent wp=0000 lp=0000:0000
WM_USER+0x0000 Returns 1397424129 (534B:0001)
WM_COMMAND Sent Notify BN_CLICKED from hwnd 3634 id 1

I know that an upgrade will solve this problem.  However, I've been working on this application for 5 months and I don't relish the idea of changing tools when I am so close to finishing.  

Besides, I'm curious.  I've found that you learn a lot of peripheral things while pursuing a problem like this.

Sincere thanks for the help!

I seem to recall that not all Windows messages that should have were processed by OWL 1. You sometimes had to process messages in an alternate method.

I belive it had to do with overriding WMCooman, setting up a message loop to test for WM_KEYDOWN and calling deafult proccesing if it was any other message.

I belive it was the same technique as used to change the background color of dialog box.

Hope this helps.

I think you may have given me a good clue here.  I'll work with the WMCommand routine and see what I can do.  I'll let you know.

Thanks

The reason that you don't get the WM_KEYDOWN for VK_RETURN in your dialog box is because the default Dialog message handler is intercepting it. You can make your messagehandler the one recieving the messages first. Then send the once you don't handle to the default dialog message handler. I don't remember how this is done in OWL 1.0. But there is a standard windows function for it.I can check my old manualls for you. It will take untill tomorrow.

Thanks.  Using a hidden Ok button would work from a functional standpoint.  However, I would much rather figure out how to allow my dialogs to intercept the keypresses.  This would also be useful in other cases, such as responding to function keys in a dialog.  

There was a comment from JensUniweb about this.  Any followup?

http://www.codeguru.com/Cpp/W-D/dislog/tutorials/article.php/c4965/