CListCtrl Notification Behavior

Hi,

Please bear with me as I describe this problem. I have already scoured the forum for an already existing answer to this but have found nothing that has provided a solution.

I have a CListCtrl object that has several operation entries. Some of these, when selected, bring up a dialog box for the user to set properties for the selected operation. When the box comes up, the user may decide to click Cancel and not set any properties at which point I deselect the item in the operations list.

The problem I'm having is that when I deselect the item, it seems an extra notification is being sent and the flags show that the item IS selected when it should not be and so this is causing my logic to redisplay the dialog thinking the item is selected.

Here's some code. First is where I'm handling the changes:

Code:

---

void CRovRebuildView::OnItemchangedListOperations(NMHDR* pNMHDR, LRESULT* pResult)
{
        NM_LISTVIEW* pNMListView = (NM_LISTVIEW*)pNMHDR;

        CheckList(pNMHDR, pResult);

        *pResult = 0;
}

---

in CheckList, everything works fine until I call

Code:

---

NM_LISTVIEW* pNMListView = (NM_LISTVIEW*)pNMHDR;

UINT uNewState = pNMListView->uNewState;
UINT uOldState = pNMListView->uOldState;
int iIndex = pNMListView->iItem;
...
m_listOperations.SetItemState(iIndex, 0, LVIS_SELECTED);

---

which causes the notification to call OnItemchangedListOperations again with the flags that show the item is selected. Even GetFirstSelectedItemPosition() shows the item is still selected. But once it goes through the 2nd iteration, then the flags are set correctly.

Either I'm missing something or there doesn't seem to be a way check precisely what's checked and what isn't.

Can anyone shed some light on the subject please? Please let me know if you need more info on this from me.

When you call SetItemState(iIndex, 0, LVIS_SELECTED) that will remove LVIS_SELECTED for the row iIndex. What's the condition before making that call?

If you wonder about the LVN_ITEMCHANGED notification, this is what you should expect when items change selection in the CListCtrl.
First there will be LVN_ITEMCHANGED messages telling of the item(s) deselected. For each item deselected one of those messages is sent telling of an uOldState = LVIS_SELECTED and a uNewState = 0. There will also be a LVN_ITEMCHANGED message for the item that had focus where uOldState = LVIS_FOCUSED and uNewState = 0.
To finish the bombardment of notifications one will be seen for what gets selected. uOldState = 0 and uNewState = LVIS_SELECTED.

Anytime you want to test if the item is checked test the uNewState. It'll be 0 if it isn't and LVIS_SELECTED if it is. And you'll see the uNewState == 0 twice if the item had focus.

Jay

Hello Jay,

Thanks for the input on this. It's been a pain for me. I actually do see what you're talking about, however, there seems to be an additional notification and that's the one that screws everything up.

For example, when I select one item initially in the list
new = 3, old = 0, item state = 3

when I deselect it, two notification are sent
new = 0, old = 3, item state = 0
new = 3, old = 0, item state = 3 <- why is this being sent?

So the second one screws things up and doesn't make any sense to me as it looks exactly like the status of the initial selected item (but only when I select one item). I get the item state like this:

Code:

---

GetItemState(iIndex, LVIS_SELECTED | LVIS_FOCUSED);

---

The condition before making the call is the 3,0,3. If I use multiple selections the flags are a bit different due to focus moving and so on, but it's something like this for the operation with the dialog when I select it:
0,1,2
2,0,2

then when I hit Cancel and call the deselect macro:
0,2,0
1,0,1

Basically what I need is:
- user selects operation
- operation pops up a dialog
- user hits cancel on dialog
- deselect operation

Sounds simple doesn't it. ;)

I know this post is old, but I just came across the exact same problem.

The only solution I can find is to use SetTimer() to delay the deselection of list items until the LVN_ITEMCHANGED handler has completed.

I hate this workaround because it is soo ugly!

Cheers / Z