beep in dialog

I create a modal dialog with DialogBoxParam().  The dialog contains several items including buttons and editboxes-all subclassed.  I set focus to the dialog window.  When I type I get a beep with every keystroke.  I trap WM_KEYDOWN, WM_KEYUP,WM_CHAR,WM_SYSKEYDOWN,WM_SYSCHAR.  How can I stop this madness???
Thank You
PS If I set focus to one of the editboxes there is no beep, but I don't want to do this.
LVL 1
marvinmAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
DarrinEConnect With a Mentor Commented:
Subclassing is a last resort in this matter - Well, without seeing the bulk of the code - its a bit hard - what I have done in one program is use ShowCaret for a similar problem.

The ShowCaret function shows the caret only if it has a current shape and has not been hidden two or more times consecutively. If the given window does not own the caret, the caret is not shown. If the hwnd parameter is NULL, the ShowCaret function shows the caret only if it is owned by a window in the current task.

Hiding the caret is cumulative. If the HideCaret function has been called five times consecutively, ShowCaret must be called five times to show the caret.
The caret is a shared resource. A window should show the caret only when it has the input focus or is active.

The alternative to this and subclassing is even simpler - why not use a static textbox ? No cursor - no focus and no other problems ?

For the beep to occur - something other than the dialog (may a control which cannot accept keystrokes) has the focus because a dialog processes lost key strokes without user intervention
0
 
marvinmAuthor Commented:
Adjusted points to 400
0
 
MadshiCommented:
Please show us the code of the "lpDialogFunc".

Regards, Madshi.
0
Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

 
jhanceCommented:
You're getting the beep because whatever window currently has the focus is not processing the keys you are giving it.  Hence, the beep.  In a dialog box, only the controls are generally able to process key strokes.  If none of the controls has the focus, then what has the focus.  Chances are it's the dialog window itself.  If you really need to do this, you need to subclass the dialog window and process ALL of the keystrokes to your liking.
0
 
marvinmAuthor Commented:
I set focus to the dialog window, but I do have a default button set.  It looks like this button is getting a keydown, keyup, and char messages.  I will use spy++ on Monday to see exactly what is happening, and post my code.
Thank You - mm
0
 
marvinmAuthor Commented:
Spy++ indicates that my OK button is receiving a keydown, char, and keyup message.  When I try to log the events I only 'see' the keydown and keyup. Here is a stripped down version of my message processing function. vtest_msg just writes to a file.

static LRESULT CALLBACK MyProc(HWND hwnd,UINT iMsg,WPARAM wParam,LPARAM lParam)
{
            case WM_CHAR:
                        vtest_msg("have char");
                  return 0;
            case WM_KEYUP:
                        vtest_msg("have keyup");
                  return 0;
            case WM_KEYDOWN:
                        vtest_msg("have keydown");
                      return 0;
      } // switch on message

      return (CallWindowProc((WNDPROC)GetWindowLong(hwnd,GWL_USERDATA),hwnd,iMsg,wParam,lParam));
} // MyProc
0
 
marvinmAuthor Commented:
Of course, I should have
switch (iMsg) {
above.
0
 
MadshiCommented:
Please do the same in the "lpDialogFunc".
0
 
marvinmAuthor Commented:
This is a slimmed down version of my dialog message function.  I do not get any of these message when I type.
static BOOL CALLBACK MyDlgProc(HWND hDlg,UINT iMsg,WPARAM wParam,LPARAM lParam)
{
    switch (iMsg) {
      case WM_CHAR:
                vtest_msg("DlgProc() WM_CHAR");
            return TRUE;
      case WM_KEYDOWN:
                test_msg("DlgProc() WM_KEYDOWN");
            return TRUE;
      case WM_KEYUP:
                test_msg("DlgProc() WM_KEYUP");
            return TRUE;              case WM_INITDIALOG:
                // some processing
            return FALSE;
      case WM_COMMAND:
                test_msg("DlgProc() WM_COMMAND");
            return TRUE;
      }  /** switch **/
      return(FALSE);
} // MyDlgProc(HWND,UINT,WPARAM,LPARAM)
0
 
marvinmAuthor Commented:
Perhaps if my OK button could trap the WM_CHAR mesage I would be all set.  spy indicates that it is getting the WM_CHAR message, but the message is not making it to my processing loop!?
0
 
marvinmAuthor Commented:
Please see previous comments.
0
 
DarrinECommented:
Can I ask what this dialog is intended for ? It has editboxes so why is the focus not going to one of them for user input etc - if we can understand what you are trying to do with the dialog then a solution miught be nearer than you think <s>

DarrinE
0
 
marvinmAuthor Commented:
The editbox is read only, and we do not want a cursor displayed.  It is really only used to display output when certain buttons on the dialog are clicked.  The buttons also have a keyboard interface, which is where the beeping comes in.  I have tried to set focus to the editbox and hide the cursor, but have had no success. (with hiding the cursor, that is)
Thank You.
0
 
jhanceCommented:
I'll go back to my original suggestion which it seems you never tried.  You need to subclass this dialog window so that you get ALL of it's keyboard messages so you can "eat" them.  

The message pump for a dialog only send messages to the window that it thinks should go there.  General key press messages don't go to a dialog because there is nothing there to process them.  They get sent to the control with the focus by default.  But your default control is a read-only edit control.  It can't accept any keyboard input, can it?

As far as the cursor is concerned, have this dialog display it's own cursor which is invisible.  That's the correct way of doing it.
0
 
marvinmAuthor Commented:
I could swear that I had tried HideCursor() before without success.  I tried again and works great.  Maybe I was not calling in the correct place on my previous attempts.  I am calling now when my editbox gets focus.
Thanks to all.
0
 
DarrinECommented:
glad I could help
0
All Courses

From novice to tech pro — start learning today.