Prev: Pass CWnd or CView to DLL
Next: CDialog::Create serious bug
From: Henryk Birecki on 17 Jan 2009 23:41
OK, I had exactly the same problem. I had a dialog and no matter what
the radio button was getting selected on dialog initialization. I
think I know the reason, but bear with me because I'm doing this
totally form memory and may be using wrong terms.

The radio button in question was the first in the z-order. MFC somehow
selects a "default" button, control... and it is the first one in the
z-order. I do not remember if it can be set by properties. When MFC is
initializing the dialog it sends out all sorts of messages to assure
that the "default" is selected. My solution was to change the z-order
so that a standard button (but not OK, or Cancel) was the first one in
the z-order. That solved the problem.

Cheers,
Henryk

Joseph M. Newcomer <newcomer(a)flounder.com> wrote:

>See below...
>
>On Sat, 17 Jan 2009 00:06:28 -0800 (PST), Woody <ols6000(a)sbcglobal.net> wrote:
>
>>I am using a modeless MFC dialog. The dialog, designed using the
>>dialog editor, contains 2 group boxes, and each group box "contains" a
>>group of 3 radio buttons. Each radio button has a handler invoked when
>>the button is clicked.
>>
>>When the dialog is created, one of the radio buttons (the one with the
>>lowest ID) receives several unexpected WM_COMMAND messages. No button
>>has been clicked at the time this occurs. I need to get rid of these,
>>as they interfere with the proper operation of the dialog.
>>
>>After the initial flurry of unexplained WM_COMMAND messages for
>>IDC_TicksX, clicking on any radio button, including IDC_TicksX,
>>produces the expected single WM_COMMAND, dispatched to the
>>corresponding On-function.
>>
>>Here is the code:
>>
>>[in a class derived from CWnd]
>>if(pFitGrid==NULL)
>>{
>> pFitGrid=new CFitGridWindow(this);
>> pFitGrid->Create(IDD_FitGridWindow,this);
>>}
>>
>>[in FitGridWindow.cpp]
>>BEGIN_MESSAGE_MAP(CFitGridWindow, CDialog)
>> ON_BN_CLICKED(IDC_TicksX, OnTicksX)
>> ON_BN_CLICKED(IDC_TicksY, OnTicksY)
>> ON_BN_CLICKED(IDC_GridX, OnGridX)
>> ON_BN_CLICKED(IDC_GridY, OnGridY)
>> ON_BN_CLICKED(IDC_NoneX, OnNoneX)
>> ON_BN_CLICKED(IDC_NoneY, OnNoneY)
>>END_MESSAGE_MAP()
>****
>What are the control IDs of those IDC_ values? Could you have a conflict with some other
>ID?
>
>I've not seen behavior like this, so if you are getting WM_COMMAND messages, there's
>something going on that is not evident from this code.
>****
>>
>>void CFitGridWindow::OnTicksX()
>>{
>>} <-breakpoint here catches the bogus messages
>*****
>If they are sent via SendMessage, your stack backtrace should reveal who sent them. Study
>it.
> joe
>*****
>>etc
>Joseph M. Newcomer [MVP]
>email: newcomer(a)flounder.com
>Web: http://www.flounder.com
>MVP Tips: http://www.flounder.com/mvp_tips.htm

From: Woody on 18 Jan 2009 02:02
On Jan 17, 8:41 pm, Henryk Birecki <soaringpi...(a)sbcglobal.net> wrote:
> OK, I had exactly the same problem. I had a dialog and no matter what
> the radio button was getting selected on dialog initialization....The radio button in question was the first in the z-order. MFC somehow
> selects a "default" button, control... and it is the first one in the
> z-order. I do not remember if it can be set by properties. When MFC is
> initializing the dialog it sends out all sorts of messages to assure
> that the "default" is selected. My solution was to change the z-order
> so that a standard button (but not OK, or Cancel) was the first one in
> the z-order.

The good news is, this also solves my problem. The bad news is, the
button has to be visible.

I added a standard pushbutton, gave it the "default" property, made it
first in the tab order (which I think is the same as z-order), and
gave it the lowest ID (out of superstition). This eliminated the
WM_COMMAND messages to the radio button. If I then gave the pushbutton
the Visible=false property, the WM_COMMAND messages to the radio
button come back.

What a dumb design of MFC, and isn't it just like MS to not document
this behavior.
From: David Ching on 18 Jan 2009 09:16

"Woody" <ols6000(a)sbcglobal.net> wrote in message
news:1963dd12-e478-413f-b2d4-b5461bb6d4af(a)o40g2000prn.googlegroups.com...
> The good news is, this also solves my problem. The bad news is, the
> button has to be visible.
>
> I added a standard pushbutton, gave it the "default" property, made it
> first in the tab order (which I think is the same as z-order), and
> gave it the lowest ID (out of superstition). This eliminated the
> WM_COMMAND messages to the radio button. If I then gave the pushbutton
> the Visible=false property, the WM_COMMAND messages to the radio
> button come back.
>
> What a dumb design of MFC, and isn't it just like MS to not document
> this behavior.

I think many years ago I was also bitten by this at 2 am during an all-niter
that was due at 8 am. Way to go HenryK for your answer!!

I think I solved it by simply changing the tab order so another control was
first in the dialog. It may have introduced a tabbing order problem, but it
allowed us to ship the product.

-- David

From: Joseph M. Newcomer on 18 Jan 2009 14:24
See below...
On Sat, 17 Jan 2009 13:30:44 -0800, "David Ching" <dc(a)remove-this.dcsoft.com> wrote:

>"Woody" <ols6000(a)sbcglobal.net> wrote in message
>news:9edf30c0-e21f-4908-96bd-fd51aefc7ab7(a)o4g2000pra.googlegroups.com...
>> I went carefully through the properties of each radio button, and
>> found nothing different between the TicksX and TicksY controls. I also
>> looked at the .rc file, to see if there was any indication of
>> something like a default button. There is no OK or Cancel button in
>> this dialog.
>
>But the TicksX radio button is selected when the dialog appears, right?
>Perhaps MFC automatically selects the first radio button for you at the
>start.
****
(a) this doesn't happen
(b) even if you do CheckRadioButton, no BN_CLICKED notification is sent for the button you
select
****
>
>Are these radio buttons assigned a DDX variable? If so, then whatever that
>variable is set to is what MFC selects after the dialog is created. Maybe
>when MFC selects the button, it generates the WM_COMMAND as if the button
>were clicked, even though it was not and MFC had just programatically
>selected it.
****
I'm not sure it should. But since I never use the MFC radio-button logic (it is Broken As
Designed so badly it is completely unusable). This is certainly something to consider; I
think it would be a serious design error if MFC did this, but Who Knows What Evil Lurks In
The Hearts of DDX?
****
>
>As I said, you need to figure out if this happens in a default, stripped
>down dialog or if it's something in your code. Create another dialog with
>nothing else but the radio button controls and see if you get the bogus
>message or not.
*****
Besides the breakpoint at the OnBnClicked handler, put one in the DoDataExchange of your
dialog and see if the event happens before or after the DoDataExchange. I never
considered the possiblity that this could be generating simulated button-click events, but
if it is, that's yet one more reason to avoid ever using the radio-button DDX mechanism.
joe
*****
>
>-- David
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 18 Jan 2009 14:25
Note also that if you support minimize, it sometimes helps to make sure that you add
if(pFitInput->IsIconized())
pFitInput->ShowWindow(SW_NORMAL);
if it is being shown.
joe

On Sat, 17 Jan 2009 15:33:57 -0800 (PST), Woody <ols6000(a)sbcglobal.net> wrote:

>On Jan 17, 1:30�pm, "David Ching" <d...(a)remove-this.dcsoft.com> wrote:
>> But the TicksX radio button is selected when the dialog appears, right?
>
>No. It is not selected (no focus rectangle), and not checked. I
>removed all the DDX stuff.
>
>I did not mention that the modeless is created non-visible, and
>requires a click on a toolbar to make it visible. That handler is in
>the CMainMenu (CWnd) parent:
>
>[message map]
>ON_COMMAND(ID_ToolBar_I,OnToolBarI)
>
>// Toggle visibility of the FitInput window
>void CMainMenu::OnToolBarI(void)
>{
> int newState;
> if(pFitInput->IsWindowVisible()) newState=SW_HIDE;
> else newState=SW_SHOW;
> pFitInput->ShowWindow(newState);
> return;
>}
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Pass CWnd or CView to DLL
Next: CDialog::Create serious bug