Ranorex Forum

OS: Windows 7 Enterprise, SP1
Ranorex: 5.3.2.23378

We're currently evaluating Ranorex for automating a Qt 4.8.5 application which makes use of both a traditional QWidget hierarchy as well as QML components mixed w/ OpenGL rendering calls inside a QGraphicsView.

This means that we use QGraphicsView::setViewport() to set the viewport to a QGLWidget.

We've noticed that this interferes with registering clicks against widgets inside the graphics view. Without a QGLWidget viewport, Ranorex Recorder successfully registers, eg, clicking a button inside a QGraphicsView. With a QGLWidget viewport, though, the recorder logs any clicks inside the view as hitting the QGLWidget viewport itself rather than any deeper widget inside the view.

This is also apparent when using the "Track..." feature of the recorder. Using a QGLWidget viewport, hovering items in the graphics view fails to highlight the selected item and instead highlights the whole viewport:
I've attached the snapshots for the two versions of the test app in the screenshots demonstrating the issue, though I'm afraid that all the reveal is that the QGLWidget indeed exists in one but not the other.

Is there a known workaround for this problem? Is it possible to prevent the QGLWidget viewport from "blocking"/intercepting clicks against widgets deeper in the view?

Thanks much!

Hi,

What happens, if you set the xpath manually, instead of tracking the element or using the Record button? For example, the path to the button in question could look like this:
/form[@title='AccessibilityTestQt4_GL']/picture/button[@text='Some Button']
Does Ranorex hits the button during runtime?

Another solution could be something like described in this post:
http://www.ranorex.com/forum/plugin-how ... t7881.html
It appears to be like something undocumented/not publicly available, but maybe it could help also in your case? I'm sure Ranorex support folks with provide you with more suggestions.

Thanks for the suggestion; very helpful!

Setting the xpath manually to the correct repo item (and adjusting the relative click location) indeed allows the test to operate correctly. The click hits as desired even if the button's position is shifted in a modified version of the app. So that's a useful workaround for the recorded clicks being registered incorrectly at first.

I'll try to give the ignore-an-element workaround a test then and report back if I have any luck.