Drop indicator not displaying with QTreeView. Need help

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

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.

Quote:

---

Originally Posted by wysota

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?

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...

Quote:

---

Originally Posted by jpn

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?

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.

Quote:

---

Originally Posted by wysota

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

Quote:

---

Originally Posted by bigchiller

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.

Quote:

---

Originally Posted by wysota

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?

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.

Quote:

---

Originally Posted by wysota

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?

Code:

---

void SubClass::someMethod()
{
    BaseClass::someMethod(); // <---
    // do something in addition to what base class does
    ...
}

---

Quote:

---

Originally Posted by wysota

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