Hi,

I am working on providing viewportEvent of QAbstractScrollArea:

Here is a first attempt.
http://users.pandora.be/Jan.Van.hijfte/qtforfpc/qt4pas-V1.52_Qt4.3.1.tar.gz http://users.pandora.be/Jan.Van.hijfte/qtforfpc/win_qt4pas-V1.52_Qt4.3.1.zip

1) use override_viewportEvent to install own viewportEvent
2) in your own Pascal viewportEvent you can call InheritedViewportEvent

    to call QAbstractScrollArea::viewportEvent(event);

3) QLCLAbstractScrollArea::viewportEvent does not call QAbstractScrollArea::viewportEvent unless no pascal procedure is stored to call.

Is this what you wanted ? If not, tell me what to change. When everything is coordinated I will release a final V1.52 for all platforms.

Please look at the code of QAbstractScrollArea::viewportEvent when provide an implementation of viewportEvent.
src/gui/widgets/qabstractscrollarea.cpp

I do not think this was necessary. It could have been done with an eventfilter. But as you asked for it twice :-). The disadvantage of this is that you cannot use it on descendants of QAbstractscrollarea. With an eventfilter you can

BTW, congratulations on the progress of the Qt Lazarus. Really amazing.

kind regards,

Den Jean

I do not think this was necessary. It could have been done with an eventfilter. But as you asked for it twice :-). The disadvantage of this is that you cannot use it on descendants of QAbstractscrollarea. With an eventfilter you can

I don't think that's not necessary anymore , but let's wait paul's opinion.

tnx.
zeljko

We are still painting on QAbstractScrollArea window instead of viewport window and this is bad. I dont know how to paint on viewport window without hack So I think this will be useful.

Best regards,
Paul Ishenin.

????? ?????? wrote

We are still painting on QAbstractScrollArea window instead of viewport window and this is bad. I dont know how to paint on viewport window without hack So I think this will be useful.

could you please elaborate. What can I provide to remove the hack. Do you need a protected handle ?

Yes Den, this is I wanted.

Best regards,
Paul Ishenin.

What is a viewport? I did a quick search on docs, and see the term is used, but I don't see any explanation.

thanks,

I still think it is better to use eventfilter to be able to use descendants aswell. But I released V1.52 with this request anyhow. http://users.pandora.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html

I do not really understand your problem. When I look at the cpp code of abstractscrollarea.cpp I just see an eventfilter aswell: ... viewport->installEventFilter(viewportFilter); But I am not sure and have no time to dig deep into LCL.

I will not mind at all to change everything if you think of something better. You are doing an amazing job with Lazarus-LCL-Qt.

regards,

Den Jean

Den Jean wrote

I still think it is better to use eventfilter to be able to use descendants aswell. But I released V1.52 with this request anyhow. http://users.pandora.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html

Ok, how I should install eventFilter to viewPort? Yes, viewport can be any widget and I can try to do the same as this method do:

procedure TQtObject.AttachEvents;
var
   Method: TMethod;
begin
   FEventHook := QObject_hook_create(TheObject);
   TEventFilterMethod(Method) := @EventFilter;
   QObject_hook_hook_events(FEventHook, Method);
end;

But look at QAbstractScrollArea::setViewport

         d->viewport->installEventFilter(d->viewportFilter);

So after setViewPort call my eventFilter will be overriden by own qt eventFilter. So how should I install eventFilter to viewport?

The only way is (hack):
1. call setViewPort
2. install eventFilter after that

Is it right? I think no, since this way is not prefered by qt. They defined some rules:
"When inheriting QAbstractScrollArea, you need to do the following: ...
* Handle events received by the viewport in viewportEvent() - notably resize events."

Lest play by their rules, or if we do hacks then we might have troubles with next version of qt.

If I am wrong in understanding qt or bindings please correct me. I dont know maybe way wich I see as hack is legal way.

Best regards,
Paul Ishenin.

tnx, that's we need, I've measured painting speed yesterday (just visually), but I can say that painting on viewport instead of all abstractscrollarea is at least 50% faster (you can see that if u compile widgetset with -dQtPaintOnViewport, and then use TStringGrid with 1000...2000 rows with some text inside), and it fixes some scrolling issues which we have at the moment with all TCustomControls descendants.

zeljko

Felipe Monteiro de Carvalho wrote

What is a viewport? I did a quick search on docs, and see the term is used, but I don't see any explanation.

it's a qwidget inside qabstractscrollarea which is being painted (used) and represented (eg. TStringGrid, TTreeView are painted on viewport, not on scrollarea - which is we can say container).

Paul Ishenin wrote

.. ? ? ?* Handle events received by the viewport in viewportEvent() - notably resize events."

AFAIK that's all we need. Hacks are not welcome.

I am confused :( I used Den's 1.52 binding and thinked that I will get QEven::Paint in viewportEvent(), but no - I only have some strange event type = 39013 (something from user events) in this viewportEvent() handler. Very strange - I have QEvent::Paint in usual eventFilter of viewport widget. How I tested this before?

Sorry Den, seems you've done that work for nothing.

Best regards,
Paul Ishenin.

NOT ! I've just fixed all problems with viewport ! ;) LCLAbstractScrollArea is thing we need ! :)))

zeljko