CListCtrl owner draw paint issue

[pd]

I have a class derived from CListCtrl with ownerdraw property set and I am
doing all my painting by myself.

OnPaint that I wrote is called by problem and everything works fine except
that the first item in the list has paint problem.

Sometimes its not highlighted when selected and sometimes it remains
highlighted even though its not selected.
I am erasing the background in my OnPaint itself and looks llike somehow
rect for first item in the list is not invalidated. this is just a refresh
issue as if I scroll and see the list problem just goes away.

Is there anyway to invalidate and forcefully paint the complete area of
listctrl? I am calling following to erase everything but its not doing what
it should.
GetClientRect(&clientRect);

dc.FillRect(&clientRect, &CBrush(RGB(255, 255, 255)));

Thx,
pd

[Ajay]

On May 4, 1:57 pm, "pd" <prash...@mobitor.com> wrote:

> GetClientRect(&clientRect);
>
> dc.FillRect(&clientRect, &CBrush(RGB(255, 255, 255)));
>

Try this instead:

Invalidate();
UpdateWindow();

--
Ajay

[AliR (VC++ MVP)]

With an ownerdraw CListCtrl you would typically override the DrawItem method
to do your own drawing. And not OnPaint.

I would have to see some code to see what you are doing.

AliR.

"pd" <pras...@mobitor.com> wrote in message
news:efgTcGOz...@TK2MSFTNGP06.phx.gbl...

[Ajay]

On May 4, 3:09 pm, "AliR \(VC++ MVP\)" <A...@online.nospam> wrote:
> With an ownerdraw CListCtrl you would typically override the DrawItem method
> to do your own drawing. And not OnPaint.
>

I think that is it unless OP meant something else by owner drawing or
its being in DrawItem anyway. Another option would be to custom draw.

--
Ajay

[pd]

ownerdraw can be implemented using DrawItem or overriding OnPaint to take
care of all the painting by yourself(bit inefficient though).

I have been using OnPaint in my case.

- pd
"AliR (VC++ MVP)" <Al...@online.nospam> wrote in message
news:wbHLl.16034$pr6....@flpi149.ffdc.sbc.com...

[pd]

Ajay,

Invalidate() or updatewindow() would result in another Onpaint invocation
and I can not do it from OnPaint as it will continue forever.

- pd
"Ajay" <ajay...@yahoo.com> wrote in message
news:2fa7a714-dc7f-42f0...@z19g2000vbz.googlegroups.com...

[Ajay]

On May 4, 3:36 pm, "pd" <prash...@mobitor.com> wrote:
> Ajay,
>
> Invalidate() or updatewindow() would result in another Onpaint invocation
> and I can not do it from OnPaint as it will continue forever.

You should not call Invalidate from OnPaint. I didnt realize thats
what I was responding it. Sorry about the confusion.

--
Ajay

[AliR (VC++ MVP)]

OK, but without seeing any code, no one will be able to find the problem.

AliR.

"pd" <pras...@mobitor.com> wrote in message

news:eRjbY9O...@TK2MSFTNGP02.phx.gbl...

[pd]

Workaround of handling keydown and forcefully redrawing first 2 items of the
list worked for me.

void MyListCtrl::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags)

{

if(GetItemCount() >0 )

RedrawItems(0,1);

CListCtrl::OnKeyDown(nChar,nRepCnt,nFlags);

}

let me know if anyone has any other suggestions.

Thx,

pd

"AliR (VC++ MVP)" <Al...@online.nospam> wrote in message

news:FXHLl.16040$pr6....@flpi149.ffdc.sbc.com...

[Joseph M. Newcomer]

There is not nearly enough information here to suggest what is required to solve this
problem. First, you have to indicate how you change the data that is to be displayed.
Then, you have to show the code you are using.

Note also that RGB(255,255,255) makes no sense. If you are painting the background of the
control, you would want to repaint it with ::GetSysColor(COLOR_WINDOW). It just happens
that on your machine, ::GetSysColor(COLOR_WINDOW) is RGB(255, 255, 255) but that is merely
coincidence.
joe

Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[Joseph M. Newcomer]

OnPaint is probably a bad choice.
joe

[Joseph M. Newcomer]

Well, you are fixing a symptom without understanding what is going wrong, so it is not
clear why this is considered a reasonable solution.

I use a lot of owner-draw and custom-draw list controls, and I've never seen this failure,
so it is almost certainly something wrong with your code. But since we see none, there is
no way to determine what is wrong.
joe

[pd]

Joseph,

I appreciate your comments and suggestions and will use
::GetSysColor(COLOR_WINDOW).
The reason I am not posting code here is it involves things those are not
relevant to painting and would be hard to understand and point the problem.

As such I don't see any problem with OnPaint method as it is clear from the
workaround that rect of first item is not geting invalidated and is not
painted.
also the call dc.FillRect(&clientRect, &CBrush(RGB(255, 255, 255))); does
not fills the complete rect specified by clientRect in fact it only fills
the rect of currently deselcted item and selected item.

and in case of first item it does not fill this rect. in addition subsequent
calls to paint the rect of first item when selected/deselected does not have
any effect untill that rect is invalidated either by manual scrolling up and
down using scroll bar etc. or with the workaround I have i.e. redrawing
those items.

This code is on WM6 platform. This certainly is weired but system perhaps is
not calling redrawitems in case of first item in the list.

thx,
- pd

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:qk9vv4tosu7rqmokl...@4ax.com...

[Joseph M. Newcomer]

See below,..

On Tue, 5 May 2009 09:00:04 -0700, "pd" <pras...@mobitor.com> wrote:

>Joseph,
>
>I appreciate your comments and suggestions and will use
>::GetSysColor(COLOR_WINDOW).
>The reason I am not posting code here is it involves things those are not
>relevant to painting and would be hard to understand and point the problem.
>
>As such I don't see any problem with OnPaint method as it is clear from the
>workaround that rect of first item is not geting invalidated and is not
>painted.

****
If it is not getting invalidated, it is important to understand what you are doing that
changes its contents. For example, for owner-draw, it is often the case that an ItemData
(LPARAM) element is modified directly. This requires an explicit invalidation be done. If
you call a function that sets a field of an item, that one field might be all that is
invalidated by the default code. So yes, it matters how you modify the content.
****

>also the call dc.FillRect(&clientRect, &CBrush(RGB(255, 255, 255))); does
>not fills the complete rect specified by clientRect in fact it only fills
>the rect of currently deselcted item and selected item.

****
Because the OnPaint handler works based on the clipping rectangle, it doesn't matter what
you *try* to draw, if what you want to draw is outside the clipping region, it will not be
painted. Doesn't matter if is TextOut or FillRect.
****

>
>and in case of first item it does not fill this rect. in addition subsequent
>calls to paint the rect of first item when selected/deselected does not have
>any effect untill that rect is invalidated either by manual scrolling up and
>down using scroll bar etc. or with the workaround I have i.e. redrawing
>those items.
>
>This code is on WM6 platform. This certainly is weired but system perhaps is
>not calling redrawitems in case of first item in the list.

****
What is WM6?
joe
****

[AliR (VC++ MVP)]

Since WM_PAINT is getting called before my posted message when DDX_Control
is used, I'm going with the flag solution for now.

Unless someone can come up with a better solution.

AliR.

"pd" <pras...@mobitor.com> wrote in message
news:efgTcGOz...@TK2MSFTNGP06.phx.gbl...

[Joseph M. Newcomer]

I just realized that you probably meant to say "Windows Mobile 6". Note that most of the
expertise is this group is desktop Windows. Therefore, it is entirely possible that this
is a failure of the Windows Mobile implementation.

Critical information like this must be part of the *first* post made, not added as a
footnote days later!
joe

[AliR (VC++ MVP)]

Ooops wrong thread.

AliR.

"AliR (VC++ MVP)" <Al...@online.nospam> wrote in message

news:sQ0Ml.15233$jZ1....@flpi144.ffdc.sbc.com...