@JonB Yes ! and my problem is solved thank you @posktomten

Option 2 suggested above works best I think and is the cleanest solution. To sum it up:

Header file for event definition:

#ifndef EVENTDEFINITIONS_H #define EVENTDEFINITIONS_H #include <QEvent> extern const QEvent::Type TYPE_AUDIO; #endif // EVENTDEFINITIONS_H

Cpp file for the event definitions where it is initialized:

#include <eventdefinitions.h> const QEvent::Type TYPE_AUDIO = static_cast<QEvent::Type>(QEvent::registerEventType());

Event subclass:

#ifndef AUDIOEVENT_H #define AUDIOEVENT_H #include <eventdefinitions.h> #include <QDebug> class AudioEvent : public QEvent { public: explicit AudioEvent(); }; #endif // AUDIOEVENT_H #include "audioevent.h" AudioEvent::AudioEvent() : QEvent(TYPE_AUDIO) { qDebug()<<QString("Creating custom event(%1)").arg(static_cast<int>(type())); }

@Dariusz said in QEventLoop - unique event?:

well I have no idea how to solve it now...

You said this is some kind of cumulative transformation you're doing, right? What about keeping only the info about the transform instead of actually doing it. Then on the update event you can calculate the accumulated result. Say you're moving a thing in space, you can keep the offset from the original position, you don't need to actually do to the move yet, just sum up the vectors. Finally construct the transformation matrix and apply. The same thing could be done for rotations, skews etc.
The only thing that you need to be careful about, however, is that affine transforms aren't commutative. If you have move and then rotate, you can't invert the order to rotate and then move. Either way you can process the similar transformations in batches based on similarity.

PS. I went on a limb here, as I have no clue what you're doing exactly. If you provide more info, we may end up suggesting something better.

You're welcome !

Since you have it working now, please mark the thread as solved using the "Topic Tools" button so other forum users may know a solution has been found :-)

Seems the cache hid the fact that you did everything already !

Even two if you take the QtScxml module.

Well, I am not behind the design of the system so I can just offer some thoughts. I would say that if you need that level of control of the event loop, you might not be using the right tool for your use case.

@BoboFuego said in How to make mouseMoveEvent and keyPressEvent to be called interchangeably?:

I don't know how to mark this thread as solved

"Topic Tools" at the bottom right side and then "Mark as Solved".

Events are not posted to a particular instance of an event loop object. They are posted to a thread. An event loop object does not "own" any events. It's basically a while loop that calls processEvents of a per thread event dispatcher.

That being said if you nest event loops they all process the same pile of events. It's just that only the top one gets to do it while the calling ones wait for it to return.

Unfortunately, it doesn't seems to work... actions() returns me an empty list.

I think I'll go for QTextEdit::createMimeDataFromSelection() because otherwise I won't be able to deal with drag & drop (I didn't think about it :/ )

Thanks anyway!

@etiennedm Why don't you just use layouts?

@AnkurSharma

But, I also expect that when I am resetting the attribute of WA_InputMethodEvent my widget should no more get the input method events anymore, and thats how it works on Qt on OSX.

I don't know how it works on OSX, I can say for sure though that QObject::eventFilter is executed before the QObject::event method (this is documented) and since you're not giving Qt leeway to process the event as it ordinarily would in the overriden QWidget::event method (you stop the event propagation when you return true from the event filter) you shouldn't expect it to respect the widget attribute. That's what I'm claiming. You should move your code from the eventFilter method to a QWidget::inputMethodEvent override.

I figured it out. You can't call the connect statement for the doubleClick signal until the QListView is in scope.

Hi,

You can modify GUI elements from other threads. You should rather use signals and slots to communicate between both. It will handle the communication properly for you.

IIRC Qt 5.5.0 has a bug handling certain key combination which should be fixed for 5.5.1 If you can, try with this one (you may have to built it by hand though)

@SGaist Fixed it ;)

Then you should either check the code where they do that and integrated it to your project or add the image saving feature to GammaRay