WM_KEYDOWN no longer picked up ??

Is the notify style specified for the static control?  By default it is off.

Hope this helps.

i'm not sure, how do I check?

Maybe your window doesn't have the focus. What do you want the message for?
Maybe you can make a forward from your app object.

>>  If you caled the Create or CreateEx function you just need to add the SS_NOTIFY.
yes, I was specifying that:

DWORD dwStyle = WS_CHILD | WS_VISIBLE | SS_NOTIFY | CS_DBLCLKS ;
CCreateContext* pContext = NULL;
return CWnd::Create(_T("STATIC"), lpszWindowName, dwStyle, rect, pParentWnd, nID, pContext);

>>Maybe your window doesn't have the focus. What do you want the message for?
>>Maybe you can make a forward from your app object.

I may have to do a forward, I was hoping not to have to..  I'm trapping keypresses like delete, ctrl-z, ctrl-y to implement undo/redo in a paint type app I'm working on (in a nutshell)

>>In general, I find deriving controls from CStatic often gets me in trouble.  I tend to use the CEdit or CButton controls myself.
Oh? what types of problems have you encountered?

well, static controls are not expected to receive keyboard messages......

gotcha

Yeah, basically the CStatic control eats some of its messages, even when notify is set.  On top of that, I think the underlying static common control also may block getting focus, which would prevent keyboard input from arriving.

In general, the CStatic is only good for display controls, even though mouse input seems to work most of the time.

hmm.. well the controls that I use as placeholders on my main dialog are Text boxes.   my own class CDisplay, I've since changed to derive from CEdit, rather than CStatic.. SS_NOTIFY is specified..   still not getting the messages

class CDisplay : public CEdit
{
// ... construction etc..

// Overrides
      // ClassWizard generated virtual function overrides
      //{{AFX_VIRTUAL(CDisplay)
      public:
      virtual BOOL Create(LPCTSTR lpszWindowName, const RECT& rect, CWnd* pParentWnd, UINT nID);
      //}}AFX_VIRTUAL

// ..

protected:
      //{{AFX_MSG(CDisplay)
      afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct);

--------------------
implementation:
--------------------

BOOL CDisplay::Create(LPCTSTR lpszWindowName, const RECT& rect, CWnd* pParentWnd, UINT nID)
{
      // Setup Specifics for this new window class

      DWORD dwStyle = WS_CHILD | WS_VISIBLE | SS_NOTIFY | CS_DBLCLKS ;
      //CCreateContext* pContext = NULL;

      return CEdit::Create(dwStyle, rect, pParentWnd, nID);
//      return CWnd::Create(_T("STATIC"), lpszWindowName, dwStyle, rect, pParentWnd, nID, pContext);
}

Well, first of all, if it's an edit control then SS_NOTIFY is the same as ES_NOHIDESEL and CS_DBLCLKS is teh same as ES_UPPERCASE, so you can remove them.  Second, you are probably better off still calling the CWnd::Create, but with _T("Edit").  Let me just give this a try and see if it works.

Really want your control to have the focus?
If not, then will make more sense to trap keys at owner window.

well it's not "actually an edit control"   - why I originally derived from CStatic, because all it is really is a window which I am completely taking over. A stream from a camera is displayed in it, and the user can draw over it (picture when you watch  a game on TV and they draw arrows and such over the video feed) - only I need to trap for delete and ctrl-z/y to delete or undo/redo drawing actions.   all that undo/redo stuff works just fine using the mouse to test the design, I just couldn't capture the key presses..

that said, I was able to forward the message up and now everything works, but I'd still prefer to understand how to get the messages directly to my "control"

>> Really want your control to have the focus?
>>If not, then will make more sense to trap keys at owner window.

Yeah I guess that does make sense..

Ah, I think the problem was a missing WS_TABSTOP option.  Try this (which worked for me):

BOOL CDisplay::Create(LPCTSTR lpszWindowName, const RECT& rect, CWnd* pParentWnd, UINT nID)
{
      return CWnd::Create(_T("Edit"), lpszWindowName, WS_TABSTOP | WS_CHILD | WS_VISIBLE, rect, pParentWnd, nID);
}

And I'm going to agree with Jaime on this one.  It is better coding practice to implement the functions for undo/redo/etc. in the control, but then to call them when appropriate from the dialog.  This allows the dialog to decide when the keypresses should be passed to the control, and when they should be sent to another control or ignored.

Not to mention it allows you to make buttons to perform the functions as well, just in case the user doesn't read the manual (no, that would never happen :-) ).

>>Really doesn't make sense to me, you are forcing a situation, not all have to be controlled inside your control, could be either the app or the >>parent window, then you can receive a user message or implement a function for your derived control.

well if you consider my control as a "container/surface" into which any number of "user creatable objects" can be added (like a layer in photoshop), and that this container/ surface class knows how to manage the contained objects - that is, adding and removing them, my preference from a design standpoint would be to have the "surface" able to directly receive the keyboard messages (delete, ctrl-z) and handle them by then internally executing the code..  it directly traps the message and handles it.  You are saying it makes more sense for the parent window to trap these messages (I think this is what you are saying), and have the parent responsible for forwarding these messages into the "surface/container" object.  But this means that the parent window needs code to trap messages which itself, will never care about. Doesn't that create an unecessary coupling?  

KurtVon - yes, adding WS_TABSTOP did in fact allow the key messages in.   I wonder then if I go back to CStatic as the base if it will still work?

It may with SS_NOTIFY, but unless you have a good reason it's been my experience that static controls do odd things to controls descended from them.  I've just learned to avoid the whole situation, so I'm not sure how extensive the limitations are.

>>I've just learned to avoid the whole situation,
sounds good to me

You will not provide an undo option via menu? just with keys?
If first, you will need to pass a message to the control anyway.

BTW. It is more friendly to put an undo button instead key shortcut or menu.

>> You will not provide an undo option via menu? just with keys?

>> BTW. It is more friendly to put an undo button instead key shortcut or menu.

no there will be, but this is not a "standard windows app" so to speak, visually it looks more like a full-screen video game.. buttons and controls are actually custom painted and alphablended into/over a video stream as the mouse moves around..  It's actually pretty cool, but it's requiring some odd-thinking in terms of how messages and controls operate..  which is a bit problematic since I'm still relatively new to windows programming.

if you have a full screen aplication it is totally reasonably (<--- I hope it is right spelled) to control your key events at app or main wnd.

reasonable :)