I'm writing a program that uses the Qt Graphics View framework. I have subclassed QGraphicsItem to a class that includes other QGraphicsItem (or other subclasses of it). This class is the parent of the included QGraphicsItem; the idea is to work with composite objects.
From the docs it seems to be a conflict in what I try to achieve:
Calling ignore() in mousePressEvent will make my object unmovable. I want to move it.
Calling accept() in mousePressEvent will prevent the event from being propagated to the child object. Some of the child objects should react to mouse events.
How can I make this work?
I think your interpretation of the documentation is incorrect.
Calling ignore() in mousePressEvent will make my object unmovable.
I don't believe that is true. To me it looks like calling ignore() is like the object saying "I have assessed this event. I have taken all actions I want to in response to this event. I have also decided it was not intended for me, so I will now pass it on to the next object underneath me". I can't find anything which suggests the ignore event will unset the QGraphicsItem::ItemIsMovable flag (which is what decides if the QGraphicsItem is movable or not).
I don't see why you couldn't make your object move and ignore() the event, but I would advise that this is not a sensible approach (in most instances: obviously you may have cause for it).
Calling accept() in mousePressEvent will prevent the event from being propagated to the child object.
I believe this is true, but the parent can still modify its children. My understanding is calling accept() is like the object saying "I have assessed this event. I have taken all actions I want to in response to this event (which may include modifying my children). I have also decided that the event was intended for me, so I will not be passing the event on".
In your parent QGraphicsItem, you might try to
MyObject::mousePressEvent ( QGraphicsSceneMouseEvent * event )
{
QGraphicsItem::mousePressEvent(event);
event->ignore();
}
This would allow normal processing of the mouse event (i.e. make your object moveable), but then ignoring it so that it is propagated.
The logic would need to be more robust, though, because there is a high risk of side effects if a parent and child respond to the same mouse event.
Send QCoreApplication::postEvent(child, mouseEvent) to child objects.
Related
What's the difference between setting ContextMenuPolicy to DefaultContextMenu or CustomContextMenu? From what I can tell, they're the same things? Either way, you get to create a custom context menu if needed.
They are certainly not the same.
While they both could create a custom menu, their behavior is quite different. Consider the QWidget documentation:
The default value of this property is Qt::DefaultContextMenu, which means the contextMenuEvent() handler is called.
This means that you need to specifically override contextMenuEvent() in order to eventually show the context menu. This usually means that subclassing is required and only the widget will handle that event (which could also be ignored) and possibly its menu.
Note that overriding contextMenuEvent() could be done also for special cases of the event management, from the simplest one (accepting it, to avoid propagation to the parent) to more complex situations that need to set up some aspects before letting the default implementation to handle the event as usual.
With Qt::CustomContextMenu, the signal customContextMenuRequested() is emitted.
This means that any object can connect to that signal (and potentially more than once), even a completely unrelated one, and eventually do something from there. This also means that there is absolutely no access to the event, which will always be considered as accepted.
I have a suspicion that something is preventing my mouse event to be called in Qt. Therefore, I think it might help to add the event to a thread. Is there any way to do that? And if so how would the syntax look?
Qt standard mouse events come to QWidget objects. Those must exist in the main thread, always.
So no, you can't receive the normal mouse events in other threads.
However, you should perhaps install an event filter to your main window or to your qApp object, so you will see all the events. Look in the docs for how to use the event filter, but in short, you need to subclass QObject to override the eventFilter method, and then create instance of this class, and install that as event filter for another object.
I'm starting to give up on the Flex forums so I'l re-post here and see how things go. Long time lurker, first time poster ;-)
I'm trapping keyboard events on the stage and dispatching custom events through a framework (Mate, though I don't know that this is an important issue), but I'm pretty confused by the scope. The structure is:
--application (traps keyboard events and dispatches custom event
-- mainPanel (receives dispatched events but mainCalendar (a child element)
is null on debugging. Obviously if I try to call a public method on
mainCalendar it errors out, even though it's a child of mainPanel.
However, mainCalendar is NOT null IF I use
FlexGlobals.topLevelApplication.mainPanel.mainCalendar.
Outerdocument and parentDocument do not expose mainCalendar either, BTW
-- mainCalendar (a custom component inside mainPanel with public methods.
Creation policy is 'all' and it's visible and exists long before I
trap any keystrokes at the top level)
Could someone take a minute and explain why the mainCalendar is out of scope when mainPanel receives a custom event, even though mainCalendar is a child of mainPanel. Is there a better way to manage the events so I don't have to always address the component via the topLevelApplication?
Thanks
(creating answer so this question could be marked as answered)
Usually, when reference to component is null and it should not, this means component isn't created yet. This might have place before application initialize event or if component's parent isn't visible and not validated.
I need help to understand to use QEvents in QT, this is driving me crazy.
I am writting an application using custom events, but as in QApplication::postEvent function, it's necesary to specify the target object.
As I understand, it's possible to post events to Qt's event loop with
QApplication::postEvent(obj_target, QEvent myevent);
This means that I'm trying to catch "myevent" event in obj_target an do some stuff.
But I need to post events without specify a target object, as QMouseEvent or QKeyEvent do
I mean, when clicking in a QMainWindow with a lot of buttons, how is that I can click
any button and that button is pressed?
What is the target object when the click event is posted?
It's possible to register objects to "listen" for a specific event?
I'm really confused, it's possible to post an event without specifying a target object?
Thank you very much in advance
There is no trivial way to post events "globally", as Dan has said. All of the event dispatching of native events is done by private Qt implementation code.
The important distinction is:
There are native messages/events, delivered by the operating system, usually received by a window-specific event loop.
There are QEvents.
Internally, Qt keeps track of the top-level Widgets (windows, really), so when it receives an event from the OS, it knows which window it should go to - it can match it using the platform window id, for example.
QEvent delivery makes no sense without a receiving object, since sending an event to an object really only means that QObject::event(QEvent*) method is called on that object. It's impossible to call this method without having an object instance!
If you want to synthesize a global key press or mouse click event, then you have to figure out what object the event goes to. Namely:
Identify what top-level window (widget) the event should go to. You can enumerate top level widgets via qApp->topLevelWidgets().
Identify the child widget the event should go to. If it's a keyboard event, then sending the event to currently focused widget via qApp->focusWidget() is sufficient. You need to enumerate the child widgets to find the deepest one in the tree that overlaps the mouse coordinates.
Send the correct QEvent subclass to the widget you've just identified. Events delivered to top-level widgets will be routed to the correct child widget.
When sending mouse events, you also need to synthesize relevant enter and leave events, or you risk leaving the widgets in an invalid state. The application.cpp source file should give you some ideas there.
This doesn't give you access to native graphical items, such as menus on OS X.
Please tell us exactly what you're trying to do. Why do you want to post a broadcast event? Who receives it? Since your own QObject-derived classes will receive those broadcasts, I presume, it's easy enough to use signal-slot mechanism. You'd simply connect(...) those receiver classes to some global broadcaster QObject's signal(s).
For this purpose, I have a specific singleton class which I call GuiSignalHub. It regroups all the application-wide signals.
Objects that want to trigger an application-level action (such as opening context help) just connect their signal to the GuiSignalHub signal. Receivers just connect the GuiSignalHub to their slot.
I'm still working on my zoomable node-graph project. I'm currently having problems with what I know must be relatively easy, but have been unable to find a solution to:
I have numerous objects, many of them are stored within other objects (and overlap in physical space). As I zoom into an object, it begins to fade away. At the moment it begins to fade, I load in the child object (or create a child object if one doesn't exist). I want to turn off the parent object's ability to respond to most events. The exception is the scroll wheel, which needs to be sent to both objects simultaneously so that the parent can continue to fade out as I zoom farther in. Try as I might, I can't find a way to tell Flex "hey, for right now dispatch these types of events ONLY to this object." I either end up with event dispatch stack overflows from trying to manually redirect the events, or I get events that don't activate at the correct time or on the correct object. What can I do?
I want to turn off the parent object's
ability to respond to most events.
You can't turn off an objects ability to respond to events.
You can write code to remove all event listeners inside that object; although I suspect this will be a manual process.
You can remove that object from the display list so its event listeners won't trigger on events in their capture or bubbling phases. If this object has children that you want to display this won't work.
You may be able to work something out where the 'child' object calls stopPropogation() and/or stopImmediatePropogation() in it's own event listeners. I believe this could prevent the handlers from firing in the parent, but it may depend how your listeners are set up. I do not believe this will have an effect if you are listening in the capture phrase.
You may be able to write "aware" event handlers that basically say:
if(SomeConditionTrue){ return; }
I'm running out if ideas. But, I'm pretty sure there is no way to universally say "Don't let this component respond to events"