I have a property sheet with a ListView and a few textboxes. I am attempting to catch the event when the user clicks on the ListView and determine what item they clicked. To do this, I am using the WM_NOTIFY event. The WM_NOTIFY fires when the ListView is clicked, but the lParam parameter points to an invalid memory location.
INT_PTR CALLBACK DialogProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch(uMsg)
{
case WM_NOTIFY:
{
//LPNMHDR pnmh = (LPNMHDR)lParam;
//switch(pnmh->code)
LPNMITEMACTIVATE lpn = (LPNMITEMACTIVATE)lParam;
switch(lpn->hdr.code)
{
case LVN_ITEMACTIVATE:
{
switch(lpn->hdr.idFrom)
{
case IDC_USED_ADDR:
{
OnUsedAddr(hWnd, lParam);
return FALSE;
}
}
}
}
}
}
return FALSE;
}
Casting the lParam as an LPNMITEMACTIVATE makes no difference, the memory location is invalid. When attempting to run in debug mode, the application breaks at switch(lpn->hdr.code) with the message "Unhandled exception at 0x0041425e in cfgtest.exe: 0xC0000005: Access violation reading location 0x001e0e84." 0X001E0E84 is the value contained in lParam and when examined in the memory watch window shows up as ?? ?? ?? ??...
Is there something that I'm doing wrong that my NMHDR is not showing up, or is there some way that I need to check to ensure that it's valid before using it?
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
Yes, with the exact same results. lParam is pointing to invalid memory. An exception is being thrown because my program is not allowed to read that section of memory, not because it's cast to the wrong structure type. Besides that, if there were anything there, then it shouldn't matter what type of structure it's cast to since the first 12 bytes will be the exact same for both structures. If you'll notice, as you read my code snippet above, LPNMHDR is commented out. That's because in the original writing of the program, I did exactly as you pointed out. But when I started getting exceptions, I changed it to LPNMITEMACTIVATE to see if that would make any difference. It didn't, because it's trying to cast an invalid memory location. Now, what I really need to know is
1. Why is lParam pointing to an invalid memory location? Is it something I've done or not done, or is this standard behavior that just isn't documented?
2. If this is standard behavior, is there any way to check lParam to see if it's a valid structure without throwing an exception?
1. lParam is usually zero when you get that error. I'm unaware of any sitation where WM_NOTIFY sends a NULL pointer, but I likely wouldn't have seen such a case even if it was common, because . . .
2. You should always check the wParam for the control ID and filter only for the control you want to watch. There is never a guarantee that some particular control will be the only thing sending WM_NOTIFY messages to your window.
Hope this helps.
Unfortunately, in this case, lParam is not zero, it's some random value. If it were NULL, I could handle that.
The MSDN documentation led me to believe that wParam didn't necessarily point to the control ID, although I'll admit it's a bit confusing.
"Identifier of the common control sending the message. This identifier is not guaranteed to be unique. An application should use the hwndFrom or idFrom member of the NMHDR structure (passed as the lParam parameter) to identify the control."
Thus, I assumed that wParam could not be relied on to contain accurate information. If this is not the case, then I'll gladly check it to see what control is firing before trying to cast the lParam.
It isn't guaranteed to be unique, but it is guaranteed to be the ID of the control that sent the message. You just need to make sure the control IDs are unique or double-check them. I've never seen code that doesn't filter on the wParam, though.
Perhaps it was some rogue control sending random WM_NOTIFY messages to your window.
Business Accounts
Answer for Membership
by: jkrPosted on 2006-08-21 at 11:35:43ID: 17358071
The docs state that "For some notification messages, this parameter points to a larger structure that has the NMHDR structure as its first member.". You can only be be sure that you are receiving an 'LVN_ITEMACTIVATE' afer examining the NMHDR, so I'd recommend to
case WM_NOTIFY:
{
LPNMHDR pnmh = (LPNMHDR)lParam;
switch(pnmh->code)
{
case LVN_ITEMACTIVATE:
{
LPNMITEMACTIVATE lpnia = (LPNMITEMACTIVATE)lParam;
switch(lpnia->hdr.idFrom)
{
case IDC_USED_ADDR:
{
OnUsedAddr(hWnd, lParam);
return FALSE;
}
}
}
}
}