It looks like you're new here. If you want to get involved, click one of these buttons!
I am trying to use the following line to generate a mouse event from
my unit tests:
mouse_click = RBA::QMouseEvent.new(
RBA::QEvent::MouseButtonPress, point,
RBA::Qt_MouseButton::LeftButton,
RBA::Qt_MouseButton::LeftButton,
RBA::Qt_KeyboardModifier::NoModifier)
The Qt_MouseButton::LeftButton arguments are accepted as the correct type
for the QMouseEvent.new method, however a runtime error is generated:
TypeError: can't convert RBA::Qt_MouseButton into Integer
Since this is a Ruby method bound to C++ and cares about type, I assume
I have given the method the correct value, yet it complains about the
value at runtime.
I am using Klayout 0.23.9 built with Ruby 1.9.3 and Qt 4.8.5.
What am I doing wrong?
Thanks,
Dave
Comments
Hi Dave,
This code actually works under Windows 7, using KLayout version 0.24-python-eval which uses Ruby 2.1.3 and Qt 4.8.2.
As far as I know, this was changed in the transition from 0.23 to 0.24. The 0.23 version seems to use integers as Qt flags, so for example the following code works in 0.23.10:
In 0.24, this was improved to the following:
Strangely enough, trying to convert your example to 0.23 using integers
...didn't work for me, I got a
RuntimeError: Unexpected object type (expected argument of class QEvent_Type, got Fixnum) in QMouseEvent::new
.Maybe there is a clue in the Qt Binding documentation, but I would recommend upgrading to 0.24 as this is probably going to become standard eventually.
Regards, Chris
Ok, seems like I didn't try hard enough. This hybrid worked under 0.23.10:
Strange. Still, I'd move to 0.24 if possible.
Regards, Chris
Thanks Chris.
This got me out of a quagmire. Your QMouseEvent.new() invocation worked in my installation.
I've taken note of your comments about versions. I can recompile a later version of KLayout,
but moving Ruby and Qt are problems to change in my company environment.
I really appreciate your help.
Dave
Hi Dave, hi Chris,
I am sorry for that confusion. I have mentioned the reason in a different thread: QFlags are classes in 0.24 and no longer mapped to integers. That enables a syntax close to C++ and all the features that QFlags offers, but lacking the backward compatibility. This is because there is either a class or an integer argument. There is no implicit translation of integers to QFlags classes yet.
Seeing the problems this causes, I consider hardcoding a backward-compatible data path.
Thanks for bringing this up.
Matthias