enabled button that doesnt take focus

[Chris Becke]

I have an app that needs to go out on an embedded touch screen system.

There is an edit box that needs to have some numbers filled in it, so I thought of placing buttons with the numbers 0, through 9 on the dialog. However the buttons steal focus when clicked, and I'd like focus to *Stay* where the 'virtual' keyboard input is going.

The option at the moment seems to be to subclass the buttons to respond to EM_FOCUS messages to set the focus back to the control id'd in wParam, but that feels very very hackish.

Is there a cleaner way to accept mouse input but not take focus?

[r_z_...@pen_fact.com]

On Fri, 26 Sep 2008 15:27:20 +0200, "Chris Becke"
<chris...@gmail.com> wrote:

>I have an app that needs to go out on an embedded touch screen system.
>
>There is an edit box that needs to have some numbers filled in it, so I thought of placing buttons with the numbers 0, through 9 on the dialog. However the buttons steal focus when clicked, and I'd like focus to *Stay* where the 'virtual' keyboard input is going.
>
>The option at the moment seems to be to subclass the buttons to respond to EM_FOCUS messages to set the focus back to the control id'd in wParam, but that feels very very hackish.

I know I've had this problem, but confess to not remembering details,
and can't find the relevant code. I believe my handler for the
BN_CLICKED message posted a WM_FOCUS message to the control I wanted
to have focus.

>
>Is there a cleaner way to accept mouse input but not take focus?

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 400
Boston, MA 02116
www.penfact.com

[Chris Becke]

I took a peek at the wine source code and, if it actually reflects windows' internals then there is no way to do this cleanly.

the BN_FOCUS notification doesn't pass the control that lost focus, so now that has to be tracked, and things seemed to get confused easilly.

So we subclassed the button(s) and completely replaced the lbutton up / down handlers (which is where the button normally takes focus (according to the wine source and experience))

<r_z_aret@pen_fact.com> wrote in message news:7neqd4loju5pjs9ss...@4ax.com...

[Kavitesh Singh]

Small code snippet which might solve your problem if i understood it correctly.

I have a user login dialog box and i needed to do these things:
1. The default button should be Authenticate - i.e. whenever user presses
enter it should execute code written for authenticate button.
2. The keyboard focus should be set to the edit box where in user will write
the username.

// make the authenticate button default push button
SendMessage(hwnd,(UINT) DM_SETDEFID,(WPARAM) ID_PASSWORD_AUTHENTICATE,0);
//set text in user-id edit control for information
SendMessage(GetDlgItem(hwnd,(IDC_USERID)),WM_SETTEXT,0,(LPARAM)TEXT("Enter
Database User-ID"));
//set caret focus to user id input edit-box
SendMessage(hwnd, WM_NEXTDLGCTL, (WPARAM)GetDlgItem(hwnd,(IDC_USERID)),
TRUE);

I hope this helps.