sending keyboard msgs to childwindows

hey,
I have a custom control and would like it to recieve a WM_KEYDOWN msg,
more in particular, the backspace and delete
buttons. Is there a way to send this(WM_KEYDOWN) message
thru the custom proc every time a key is pressed...?
Without doing anything the control doesn't get a WM_KEYDOWN
msg at all..
did a search on the board, MSDN and of course on the
trustworthy gooogle. No doubt I saw that subclassing was some
kindofan answer, but still it doesn't seem to accomplish this?
The whole control is a class and the GWL_USERDATA is set to point to the instance of the class..

any help/hints/information is greatly apriciated
thanks a bunch :)
/btq

Well, the simplest way is to add this to your message loop:

Code:

---



while( GetMessage(&msg, NULL, 0, 0) > 0)  {
 
  DispatchMessage(&msg);

  TranslateMessage(&msg);

  if(msg.message == WM_KEYDOWN) {
    SendMessage(hChild, msg.message, msg.wParam, msg.lParam);
    }
//...
  }

---

But this is not a good long term solution, and so for that I would suggest using the "controller" paradigm often pushed in the C++ community. This is a lengthy issue and so I won't go into much detail, but there are many good books on the theory, ("C++ in Action" by Bartosz Milewski comes to mind...). Suffice it to say it is a real solution to the entire problem of reliably controlling Windows.

urghh..
so either I have to make crapy error-prone code by sending the
message from another messageprocedure or dig deep into my into my pocket for my librarycard?
ack...are there no easier solutions??

thanks for the reply though :)
/btq

Window subclassing should be able to deal with most situations you care to code for. In this regard and with respect to your original question you may want to take a closer look at WM_GETDLGCODE to see if it will offer added functionality, particularly if your control is in a dialog and you want to retain some default dialog key capability.

aight..I've looked a bit into Subclassing but it seems that's only
for already defined windows like "button" etc.?? I mean my window already has a
custom proc and and it seems Subclassing wouldn't make any difference then?

anyways, I've realised my problem was SetFocus. With SetFocus
set to my window it received keydown messages..
However, since this control is dynamically created by the user and all of these controls should receive the same msg, that wouldn't work with SetFocus(). So my question is: can't I just filter out the WM_KILLFOCUS? if these controls never receive a
WM_KILLFOCUS will these messages still run through the controls
proc then? And if it works maybe more important is: is this 'bad'
windows programming-style?

thanks a bunch :)
/btq

>>can't I just filter out the WM_KILLFOCUS? if these controls never receive a
WM_KILLFOCUS will these messages still run through the controls

Only one ctrl can have 'focus'. The user can not type into more than one ctrl at a time.
So you will have to broadcast your msg to the other windows.
I suggest a custom message to send on to the other windows. Store the HWNDS in an dynamic array / linked list so you can loop thru them. Or assign sequential ID's and loop that way.

#define WM_MY_APPS_MSG WM_USER+40001

Or look at SendMessage() with a HWND_BROADCAST (will not be sent to child wnds though)

Going off of novacain's suggestion, how about this: In the WinMain message loop, use the SendMessage() example I gave to send all keyboard messages to the main window's proc (instead of to the child). Within the proc itself, you have in the WM_CREATE a vector/linked list/array constantly pushing new HWND's into a stack. In the WM_KEYDOWN handler, simply iterate through the stack and SendMessage(). The plus is that it is a long-term/generic solution to handling keyboard input. The minus is that no matter what, every window gets the message.