Registering clicks using QGLWidget viewport

Technology specific object identification, supported applications, web technologies, and 3rd party controls.
Posts: 2
Joined: Tue May 05, 2015 5:31 pm

Registering clicks using QGLWidget viewport

Post by humberb » Wed May 06, 2015 4:03 pm

OS: Windows 7 Enterprise, SP1

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!
You do not have the required permissions to view the files attached to this post.

User avatar
Ranorex Guru
Ranorex Guru
Posts: 7469
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: Registering clicks using QGLWidget viewport

Post by odklizec » Thu May 07, 2015 7:29 am


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: ... 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.
Pavel Kudrys
Ranorex explorer at Descartes Systems

Please add these details to your questions:
  • Ranorex Snapshot. Learn how to create one >here<
  • Ranorex xPath of problematic element(s)
  • Ranorex version
  • OS version
  • HW configuration

Posts: 2
Joined: Tue May 05, 2015 5:31 pm

Re: Registering clicks using QGLWidget viewport

Post by humberb » Thu May 07, 2015 10:05 pm

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.