Prev: Pass CWnd or CView to DLL
Next: CDialog::Create serious bug
From: Joseph M. Newcomer on 17 Jan 2009 15:15
That's very interesting, and completely off-the-wall! You are definitely getting a
WM_COMMAND:BN_CLICKED notification arriving, and no discernable reason for how it got
there!

MOre below...

On Sat, 17 Jan 2009 11:47:48 -0800 (PST), Woody <ols6000(a)sbcglobal.net> wrote:

>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
****
This is what is amazing! You're right; there's no reason this BN_CLICKED notification
should ever appear.

I'd be reduced to single-stepping here. I'd set a breakpoint at the hook function that
recognizes the creation. Then I'd probably set a breakpoint at AfxWndProc and do more
single-stepping (step-into, F11). Tedious as all-get-out, but I'm not sure how else I
could begin to track down what is causing this.

Are these buttons regular CButtons or are they a subclass of CButton? If a subclass, I'd
set a lot of breakpoints in the subclass locations depending on what it does. I'd also be
suspicious of WM_NOTIFY messages to the parent that might be triggering some other weird
behavior.

But you've definitely got something first-order-weird happening here. I don't have any
good insight and would be reduced to the analysis methods I've just outlined.
joe
*****
>[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++
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: David Ching on 17 Jan 2009 16:30
"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.

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.

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.

-- David

From: Woody on 17 Jan 2009 18:24
On Jan 17, 12:15 pm, Joseph M. Newcomer <newco...(a)flounder.com> wrote:
> I'd be reduced to single-stepping here.  I'd set a breakpoint at the hook function that
> recognizes the creation.  Then I'd probably set a breakpoint at AfxWndProc and do more
> single-stepping (step-into, F11).  Tedious as all-get-out, but I'm not sure how else I
> could begin to track down what is causing this.

Even more tedious when the debugger doesn't recognize the source, and
you're single-stepping through assembler. I tried that until I could
no longer keep track of where I was, but no further info.

> Are these buttons regular CButtons or are they a subclass of CButton?

They are regular CButtons, created by the dialog editor. And, as far
as I can tell, all 6 are identical (except that 2 have the "group"
attribute), but only 1 misbehaves.

 In my opinion, a tool like ATL/MFC Tracer would be very helpful, but
I couldn't understand how it works. I thought of trying to build the
project under VS6, which has an understandable trace tool, but that is
a *big* undertaking.

Another possibility is that somehow a mouse-click with the right
position is already enqueued at the time the dialog is created. This
doesn't make much sense either, but it should be easy enough to check.
From: Woody on 17 Jan 2009 18:33
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;
}

From: Alexander Grigoriev on 17 Jan 2009 19:17
I think the radio button group state is set by BM_CLICK message. In this
case, the button also sends BN_CLICK notification to the parent window.

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
news:uie4n4d5dp9ka6sld03ktrbr0k05f4kqhp(a)4ax.com...
> That's very interesting, and completely off-the-wall! You are definitely
> getting a
> WM_COMMAND:BN_CLICKED notification arriving, and no discernable reason for
> how it got
> there!
>
> MOre below...
>
> On Sat, 17 Jan 2009 11:47:48 -0800 (PST), Woody <ols6000(a)sbcglobal.net>
> wrote:
>
>>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
> ****
> This is what is amazing! You're right; there's no reason this BN_CLICKED
> notification
> should ever appear.
>
> I'd be reduced to single-stepping here. I'd set a breakpoint at the hook
> function that
> recognizes the creation. Then I'd probably set a breakpoint at AfxWndProc
> and do more
> single-stepping (step-into, F11). Tedious as all-get-out, but I'm not
> sure how else I
> could begin to track down what is causing this.
>
> Are these buttons regular CButtons or are they a subclass of CButton? If
> a subclass, I'd
> set a lot of breakpoints in the subclass locations depending on what it
> does. I'd also be
> suspicious of WM_NOTIFY messages to the parent that might be triggering
> some other weird
> behavior.
>
> But you've definitely got something first-order-weird happening here. I
> don't have any
> good insight and would be reduced to the analysis methods I've just
> outlined.
> joe
> *****
>>[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++
>>
> 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