• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 586
  • Last Modified:

WM_KEYDOWN no longer picked up ??

My problem is that WM_KEYDOWN messages seem to stop getting picked up at a certain point in my hierarchy and I can't figure out why.


in my WinApp pretranslate message:

if(pMsg->message==WM_KEYDOWN)
{
      TRACE(_T("GOT KEYDOWN\n"));
}

it gets picked up.

my main dialog picks it up as well.

I have a CStatic derived control in my dialog.  It's PreTranslateMessage is getting executed but it's not picking up WM_KEYDOWN anymore. I can't figure out why. What should I look for?  I tried making my control derive from CDialog instead, but that made no difference.

thanks!
-Paul
0
PMH4514
Asked:
PMH4514
  • 11
  • 7
  • 7
2 Solutions
 
KurtVonCommented:
Is the notify style specified for the static control?  By default it is off.

Hope this helps.
0
 
PMH4514Author Commented:
i'm not sure, how do I check?
0
 
KurtVonCommented:
Depends how it was created.  If you caled the Create or CreateEx function you just need to add the SS_NOTIFY.  If you are subclassing an existing static control then just check teh notify property in the dialog.

In general, I find deriving controls from CStatic often gets me in trouble.  I tend to use the CEdit or CButton controls myself.
0
Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

 
Jaime OlivaresSoftware ArchitectCommented:
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.
0
 
PMH4514Author Commented:
>>  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?
0
 
Jaime OlivaresSoftware ArchitectCommented:
well, static controls are not expected to receive keyboard messages......
0
 
PMH4514Author Commented:
gotcha
0
 
KurtVonCommented:
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.
0
 
PMH4514Author Commented:
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
0
 
PMH4514Author Commented:
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);
}
0
 
KurtVonCommented:
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.
0
 
Jaime OlivaresSoftware ArchitectCommented:
Really want your control to have the focus?
If not, then will make more sense to trap keys at owner window.
0
 
PMH4514Author Commented:
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"
0
 
PMH4514Author Commented:
>> 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..
0
 
Jaime OlivaresSoftware ArchitectCommented:
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.
0
 
KurtVonCommented:
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);
}
0
 
KurtVonCommented:
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 :-) ).
0
 
PMH4514Author Commented:
>>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?


0
 
KurtVonCommented:
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.
0
 
PMH4514Author Commented:
>>I've just learned to avoid the whole situation,
sounds good to me
0
 
Jaime OlivaresSoftware ArchitectCommented:
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.
0
 
Jaime OlivaresSoftware ArchitectCommented:
BTW. It is more friendly to put an undo button instead key shortcut or menu.
0
 
PMH4514Author Commented:
>> 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.

0
 
Jaime OlivaresSoftware ArchitectCommented:
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.
0
 
PMH4514Author Commented:
reasonable :)
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Microsoft Office 2010

This course will introduce you to the interfaces and features of Microsoft Office 2010 Word, Excel, PowerPoint, Outlook, and Access. You will learn about the features that are shared between all products in the Office suite, as well as the new features that are product specific.

  • 11
  • 7
  • 7
Tackle projects and never again get stuck behind a technical roadblock.
Join Now