ListView painting (was Re: Mouse up vs Mouse click)

[Fabian Cenedese]

>>>The misbehaving app uses a ownerdrawn, CListCtrl-derived list. When
>>>I click on a cell not in the first column the cell gets selected. But on
>>>wine I can see that the selection flashes shortly and disappears right
>>>again (Surprisingly it works when I click in the first column. As my
>>>application uses the same code for all columns it must be something
>>>else.). After putting some debug messages in my code I found that
>>>on Windows after the left-button-down event a left-button-click event
>>>is generated, no matter how long I hold the button before releasing.
>>>On wine there is no click event but a mouse up event. And the cell
>>>flashes even when I hold the button, so it's not the releasing itself
>>>that clears the selection.
>
>I tried again to find this problem. I couldn't find any difference in how the
>mouse messages are generated/handled between the two cases (clicking
>on first column/not first column). I now start to think that it's more a focus
>problem. If the focus is immediately shifted away after getting it it might
>look like the flashing cell I have now. To find out more about the focus
>I made some traces with +win.
>
>This is from clicking on the second column (doesn't work). Note
>the additional BeginPaint in the middle and the different
>paint flags:

(snip)

As nobody is participating I need to reply to my own posts :)

I may be getting closer. My assumptions about mouse handling or
focus seem both wrong. The cell gets activated and stays like that,
it's just not visible. But when I move with cursor keys the (invisible)
selection moves from the clicked cell to the next cell (and is now
visible).
So for me it looks like this: When I click in a cell it gets invalidated
and painted selected. But if the cell is not in the first row the first
column (or the whole line) gets invalidated and repainted too, therefore
erasing the already painted selection.


 From my code of the derived list control:

void CMyListCtrl::OnLButtonDown(UINT nFlags, CPoint point) 
{
        LVHITTESTINFO ht;
        ht.pt = point;
        SubItemHitTest(&ht);

        m_CurSubItem = IndexToOrder(ht.iSubItem);

        if(ht.iItem!=-1)
        {
                CHeaderCtrl* pHeader = GetHeaderCtrl();

                //set first selected and focus state
                SetItem(ht.iItem, 0, LVIF_STATE, NULL, 0, LVIS_SELECTED | LVIS_FOCUSED, LVIS_SELECTED | LVIS_FOCUSED, 0);

                //update row anyway for selection bar
                CRect rc;
                GetItemRect(ht.iItem, rc, LVIR_BOUNDS);
                InvalidateRect(rc);
                UpdateWindow();
        } 

        //following line is used for drag&drop support. I don't know why!! Do it at the 
        //end of this function because it hangs until mouse up message has proceed.
        CListCtrl::OnLButtonDown(nFlags, point);
        // test
        AfxMessageBox("Released");
}


The comment in the end is not from me but it really is like that. The call stays
in there until I release the mouse button, no matter if on the same cell or
somewhere else (as it says, for drag'n'drop). The test message box after
the call only comes up when I release the button. But on wine it immediately
pops up while still holding down the mouse button. I don't know how the
hanging is down on Windows but I think this is what mixes up my events
and why my cell doesn't stay painted selected. I'm still wondering though
why this isn't the same on the first column.

Does anybody know about the handling of mouse events in the listview?
Is this a bug or just not implemented yet (I've seen the comment in the
beginning of listview.c :) ?

Thanks

bye  Fabi