I have a little problem with ListView control.
Report view.
I create gridlined ListView using LVM_SETEXTENDEDLISTVIEWSTYLE.
If contents of ListView a large and upper part of it hidden (scrolled up)
then when using scroll bar scrolling upwardly some lines of gridlines
is wiped.
It doesn't happend when scrolling downward.
It doesn't happend when scrolling in any direction using arrow keys
(scrolling by moving selection mark)
It happend when and only when upper part of list is hidden and I scroll
DOWN using SCROLLBAR.
Notion:
Wiped gridlines immidietly appears back if either selection mark runs
though wiped gridlines part or even when mouse is over this part.
That's enough for the wiped lines to be repainted.
By why they are not repainted in the first place?
And only when scrolling with scrollbar up?
When down - the are painted allright.
Report view.
I create gridlined ListView using LVM_SETEXTENDEDLISTVIEWSTYLE.
If contents of ListView a large and upper part of it hidden (scrolled up)
then when using scroll bar scrolling upwardly some lines of gridlines
is wiped.
It doesn't happend when scrolling downward.
It doesn't happend when scrolling in any direction using arrow keys
(scrolling by moving selection mark)
It happend when and only when upper part of list is hidden and I scroll
DOWN using SCROLLBAR.
Notion:
Wiped gridlines immidietly appears back if either selection mark runs
though wiped gridlines part or even when mouse is over this part.
That's enough for the wiped lines to be repainted.
By why they are not repainted in the first place?
And only when scrolling with scrollbar up?
When down - the are painted allright.
I'm sure this isn't the best solution but what about doing a InvalidateRect to repaint the gridlines?
And where would I use it?
To be honest your post confuses me a bit.
It doesn't happend when scrolling downward.
.....
It happend when and only when upper part of list is hidden and I scroll
DOWN using SCROLLBAR.
If the problem is only when you scroll down, then I'd put it in whichever the scroll-thingamajig message is that fires when you scroll down. ....or vice versa for scrolling up.
wm_vscroll or whatever
I'm sorry I haven't messed with scrollbars very much.
It doesn't happend when scrolling downward.
.....
It happend when and only when upper part of list is hidden and I scroll
DOWN using SCROLLBAR.
If the problem is only when you scroll down, then I'd put it in whichever the scroll-thingamajig message is that fires when you scroll down. ....or vice versa for scrolling up.
wm_vscroll or whatever
I'm sorry I haven't messed with scrollbars very much.
Didn't help.
Thanx for suggestion.
Anybody else to do my homework? :)
Ketil, your ListView grids are not wipped in the same action
what would you recomend?
I can write some project to visualize the problem.
Thanx for suggestion.
Anybody else to do my homework? :)
Ketil, your ListView grids are not wipped in the same action
what would you recomend?
I can write some project to visualize the problem.
The Svin,
ya lets see an example.
ya lets see an example.
I think he means something like this (I moved the listview a few times so you get 'residu bars' )
The problem is solved.
was it like in my example? If so did you find out what caused it?
A little bit different.
For unknown reason, processing SB_LINELEFT(UP),SB_THUMBPOSITION,SB_THUMBTRACK
ListView proc not always repaint gridlines.
Funny thing that InvalidateRect (and many other
update funcs) doesn't cause repaint either.
So I took 4oh4 (thanx, 4oh4 , you gave me start point)
note of VSCROLL but was forced to make repaint
manually.
Here is solution (if you want I'll sent RadAsm example)
of possible ListView subclassing:
For unknown reason, processing SB_LINELEFT(UP),SB_THUMBPOSITION,SB_THUMBTRACK
ListView proc not always repaint gridlines.
Funny thing that InvalidateRect (and many other
update funcs) doesn't cause repaint either.
So I took 4oh4 (thanx, 4oh4 , you gave me start point)
note of VSCROLL but was forced to make repaint
manually.
Here is solution (if you want I'll sent RadAsm example)
of possible ListView subclassing:
SubListView proc uses ebx hWnd,uMsg,wParam,lParam
LOCAL rc:RECT
mov eax,uMsg
WM_CASE eax,<VSCROLL>
invoke CallWindowProc,RealLVProc,hWnd,uMsg,wParam,lParam
@r: ret
@@VSCROLL:
invoke CallWindowProc,RealLVProc,hWnd,uMsg,wParam,lParam
mov eax,wParam
and eax,0FFFFh
mov ecx,100011010b
bt ecx,eax
jc @r
invoke GetDC,hWnd
mov ebx,eax
invoke SendMessage,hWnd,WM_PAINT,ebx,0
invoke ReleaseDC,hWnd,ebx
jmp @r
SubListView endp
I made some stupid demo from one of project.
Run it, use scroll bar sliding ListView control (put some more files
in project directory so ListView has more rows)
Then comment 1 line that calls SetWindowLong, compile, and see what happens now when using scrollbar.
Run it, use scroll bar sliding ListView control (put some more files
in project directory so ListView has more rows)
Then comment 1 line that calls SetWindowLong, compile, and see what happens now when using scrollbar.
and eax,0FFFFh
No need, but you know this. :)
No need, but you know this. :)
You are right, it's left from previous code. (some experements for
catching calls)
catching calls)
I like how you work with the API
It's quite borring actually :)
Usually C++ programmers did that job with GUI, but none of them
stay now, all gone.
So I forced to do their job.
I change this, too
Ha! :)
You are as all of them ;)
I noteced a long ago in the board that people usually firstly run
your prog and see how it looks and only then (if it looks interesting for them) they look what is your code about. :)
After that I accostomed to add some simple, easy to code effects to bring attention :)
but how would we do period 3
shift and xor.
I leave for you all pleasure to figure out the rest ;)
Here is also needless now
LOCAL rc:RECT
I forgot to remove it after experimenting with InvalidateRect,
wich doesn't work.
And it seems can lead for solution of another problem:
one that captain Nemo posted.
LOCAL rc:RECT
I forgot to remove it after experimenting with InvalidateRect,
wich doesn't work.
And it seems can lead for solution of another problem:
one that captain Nemo posted.
Glad I managed to help you somehow. It's odd that InvalidateRect didn't fix it though. And I'm not sure how good it would be to do an InvalidateRect every time the wm_vscroll message fired, since presumably windows should do that anyways and you'd be using twice the usual resources just repainting your listview. -shrugs-
Ah well, at least you solved the problem. That's the important thing I guess.
Ah well, at least you solved the problem. That's the important thing I guess.
Svin, the other discussion on periodic execution is HERE.