I am using a QAbstractScrollArea + a custom QWidget derivative widget as "the" widget
(having sizeHint() overriden).
The application needs to constantly update the QWidget content during mouseMove (kind of
a drag, but not exactly, it is a drawing tool to draw lines between objects, thus the mouse
cursor needs to change + the line needs to be drawn on the fly).
The application works fine, e.g. I can render the content properly, scrollbars visible,
I can manual update the viewport during scrollContentsBy, etc.
However regardless that I manually fire a update() (or repaint()) call in mouseMoveEvent,
the paintEvent will only be called after the "drag" process is over, e.g. the mouseReleaseEvent is fired.
And I'm clueless why this happens. Obviously if I do the update directly within the
mouseMoveEvent, it'll be rejected by QPainter (as I can't instantiate a QPainter within
the mouseMoveEvent - Qt drops "paintEngine should no longer be called" when trying to do that).
Any suggestion is welcomed :)
Thanks,
Meh, lame me. Never never mix "update()" with "viewport()->update()"
Related
I have a Qt application with objects derived from QGraphicsObjcet that need to be movable in a scene. I know that I can use the flags for movement to achieve this.
myObject->setFlag(QGraphicsItem::ItemIsMovable);
myObject->setFlag(QGraphicsItem::ItemIsSelectable);
myObject->setFlag(QGraphicsItem::ItemSendsGeometryChanges);
but I am having an issue with the objects popping out of position when i use it. The only time when the objects move into an incorrect position is when an object I've moved is deleted and removed from the scene, the next time I try to move another object in the scene, its position relative to mouse Cursor is distorted until I release it and press it again. I realise that my problem could be occuring somewhere completely elsewhere in my code but from my own debugging I would at least want to try and implement the move functionality myself to solve this issue.
So my question is: How can you implement movable objects (derived from QGraphicsObject) that act as if the flags above are active?
I've been trying to use mouseMoveEvent but can't figure out how I get the objects to move with the cursor. Maybe I should look into DragMoveEvent instead? If possible, I would however really appreciate to see what the code for mouseMoveEvent below would look:
void myObject::mouseMoveEvent(QGraphicsSceneMouseEvent *event)
{
// How do I get myObject to follow
// the event pos in the scene from here?
QGraphicsObject::mouseMoveEvent(event);
update();
}
I think something like this should do the trick (not tested):
void myObject::mouseMoveEvent(QGraphicsSceneMouseEvent *event)
{
// Set the item position as the mouse position.
this->setPos(event->scenePos());
// If your object (this) has no parent, then setPos() place it using scene coordinates, which is what you need here.
QGraphicsObject::mouseMoveEvent(event);
update();
}
With the code above, your object is going to follow the mouse untill the end of the world, so you probably want to combine it with a start/stop flag.
And if your item has a parent, you are probably going to need to translate the coordinates.
I have a area shows waveform of a wave file.
I want that a line follow mouse moving like audio editor and this line's behavior is like progressbar when it is playing.
But there's only one paintEvent function, it works well when it is not playing, how to implement it?
Remember that the paintEvent isn't meant to react to user interaction directly. You should handle interaction in relevant mouse/keyboard event handlers, and modify a data structure that describes what's to be shown. Before returning from the event handler, queue an update using QWidget::update().
The paintEvent will be then called from the event loop, and should repaint the widget based on the updated data. Also don't forget that the paintEvent can be called at any time, and that you can paint on the widget only from within the paintEvent.
I am learning Qt and am trying to paint a simple display for my program with QPainter.
I draw static elements (frames etc.) once and only update dynamic elements afterwards.
Everything works fine, except for when the window loses focus. As soon as that happens, the whole area is cleared (dynamic elements keeps being painted as before).
Is it possible to prevent this behaviour? If not, how do I determine if the window have lost focus?
When your widget is uncovered, the paintEvent member will be called. The event passed in has a region() member that tells you what part of the widget should be redrawn. You can use that to redraw the static parts if/when necessary.
While I did not find why the screen was repainted, the focus can be triggered by using
eventFilter(QObject *, QEvent *event) {
if (event->type() == QEvent::ActivationChange){}
}
and paint function can be called from here. Although a slight delay must be added, as the trigger usually fires before the window looses focus (hence still clearing the repaint).
I'm overloading the paint() function in QAbstractItemDelegate (my own Item delegate class).
When dragging, it paints the contents of the entire cell, which I don't want. I'm assuming that the paint() function is called with something specific while dragging, but I don't seem to find it.
The closest I've been able to find is a QState variable in the owning view class (access function QTableView::state() is protected.) By creating a function on my QTableView-derived class called 'isDragging()' which calls that function and returns whether dragging or no, I can determine within my delegate class whether I'm dragging or not, and can modify the paint() function.
This almost works.
The problem is that it shows the modified paint image in the original cell, which I don't want - I want to leave the image in the original cell untouched.
Have to scour the examples, I guess, and see if there's something that does this...
I have crawled through the Qt source and I can see where it sets the drag pixmap by calling the QItemDelegate::paint() function, but the only thing it changes is it forces QStyle::State_Selected in the item option style. That's not enough, since the item is selected, already.
Any way to know how to draw a cell's contents explicitly when dragging?
Ok, the ultimate answer on this was to, yes, set the flag on 'startDrag', but rather than leaving it around and unsetting it on mouse release button event, simply call the base method and then unset.
The reason is that the image for the cursor is only requested (and painted) once - not continuously during the drag, as I had first thought. Leaving the flag set meant the cursor image would get drawn at inappropriate times.
So, the implementation looks like:
MyClass::dragStart(Qt::DropActions supportedActions)
{
__dragStart = true;
TableView::dragStart(supportedActions);
// request for drag cursor image happens here
__dragStart = false;
}
Why don't you do that yourself? Set a flag when dragging starts and remember the active ModelIndex, do some special painting when the flag is set, and clear the flag when dragging is finished. You can do this by overriding QAbstractItemView::startDrag.
I have a problem:
I'm creating a widget which displays current date's day number. It's like a button, but it's not derived from QPushButton class. Just from QWidget. So I've reimplemented enterEvent(), leaveEvent(), mousePressEvent(), mouseReleaseEvent(). I do call update() inside these methods and widget has realistic button behavior (paintEvent() is reimplemented also).
But when I change system date and hover that widget with other window, my widget doesn't get paintEvent() and the old date is displayed. Only when I place mouse over it, widget repaints it's contents.
I guess there is a feature (like buffering) which paints old contents on hovering with other window to avoid unnecessary recalculations. But I need to disable it. Tried to set many attributes (the Qt::WidgetAttribute enum). But it doesn't work.
I think you should find a way to detect that the system time has changed and call update() when that happens. Any other method (like detecting the "hovering" of a window or waiting for a mouse event) will cause the update to occur too late.