Radio button click event being sent when Dialog gains focus
John Graumann
If am on the wrong group for this, please let me know. On to my problem:
I have a group of radio buttons in a Modal dialog box. They all have Group
and Auto unchecked in the resource file, as I am handling them myself. For
each button, I have a message handler for the ON_CLICKED (BN_CLICKED) event.
In the message handler, the appropriate radio buttons are "checked" and
"unchecked", and some other handler code is executed, depending on which
button is pressed.
The problem I am having is this: if a radio button (I have tried both the
regular and push-like styles) has 'focus' (as can be verified by the focus
rectangle around it), clicking on a different app in Windows, and then
clicking back to my app causes the radio button to be "clicked". This is not
desirabable behaviour. For example, when the user checks a certain radio
button, the OnClick handler is required to configure some hardware. If the
hardware config. fail for some reason, the button is unchecked. However, if
the user then clicks another app in Windows, and clicks back to my app, the
configuration will be attempted again, because the radio button still had
focus from the last time.
Another way to repeat it is to click a radio button, and drag the mouse
away, so that the radio button's window has focus, but it is not clicked. If
I tab to another window, and then tab back, the ON_CLICKED event is fired.
Is this a known problem, and if so, is there a workaround for this ? Short
of setting focus to another control (this doesnt happen with any other
control as far as I can tell) when the the app itself loses focus, I don't
know how else to handle this.
Any thoughts ?
Thanks for any help.
John Graumann
Jeff Partch
news:aulamv$dg0$1...@canopus.cc.umanitoba.ca...
This seems like the documented behavior. According to the "Button
Default Message Processing" topic at the following URL...
...this is how the WM_SETFOCUS message is handled...
"Draws a focus rectangle on the button getting the focus. For radio
buttons and automatic radio buttons, the parent window is sent a
BN_CLICKED notification message".
...and according to the "Dialog Box Default Message Processing" topic at
this URL...
...this is how the WM_ACTIVATE message is handled...
"Restores the input focus to the control identified by the previously
saved handle if the dialog box is activated. Otherwise, the procedure
saves the handle to the control having the input focus".
One solution from off the top of my head is to add a member variable to
the CDialog derived class...
protected:
BOOL m_bInActivate;
...initialize it to FALSE in the ctor, and add a handler for the
WM_ACTIVATE message. Then set it to TRUE before calling the base class,
and set it back to FALSE afterward...
VOID
CSomeDlg::OnActivate(
UINT nState,
CWnd* pWndOther,
BOOL bMinimized
)
{
m_bInActivate = TRUE;
CDialog::OnActivate(
nState, pWndOther, bMinimized);
m_bInActivate = FALSE;
}
...then in your BN_CLICKED handler, you can test it...
VOID
CSomeDlg::OnRadio1(
VOID
)
{
if (!m_bInActivate)
{
TRACE(_T("BN_CLICKED\n"));
}
}
...but double-check me, it may be more complicated than that or it may
just be the wrong approach entirely.
--
Jeff Partch [VC++ MVP]
Joseph M. Newcomer
which it mattered if there was a redundant button click.
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www3.pgh.net/~newcomer
MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm
John Graumann
radio button by default, but having this happen during a dialog activation
is not good in my case. As someone else said, 9 times out of 10, a redundant
click on a radio button doesn't matter. Only in cases like mine, when
hardware is being configured when the button is clicked, do issues like this
arise.
I will try something similar to what you suggest. Thanks for your help.
John
"Jeff Partch" <je...@mvps.org> wrote in message
news:eJ4EN6srCHA.1776@TK2MSFTNGP10...
Jus...@boowho.gone
wrote:
>Sounds like you've hit on it. I can see why getting focus should click a
>radio button by default, but having this happen during a dialog activation
>is not good in my case. As someone else said, 9 times out of 10, a redundant
>click on a radio button doesn't matter. Only in cases like mine, when
>hardware is being configured when the button is clicked, do issues like this
>arise.
When I have had to control hardware I have always taken a different
approach to this problem. This may work for you... or not. :-) But it
has *always" worked for me.
I think of the GUI (in this context) as a metaphorical "state
machine." The user can click away endlessly and forever on the GUI
elements (buttons, combo's, whatever) thus changing their "state." The
code shouldn't process any of these events at all during the time the
user is click happy. This is where most people go wrong. Writing code
to do something *every time* an event happens in a control is a road
to madness.
Eventually the user will decide to *apply* the changes they have made
to the GUI, which should then and only then affect the actual
hardware. I've literally seen THOUSANDS of lines of code written to
accommodate the "real-time" action of clicking and "un-clicking"
buttons or similar controls. Reams of code to figure out what was
clicked and how to backtrack the action if it's un-clicked. Forget
about it! Just process them all at the right time. The "apply" time.
So, add an "Apply" button to the GUI. Don't process _anything_[*] in
the GUI until the user pushes Apply, then enumerate the appropriate
controls, get their "state," ie: data values, and send it to the
hardware at that time.
It's amazing how many problems simply vanish once this design decision
is put in place. A bonus is the code is less complicated and much
easier to maintain. No backtracking, no focus problems, etc. I've
never had a command button exhibit the behavior of the "self clicking"
radio button.
There could be hardware dependant reasons why this would not work, but
most of the time I find it's the programmer's way of thinking that is
the biggest hurdle.
[*] Within reason of course.
Dilbert: What was that popping sound?
Dogbert: A paradigm shifting without a clutch.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Joseph M. Newcomer
That's what I meant when I said I'd never written a program for which redundant button
clicks on radio buttons had meaning. Radio buttons just configure things. There is usally
some "action" button, sometimes overt, sometimes implied (for example, switching to
another tab on the dialog), that commits the selected state to the device.
joe
Joseph M. Newcomer [MVP]