OnVScroll processing problem

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

OnVScroll processing problem

Jochen Riekhof-6
Hi...

got a small problem with scrolling and view updating. I have overridden
ListView>>onVScroll:, send super onVScroll: first and and then trigger
my own event for updating of the enclosing view. This view computes the
positions of the table rows to paint accordingly.

My problem is now that the painting is always one scroll event late.

This is apparently because when I trigger my event in my onVScroll: the
window processing of the actual scroll event is not yet completed. As a
workaround I now save the event in an instance var and override
ListView>>dispatchMessage:wParam:lParam:. Here I send the super message
first which completes all the required windows processing, then look if
there is a saved event and trigger my own one from here.

Everything works now, but quite often I experience "freezing" scrollbars
now.

Is there a better way to delay processing until after an event
completed? Forking a process is too slow, and postToInputQueue is not
working as there is no idle until after the user relased the scrollbar.

Any ideas?

Ciao

...Jochen


Reply | Threaded
Open this post in threaded view
|

Re: OnVScroll processing problem

Jochen Riekhof-6
Hi...

unfortunately I could reproduce the problem also without the described
scenario. No clue currently. Sometimes the entire scrollbar just ceases
to respond to any mouse click and also hovering hilights do not appear.
After making it repaint somehow (e.g. by switching to another dolphin
window and back) maks it work again.

???

Ciao

...Jochen

P.S. positive is that the trick with the event processing works fine :-)


Reply | Threaded
Open this post in threaded view
|

Re: OnVScroll processing problem

Steve Alan Waring
In reply to this post by Jochen Riekhof-6
Hi Jochen,

I have never done this myself so I am just speculating ... have you
seen MultilineTextEditWithImage>>onHScroll: and #onVScroll:? They do
default windows processing, then ask for a repaint, then answer to 0 to
suppress doing default windows processing again. From your description,
I think this is different to what you have tried because it forces the
send of #defaultWindowProcessing: (which a super send will not do).

Worth a try, but I would save my image before testing it.

Steve


Reply | Threaded
Open this post in threaded view
|

Re: OnVScroll processing problem

Jochen Riekhof-8
Hi Steve,

thank you for the hint! It solves exatly the same problem that I have,
but is cleaner to implement so I now use the one from
MultilineTextEditWithImage.

As for the hangs in scrolling, I now always issue an invalidate on the
view after zOrderTop, I /seems/ that this helps but I did not test it
for a longer time yet.

Ciao

...Jochen