PDA

View Full Version : Drop indicator not displaying with QTreeView. Need help



bigchiller
4th March 2008, 19:31
Hello,

We have a QTreeView using QT 4.1.3 where we support drag & drop from within the view and have implemented dropEvent(), dragMoveEvent(), dragLeaveEvent() and dragEnterEvent().

In our constructor we are making a call to
setDropIndicatorShown(true);

I am unable to get the drop indicator to display. I've noticed that the document http://doc.trolltech.com/4.1/model-view-dnd.html states that removeRows() must be implemented in our model for the QT::MoveAction to work correctly. We currently do not have an implementation for this function, but our MoveAction works very well. Is this function required for the drop indicator to display?

Any help would be greatly appreciated,

Brad

wysota
4th March 2008, 21:01
I suggest you try a more recent version of Qt. As far as I remember this functionality might have been broken in the version you are using.

bigchiller
4th March 2008, 21:19
I suggest you try a more recent version of Qt. As far as I remember this functionality might have been broken in the version you are using.


Our most recent build uses QT 4.3.3 and it fails there too. Is there a check list of things that i must have in order to support drop indicators? Is there anyway I can manually render drop indicator lines with the QPaint engine or something similar?

jpn
4th March 2008, 21:42
What is the reason for re-implementing all those event handlers? I guess they are the ones who take care of things like drop indicator position...

bigchiller
4th March 2008, 21:45
What is the reason for re-implementing all those event handlers? I guess they are the ones who take care of things like drop indicator position...

Not sure. I'm trying to maintain code that was written by someone else. Perhaps removing these event handlers is the solution?

wysota
4th March 2008, 22:59
I'd suggest starting by calling the base class implementation. But in general when using item views you should handle drops within the model and not the view. Search the forum for details.

bigchiller
4th March 2008, 23:37
I'd suggest starting by calling the base class implementation. But in general when using item views you should handle drops within the model and not the view. Search the forum for details.

I should handle drops within the model? What about dragEnterEvent and dragMoveEvent

wysota
5th March 2008, 00:03
What about dragEnterEvent and dragMoveEvent

You can reimplement them, but the default implementation is fine in most cases (and it's responsible for showing the drop indicator). The only reason for reimplementing them I know is when you want to decide if a drop on a particular item should be accepted depending on the contents of a particular drag.

bigchiller
5th March 2008, 16:28
You can reimplement them, but the default implementation is fine in most cases (and it's responsible for showing the drop indicator). The only reason for reimplementing them I know is when you want to decide if a drop on a particular item should be accepted depending on the contents of a particular drag.

Currently our dragMoveEvent is making the decision whether to use a Qt:CopyEvent or a Qt:MoveEvent. We support either internal moves or dragging external files and copying them into the tree view. Is there a preferred location to place this logic?

wysota
5th March 2008, 16:42
The action to be performed could be decided within QAbstractItemModel::dropMimeData(). Of course you can do that in the dropMoveEvent() method, but remember to call the base class implementation.

bigchiller
5th March 2008, 17:09
The action to be performed could be decided within QAbstractItemModel::dropMimeData(). Of course you can do that in the dropMoveEvent() method, but remember to call the base class implementation.

dropMoveEvent? Do you mean dragMoveEvent? How would I go about calling the base class implementation if i override dragMoveEvent?

jpn
5th March 2008, 17:17
void SubClass::someMethod()
{
BaseClass::someMethod(); // <---
// do something in addition to what base class does
...
}

akiross
12th March 2008, 12:38
The action to be performed could be decided within QAbstractItemModel::dropMimeData(). Of course you can do that in the dropMoveEvent() method, but remember to call the base class implementation.

My model (subclass of abstract table model) should accept copy actions when dragging from another widget, while accepting move actions when dragging within the widget.

If the action to perform can be decided within QAbstractItemModel::dropMimeData(), how can I operate on the source model when moving?
In other word: if I choose to copy or move within dropMimeData, shoudn't I have access to a QModelIndex for the source data?
I'm wondering:
dropMimeData knows which action should be performed, but returns a bool. So, another object should get this return value and - i guess - this object should check if the move action returned a true and, if it is true, the source object should then ask to source model to remove the data.
How can this be done within dropMimeData?

(Actually I'm really noob with drag and drops, still learning what's behind the curtains :)

Shouldn't this decision be taken by the view? (e.g. in the startDrag() ?)

Thanks