ASSERT when clicking on link in notification

Hi,

in my MFC/WM2003 application I create a notification using the following code (Visual Studio 2005 SP1, WM2003 SDK):

SHNOTIFICATIONDATA sn = {0};

sn.cbStruct = sizeof(sn);
sn.dwID = 1;
sn.npPriority = SHNP_INFORM;
sn.csDuration = 0xFFFF;
sn.hicon = LoadIcon(AfxGetResourceHandle(), MAKEINTRESOURCE(IDI_MAINICON));
sn.clsid = myCLSID;
sn.grfFlags = 0;
sn.hwndSink = GetSafeHwnd();
sn.pszTitle = L"Notification";
sn.pszHTML = ConstructNotificationMessage(type, data);

SHNotificationAdd(&sn);

The HTML contains a '<input type=button name='cmd:45000' value='test'>"' button to click. When the user clicks this button, my application receives a message with wParam=45000 and I can react to that button press.

But when I use the debug build, I am getting an assert thrown in wincore.cpp:

ASSERT(nID == 0 || ::IsWindow(hWndCtrl));

The nID is 45000 (my button) and the hWndCtrl is set to my dwID value (but apparently it is supposed to be some window handle). There are two or three other posts (search groups.google.com with "assert shnotificationadd") where people describe the same problem, but apart from the impression that this may be a bug in MFC there is no solution posted.

I'd appreciate any information as to what the problem here is. It doesn't seem to do any harm (i.e. everything is just working fine, except for the ASSERT), but I would like to get rid of the annoying assert messagebox :-)

Thanks,

Daniel

Answer this question

ASSERT when clicking on link in notification

SolveIt
Reported at https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx FeedbackID=260159
jsmartfoster
ok, that was me only, I think I need to have some more understanding of this - If you are unhappy with it, we can reopen the bug. However I would like to know if you want the notification messages to come to back to your dialog, that happens by default with WM_NOTIFY, you don't have to set this hwndSink for that.

However as another design parameter, if you want inetractive application, then I guess Dialog based interaction with user of the app is better than notifying through the shell.

The other way is to have handle the button clock events on the notification HTML, withing the HTML itself - I am not what is the best way to implement the notification mechanism - but let me again check on if the hwndSink needs to be assigned for getting notification back to the window - BTW are you handling WM_NOTIFY and are you not getting notiofication

Thanks,

Gangadhar
Sarath.
Here are links to other people asking the same question, no answer provided:
- http://groups.google.de/group/microsoft.public.vc.mfc/browse_thread/thread/178ae1bd3fff0e56/f5e842daa1e1d277
- http://groups.google.de/group/microsoft.public.pocketpc.developer/browse_thread/thread/265b180c89891347/cb3192fd5f038f4b
- http://groups.google.de/group/microsoft.public.pocketpc.developer/browse_thread/thread/1ad0473c28a0b63c/7bb3f4b664a7b7f0
I'd really like to get rid of this ASSERT, it's been both in eVC4 as well as Visual Studio 2005, so either I am doing something wrong or it is a really long-standing bug in MFC ;-)

Please help
Forgon
I stabled across this Assert myself but it's easy to avoid it:

I used this code and now I don't get any asserts:

in the header file:

protected:

virtual BOOL OnWndMsg(UINT message, WPARAM wParam, LPARAM lParam, LRESULT* pResult);

in the cpp file:

BOOL CAppDlg::OnWndMsg(UINT message, WPARAM wParam, LPARAM lParam, LRESULT* pResult)

{

if (message == WM_COMMAND)

{

UINT nID = LOWORD(wParam);

HWND hWndCtrl = (HWND)lParam;

int nCode = HIWORD(wParam);

// Is it == to our notification ID

if ( (hWndCtrl != NULL) && (hWndCtrl == (HWND)1) )

{

// Let's handle it

if (OnCmdMsg(nID, nCode, NULL, NULL))

{

if (pResult != NULL)

*pResult = 1;

return TRUE;

}

return FALSE;

}

}

return CDialog::OnWndMsg(message, wParam, lParam, pResult);

}
BortNE24
Remove this line, sn.hwndSink = GetSafeHwnd();
then it should work without any problems.

Thanks,

Gangadhar
Gioking
Gangadhar Heralgi - MSFT wrote:
Remove this line, sn.hwndSink = GetSafeHwnd();
then it should work without any problems.
It does, but it also disables that my application is getting notified when a link is clicked, which is something that I need.

(If it makes any difference, in my code it doesn't actually call GetSafeHwnd() but something like "sn.hwndSink = myMainAppWindow->m_hWnd;", as the notification construction code is not in the class that is supposed to handle the notifications (but the other examples linked above seem to use GetSafeHwnd(), so this shouldn't be any different)

P.S.: The bug I filed about this has been closed as "by design". Unfortunately there was no explanation given what the design purpose was and why MFC throws a warning about something that was done by design ;-(
Joffies

Hi,

This seems to be a bug in MFC. Can you please file this bug with clear reproduction steps at

http://connect.microsoft.com/feedback/default.aspx SiteID=210

We will certainly look into this issue.

Thanks for reporting the issue,

Achal,

VSD, Microsoft
david Laub
I mean you will have to handle WM_COMMAND if you like to recv notification to your dialog - if you want to use GetSafeHWnd(), here is how it is done by other customers

http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=974570&SiteID=1

Thanks,

Gangadhar Heralgi

Perwel

Gangadhar Heralgi - MSFT wrote:

ok, that was me only, I think I need to have some more understanding of this - If you are unhappy with it, we can reopen the bug. However I would like to know if you want the notification messages to come to back to your dialog, that happens by default with WM_NOTIFY, you don't have to set this hwndSink for that.

I don't actually have a dialog but just a CWnd derived class. I also don't want to have the messages go to the window that calls SHNotificationAdd but rather to some other window (maybe a stupid decision, but the documentation indicates usage of hwndSink for that)

However as another design parameter, if you want inetractive application, then I guess Dialog based interaction with user of the app is better than notifying through the shell.

I use notifications to notify the user e.g. about new events (pending / overdue) in my application. I think this is a prime example for using the notifications. Within this notification I want the user to be able to e.g. remind him later or go to my app to view more details.

The other way is to have handle the button clock events on the notification HTML, withing the HTML itself - I am not what is the best way to implement the notification mechanism - but let me again check on if the hwndSink needs to be assigned for getting notification back to the window - BTW are you handling WM_NOTIFY and are you not getting notiofication

I mean you will have to handle WM_COMMAND if you like to recv notification to your dialog - if you want to use GetSafeHWnd(), here is how it is done by other customers

http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=974570&SiteID=1

The user in the link you quoted uses NOTIFY_CODE_HANDLER_EX which is not defined in PPC 2003 SDK (and also not found in MSDN).

I think the issue here may be that I don't intercept the message manually (in WndProc or OnWndMsg as MAA1 showed above) but just added in my message map:

ON_COMMAND(45000, OnNotify)

and assumed MFC would be able to handle this (which it does, but triggering an ASSERT in wincore.cpp:2598).

Maybe the dwID is sent in place of a hWndCtrl as the code assumes that it should never be received by CWnd::OnCommand

ASSERT when clicking on link in notification

Answer this question