Prev: Pass CWnd or CView to DLL
Next: CDialog::Create serious bug
From: Woody on 17 Jan 2009 03:06
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()

void CFitGridWindow::OnTicksX()
{
} <-breakpoint here catches the bogus messages
etc
From: David Ching on 17 Jan 2009 10:16
"Woody" <ols6000(a)sbcglobal.net> wrote in message
news:e533da30-8785-40bb-8f3b-ddc5f59a5c01(a)w24g2000prd.googlegroups.com...
> 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.
>

Perhaps this is caused by MFC setting the default radio button when the
dialog is created. I don't have an MFC project handy right now. Why don't
you create a sample MFC dialog-based project with some radio buttons and see
if the same WM_COMMAND is sent to the radio button (lowest id) in that one?
Then you could at least know if it is global MFC issue or not. If nothing
else, you may need to set a flag in your code (ugh) that says whether it is
initialized or not and ignore the OnTickX() messages.

Thanks,
David

From: Joseph M. Newcomer on 17 Jan 2009 13:14
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 17 Jan 2009 14:47
On Jan 17, 10:14 am, Joseph M. Newcomer <newco...(a)flounder.com> wrote:
> What are the control IDs of those IDC_ values?  Could you have a  conflict with some other
> ID?
If there is, it isn't obvious. The control receiving the unexplained
messages has IDC 3671. Here is the relevant part of resource.h:

#define IDC_TicksX 3671
#define IDC_DebugOutput07 3672
#define IDC_TicksY 3672
#define IDC_DebugOutput08 3673
#define IDC_NoneX 3673
#define IDC_DebugOutput09 3674
#define IDC_GridX 3674
#define IDC_DebugOutput10 3675
#define IDC_GridTypeX 3675
#define IDC_DebugOutput11 3676
#define IDC_RADIO4 3676
#define IDC_GridTypeX2 3677
#define IDC_GridTypeY 3677

The debug output IDCs are in a different dialog. I also searched all
files in the project for "3671" and its hex equivalent. But to be sure
it isn't due to an ID conflict, I have manually renumbered the IDs in
the affect dialog to a unique range and rebuilt everything. I still
get the same unwanted messages.

> If they are sent via SendMessage, your stack backtrace should reveal who sent them.  Study it.

Here is the stack. The first entry is the message handler. message 273
(=0x111) is WM_COMMAND. 3679 is the IDC_TicksX (renumbered from the
above excerpt). The message is being sent during the modeless dialog
Create; that code is in CMainMenuToolbar. User has clicked within the
main menu (CWnd-derived), and that invokes the modeless Create. I
tried tracing through CreateDialogIndirect, but my MFC source code
apparently doesn't match, so I just get the disassembler.

Any assistance will be appreciated. I also tried to use the tool ATL/
MFC Tracer to see where the message was coming from, but this tool is
essentially undocumented.

CFitGridWindow::OnTicksX() Line 64
_AfxDispatchCmdMsg(CCmdTarget * pTarget=0x0830a290, unsigned int
nID=3679, int nCode=0, void (void)* pfn=0x00954089, void *
pExtra=0x00000000, unsigned int nSig=56, AFX_CMDHANDLERINFO *
pHandlerInfo=0x00000000) Line 82
CCmdTarget::OnCmdMsg(unsigned int nID=3679, int nCode=0, void *
pExtra=0x00000000, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000) Line
381 + 0x27 bytes
CDialog::OnCmdMsg(unsigned int nID=3679, int nCode=0, void *
pExtra=0x00000000, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000) Line
85 + 0x18 bytes
CWnd::OnCommand(unsigned int wParam=3679, long lParam=198698) Line
2300
CWnd::OnWndMsg(unsigned int message=273, unsigned int wParam=3679,
long lParam=198698, long * pResult=0x0038ed68) Line 1755 + 0x1e bytes
CWnd::WindowProc(unsigned int message=273, unsigned int wParam=3679,
long lParam=198698) Line 1741 + 0x20 bytes
AfxCallWndProc(CWnd * pWnd=0x0830a290, HWND__ * hWnd=0x00030826,
unsigned int nMsg=273, unsigned int wParam=3679, long lParam=198698)
Line 240 + 0x1c bytes
AfxWndProc(HWND__ * hWnd=0x00030826, unsigned int nMsg=273, unsigned
int wParam=3679, long lParam=198698) Line 389
7e418734
[Frames below may be incorrect and/or missing, no symbols loaded for
user32.dll]
....
CWnd::CreateDlgIndirect(const DLGTEMPLATE *
lpDialogTemplate=0x07bdb358, CWnd * pParentWnd=0x0830bb78, HINSTANCE__
* hInst=0x00400000) Line 307 + 0x2a bytes
CDialog::CreateIndirect(const DLGTEMPLATE *
lpDialogTemplate=0x07bdb358, CWnd * pParentWnd=0x0830bb78, void *
lpDialogInit=0x00000000, HINSTANCE__ * hInst=0x00400000) Line 211
CDialog::CreateIndirect(void * hDialogTemplate=0x07bdb358, CWnd *
pParentWnd=0x0830bb78, HINSTANCE__ * hInst=0x00400000) Line 188 + 0x16
bytes
CDialog::Create(const char * lpszTemplateName=0x000000f1, CWnd *
pParentWnd=0x0830bb78) Line 170 + 0x14 bytes
CDialog::Create(unsigned int nIDTemplate=241, CWnd *
pParentWnd=0x0830bb78) Line 601 + 0x18 bytes
CMainMenu::MainMenuToolbar() Line 95 + 0x21 bytes
CMainMenu::SelectionMade() Line 1881
CMainMenu::OnLButtonDown(unsigned int nFlags=1, CPoint point={...})
Line 1706 + 0x8 bytes
CWnd::OnWndMsg(unsigned int message=513, unsigned int wParam=1, long
lParam=20972204, long * pResult=0x0038fcbc) Line 2169
CWnd::WindowProc(unsigned int message=513, unsigned int wParam=1, long
lParam=20972204) Line 1741 + 0x20 bytes
AfxCallWndProc(CWnd * pWnd=0x0830bb78, HWND__ * hWnd=0x000507fa,
unsigned int nMsg=513, unsigned int wParam=1, long lParam=20972204)
Line 240 + 0x1c bytes
AfxWndProc(HWND__ * hWnd=0x000507fa, unsigned int nMsg=513, unsigned
int wParam=1, long lParam=20972204) Line 389
....
AfxInternalPumpMessage() Line 183C++


From: Woody on 17 Jan 2009 14:53
On Jan 17, 7:16 am, "David Ching" <d...(a)remove-this.dcsoft.com>
wrote:
> Perhaps this is caused by MFC setting the default radio button when the
> dialog is created.

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.

Another bit of information is that if I add an OnInitDialog handler,
the message occurs after that handler has been reached (there is no
code there except return TRUE).

> If nothing else, you may need to set a flag in your code (ugh) that says whether it is
> initialized or not and ignore the OnTickX() messages.

I tried this also, and it is trickier than it seems. Depending on what
the user is doing, the "ignore/process" flag changes dynamically
during the process.
 |  Next  |  Last
Pages: 1 2 3 4
Prev: Pass CWnd or CView to DLL
Next: CDialog::Create serious bug