In release version CTabCtrl message fails to reach main Dialog

[caperover2002]

hi,all

In release version CTabCtrl message fails to reach main Dialog.Here is how the message is handled:


ON_NOTIFY(TCN_SELCHANGE, IDC_TAB_LISTS, OnSelchangeTabLists)

.....


void CTestDlg::OnSelchangeTabLists(NMHDR* pNMHDR, LRESULT* pResult)
{

}

It works in debug version, but not in release version. Why does this happen? I have check some other ON_NOTIFY() works, but not for Tab control.

[mdmd]

Hey,

I just tried this in vc6 and vc7 on win2000 and it worked in both cases in release using default settings. I created and SDI and added a dialog with DoModal().

What's different in your setup ? Is the dialog coming from a dll. The only time I had problems changing pages was when the tabctrl was on a dialog in a dll, both modules using static mfc.

[caperover2002]

well,I made mistake.

Actually I use a derived CMyTabCtrl class from CTabCtrl. The CMyTabCtrl is supposed to intercept the WM_SELCHANGE message first, (I checked that it did receive it), and in that handler CMyTabCtrl post a WM_NOTFIY message to the GetParent(), using

CWnd *pWnd=GetParent();
pNMHDR->code=TVN_SELCHANGE;
pWnd->PostMessage(WM_NOTIFY,0,(LPARAM)pNMHDR);

BTW, in the CMyTabCtrl , ON_NOTIFY_REFLECT is used to map messages and in parent window ON_NOTIFY is used.

But, all these work well in a debug version.


At last,I found that the main dialog did receive the WM_NOTIFY but it did not dispatch to the right handler.

How does windows dispatch WM_NOTIFY? In other words, what should be in PostMessage()? I all tried

pWnd->PostMessage(WM_NOTIFY,GetDlgCtrlID(),(LPARAM)pNMHDR);

It did not work either.

[mdmd]

Ok, its kind of a gray area, eh ? I was reading the docs for a while and got much conflicting information. The solution I found is down the bottom. I just added notes to ask some question cause I was curious about your investigation into this.

I think that some of the notify's are working is by luck ? Maybe the version of the compiler. I converted this project to vc7 to try out both cause I didn't know what you were using; I don't get the same results doing what you do for the tab messages; they never get to the dialog if they are handled in the tabctrl itself.

I think this is design. Can I ask why you used PostMessage() instead of SendMessage() ? Is it because you got a stack fault ?
I think the result of what you were doing with PostMessage() is that the WM_NOTIFY goes to the main message loop and then goes to the control if the control handles the particular message. So I think the main window is getting the message, its just going off to the control again but is 'gone' before it gets there because it looks at some internal settings and knows it shouldn't be getting the message again ? Who Knows.

Here is the solution that works for VC7. This is documented to give you the result you want.

In your tab control class handle your message map this way
ON_NOTIFY_REFLECT_EX(TCN_SELCHANGE, OnTcnSelchange)

And change the return value to the handlers to BOOL.
return FALSE; and the message will also be sent to the parent
return TRUE; and the processing stops here.

[caperover2002]

thanks so much, mdmd! It works now.

Originally posted by mdmd
I think this is design. Can I ask why you used PostMessage() instead of SendMessage() ? Is it because you got a stack fault ?

This is because if I use SendMessage() instead of PostMessage(), the tab control will wait for the return all the time.But, as you see in the dialog WM_NOTIFY handler, the return type is void. So in fact the tab control can never get reply, and it will block there for ever.

[lluisga]

I bumped into the same issue (the application only failed in release, not in debug, and even in that case only in same windows and not in others due to the ON_NOTIFY handle) and in my case at least I could solve the problem only by adding the default parameters to the handle void CDlg::OnNotify(NMHDR* pNMHDR, LRESULT* pResult) that I originally was calling with no parameters.

Hope that helps.