Qt::DropActions is a bitmask. The issue I suspect is that instead of: e->dropAction() & model->supportedDropActions()
we should have: e->possibleActions() & model->supportedDropActions() So that any action common to both the source model dragActions() and the destination model dropActions() can be used. Etienne 2017-03-27 19:20 GMT+02:00 Jason H <jh...@gmx.com>: > With the &, it looks like it's using a bitmask. Make sure that the > dropAction() and supportedDropActions() values are arranged correctly, as a > bitmask. > > > 00100 * 00111 = 00100, return true. Therefore the only other thing is it > is a mime issue? > > *Sent:* Monday, March 27, 2017 at 9:28 AM > *From:* "Etienne Sandré-Chardonnal" <etienne.san...@m4x.org> > *To:* "interest@qt-project.org" <Interest@qt-project.org> > *Subject:* [Interest] Model/Views and Drag&Drop actions > Dear all, > > I have two custom models associated with views and I would like to drag > from model A and drop into model B. > > Model B has overloaded supportedDropActions and returns Qt::LinkAction > > Model A has overloaded supportedDragActions and returns Qt::MoveAction | > Qt::LinkAction > > This does not work as the cursor turns to a forbidden sign when dragging > over B. > > If model A supportedDragActions returns Qt::LinkAction only, then this > works. > > > > If I look to the source code of QAbstractItemViewPrivate, i find in > canDecode(QDropEvent * e): > > if (mime->hasFormat(modelTypes.at(i)) > && (e->dropAction() & model->supportedDropActions())) > return true; > > Which explains the issue, the event handler does not check the event's > possible drop actions and does not call setDropAction if the proposed > action is not supported. > > Is this a bug or a feature? >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
