Сам не решал но делал бы так: в деструкторе перекрытого QDrag испустил бы сигнал созданный с QueuedConnection (т.е. через очередь) а в слоте для этого сигнала уже спокойно удалял источник или что надо
Edit: и перекрывать не надо, есть удобный готовый сигнал destroyed
Спасибо, почитал про этот сигнал. Если я верно понял мысль, то мне надо вешаться на QDrag::destroyed, так? Увы, сделать не получится вот почему: обвязка для драга вынесена, как я писал в отдельный класс, который не наследует QObject и не декларирует Q_OBJECT, т.е. про сигналы-слоты он не знает ничего, но зато умеет создавать QDrag, запоминать точку начала перетаскивания и принимать или не принимать dragEnter.
Вот такая декларация:
C++ (Qt)
class DraggableItem
{
QWidget* widgetSelf;
bool draggable;
bool dragging;
QPoint dragPos;
QString mimeType;
QByteArray mimeData;
protected:
QPixmap dragpix;
virtual void SetDragPixmap();
public:
DraggableItem(QWidget* widgetSelf);
virtual ~DraggableItem() {}
void SetDraggable(bool d) { draggable = d; }
bool Draggable() { return draggable; }
bool Dragging() { return dragging; }
QPoint DragPos() { return dragPos; }
void SetMimeData(const std::string& type, const QByteArray& data = QByteArray());
protected /*slots*/:
virtual void mouseMoveEvent(QMouseEvent*);
virtual void mousePressEvent(QMouseEvent*);
virtual void dragEnterEvent(QDragEnterEvent*);
virtual void dragLeaveEvent(QDragLeaveEvent*);
virtual void dropEvent(QDropEvent*);
protected:
virtual void StartDrag();
};
Т.е. имитация методов QWidget'а, реализующие базовую функциональность и перегружаемые в потомках.
На такое извращение пришлось пойти по той причине, что множественное наследование QObject не допускается, а делать линейное наследование просто глупо (например класс
QEditLabel наследует:
QBaseExtLabel(отсюда тянется QObject),
EditableItem, DraggableItem, PairItem<QEditLabel>, в них заключена голая функциональность).
Привеситься на QDrag::destroyed с привязкой его к widgetSelf я не могу за отсутствием общего предка у удаляемых виджетов.
