What's wrong here?

[Earn]

I must be missing something obvious here but I can't find it.  In this example code the @IDKEYDOWN message is received until the button is pressed then the message no longer registers.  How do I get the parent window to continue to receive the keystroke messages after a control gets focus?

Code Select Expand

CONST EDIT_1 = 1
CONST EDIT_2 = 2
CONST BUTTON_3 = 3
DIALOG d1
CREATEDIALOG d1,0,0,300,156,0x80C80080,0,"Caption",&d1_handler
CONTROL d1,@EDIT,"",11,32,29,28,0x58800804|@CTEDITRO,EDIT_2
CONTROL d1,@EDIT,"",8,2,238,22,0x50800800|@CTEDITRIGHT|@CTEDITRO,EDIT_1
CONTROL d1,@BUTTON,"Button1",115,90,70,20,0x50000000,BUTTON_3

OPENCONSOLE
SHOWDIALOG d1
WAITUNTIL d1=0
CLOSECONSOLE
END

SUB d1_handler
SELECT @MESSAGE
CASE @IDINITDIALOG
CENTERWINDOW d1
/* Initialize any controls here */
CASE @IDCLOSEWINDOW
CLOSEDIALOG d1,@IDOK
CASE @IDKEYDOWN
SETCONTROLTEXT(d1,EDIT_1,HEX$(@WPARAM))
PRINT HEX$(@WPARAM)
CASE @IDCONTROL
SELECT @CONTROLID
CASE EDIT_1
/* respond to edit notifications here */
CASE BUTTON_3
IF @NOTIFYCODE = 0
/*button clicked*/
ENDIF
ENDSELECT
ENDSELECT
RETURN
ENDSUBEarn

[Ionic Wind Support Team]

Earn,
"focus" refers to input focus, meaning Windows diverts all keystrokes to the control that has the input focus.  If you are looking to process something particular, such as arrow keys, see this responds I gave to Larry a very short time ago:

http://www.ionicwind.com/forums/index.php/topic,2909.0.html

Read the Microsoft article mentioned in the post.

Paul.

[Ionic Wind Support Team]

http://msdn.microsoft.com/en-us/library/ms645425(VS.85).aspx

If you wanted to process all keyboard messages yourself you could reply to WM_GETDLGCODE with DLGC_WANTALLKEYS but that would mean edit controls would probably not work.

Paul.

[Earn]

Paul,
I'm not saying that the answer is not there but I'm not seeing it.  Just to see what happens I tried replying to WM_GETDLGCODE with DLGC_WANTALLKEYS but I have the same result.  After I click on the button or in the edit control my handler no longer gets the @IDKEYDOWN messages.
Earn

[Ionic Wind Support Team]

Actually that message is received by the controls, not the parent window, sorry.

Perhaps if you could explain why you want to override default keyboard handling in a parent dialog I could be of more help.  For example if you are trying to use the function keys then keyboard accelerators are the answer. 

Paul.

[Earn]

I'm trying to setup a graphical keyboard.  If the user clicks a button I display the character in a listbox.  I want to do the same if the user uses the keyboard.
Earn

[Ionic Wind Support Team]

Graphical keyboard?  Meaning like an onscreen one?

Just give the button text mnemonics (the &). 

Of course I would approach it differently myself.  Number one I wouldn't use a dialog, I would use a nice bitmap image of a keyboard and map rectangles to each key, hit testing for each one.  But this will work in a pinch.

Code Select Expand


CONST BUTTON_1 = 1
CONST BUTTON_2 = 2
CONST BUTTON_3 = 3
CONST BUTTON_4 = 4
DIALOG d1
CREATEDIALOG d1,0,0,300,202,0x80C80080,0,"Caption",&d1_handler
CONTROL d1,@SYSBUTTON,"&A",17,28,33,20,0x50000000,BUTTON_1
CONTROL d1,@SYSBUTTON,"&B",63,28,33,20,0x50000000,BUTTON_2
CONTROL d1,@SYSBUTTON,"&C",109,28,33,20,0x50000000,BUTTON_3
CONTROL d1,@SYSBUTTON,"&D",154,28,33,20,0x50000000,BUTTON_4
CONTROL d1,@EDIT,"",17,2,139,20,@CTEDITRO,999

DoModal d1

SUB d1_handler
SELECT @MESSAGE
CASE @IDINITDIALOG
CENTERWINDOW d1
/* Initialize any controls here */
CASE @IDCLOSEWINDOW
CLOSEDIALOG d1,@IDOK
CASE @IDCONTROL
SELECT @CONTROLID
CASE BUTTON_1
IF @NOTIFYCODE = 0
/*button clicked*/
SetControlText d1,999,GetControlText(d1,999)+"A"
ENDIF
CASE BUTTON_2
IF @NOTIFYCODE = 0
/*button clicked*/
SetControlText d1,999,GetControlText(d1,999)+"B"
ENDIF
CASE BUTTON_3
IF @NOTIFYCODE = 0
/*button clicked*/
SetControlText d1,999,GetControlText(d1,999)+"C"
ENDIF
CASE BUTTON_4
IF @NOTIFYCODE = 0
/*button clicked*/
SetControlText d1,999,GetControlText(d1,999)+"D"
ENDIF
ENDSELECT
ENDSELECT
RETURN
ENDSUB


[Earn]

Sorry for the delay between these posts.  Life got in the way and I couldn't get right back.

I understand what you're showing me here but that doesn't get me the extended (lparam) information for the keyboard activity.  I guess the open question is still: Why does the dialog receive wm_keydown messages before a contol is used and stops receiving wm_keydown messages after a control is used?

Earn

[Ionic Wind Support Team]

Earn,
Because that is how Microsoft designed it.  When a dialog is first started none of the controls have input focus so the messages get sent to the dialogs handler.  Once a control gets the input focus the dialog can never get it back.

The only way around it is to circumvent normal message processing, and designed your own message loop instead of using WAIT/WAITUNTIL.  And that will only work for non modal dialogs, in other words dialogs shown with ShowDialog.  In your message loop where you use API functions like GetMessage, TranslateMessage and DispatchMessage you can intercept the key messages before you send them along to the dialog.  DoModal processing is handled differently, the message loop for modal dialogs is buried in the system API and handled by the OS.

Another way to do it, would be to create your own button class and return DLGC_WANTALLKEYS and let the button see if a key relates to itself.  But I don't think it would receive any keyboard messages unless it has input focus.

Dialogs are meant as containers for controls, nothing more.  Use a window instead and save yourself the headaches.

Paul.

[Earn]

OK.  Now I get it.  But why MS felt that a button should retain input focus boggles the mind. 

"map rectangles to each key, hit testing for each one"   
In laymans terms, how would one go about doing this? 

Earn

[Ionic Wind Support Team]

The API function PtInRect will tell you whether or not the mouse coordinates fall within the bounds of a rectangle.   All you need to do is have an array of WINRECT udt's, and figure out the rectangle location of each key. 

You could also use a window and do it the button way, because a window does not have the default message processing of a dialog unless you use EnableTabs.  Which is why I mentioned to use a window and save yourself the headache.

OK.  Now I get it.  But why MS felt that a button should retain input focus boggles the mind.

Because the spacebar will activate the button, checkbox or radiobutton control.  So it has a need for input focus in a dialog. 

Paul.

[Earn]

Gotit now. 
Thanks for all your help Paul.
Earn