[Drag&drop]Récupérer l'élément déplacé

Bonjour,

J'ai un QListView dont le modèle est un QStandardItemModel.
Malheureusement lors d'un drag&drop, le QStandardItem déplacé est supprimé pour être recrée lors du drop.

J'ai alors besoin de connaître le QStandardItem qui va être supprimé ainsi que celui qui sera créé.

J'ai donc remplacé ma QListView par une classe perso héritant de QListView.
J'ai redéfini QListView::dropEvent ( QDropEvent * e ) et j'arrive à récupérer le nouveau QStandardItem :

Code:

---

1 2 3

QStandardItemModel * modele = (QStandardItemModel *)model(); int ligne = indexAt(e->pos() ).row(); //nouvelle position de l'objet déplacé modele->item(ligne); //nouveau QStandardItem

---

.

Par contre impossible d'obtenir le

Code:

---

QStandardItem

---

qui sera détruit.

Auriez-vous une idée?

L'une des solutions que je vois, ce n'est pas idéal, est de récupérer le dernier item sélectionné soit au travers du signal rowsAboutToBeRemoved de QAbstractItemModel ou en étendant la methode mousePressEvent de QWidget.

Il te suffit de cloner l'objet pour garder les informations dont tu as besoin en mémoire.
Une instance de QStandardItem n'est pas un QObject dont il a l'avantage de pouvoir être cloné (à vérifier tout de meme).

Merci pour ta réponse,

J'ai trouvé une solution hier soir en conservant le dernier QStandardItem sélectionné en utilisant le signal QListView::pressed(QModelIndex).

Mais je me suis aperçut qu'après un drag&drop le modèle a l'ancien QStandardItem et le nouveau QStandardItem donc ça fausse ma récupération du nouveau QStandardItem grâce au indexAt(e->pos() ).

Je pense donc utiliser itemChanged(QStandardItem*) pour récupérer le nouvel itemChanged(QStandardItem*).

Salut,

En fait, le gros problème est peut etre que les QStandardItem sont fortement correlés avec les QModelIndex, dans le sens où il y a une relation étroite entre l'index récupéré et l'objet qui y est associé (voir du coté de itemFromIndex() et de indexFromItem()).

Or, tu n'ignores sans doute pas qu'un QModelIndex n'a une durée de validité que relativement réduite, vu qu'il devient d'office invalide dés que le modèle subit la moindre modification.

Par conséquent, le QStandarItem ne correspond réellement à un index que... tant que le modèle n'a pas été modifié.

Lorsque le modèle se met à jour, il n'a aucune raison de garder un QStandardItem qui n'est associé à aucun QModelIndex (ce qui sera le cas si l'index est supprimé lors du drag), et c'est pour cela que ton QStandardItem est détruit avant d'être recréé (au moment où le modèle se met à jour).

L'idéal est donc peut etre de passer par un QSelectionModel qui aurait comme objectif de garder les informations le temps que tout se remette en place ;)

Citation:

---

Envoyé par koala01

Lorsque le modèle se met à jour, il n'a aucune raison de garder un QStandardItem qui n'est associé à aucun QModelIndex (ce qui sera le cas si l'index est supprimé lors du drag), et c'est pour cela que ton QStandardItem est détruit avant d'être recréé (au moment où le modèle se met à jour).

---

Je comprend la logique mais dans un sens il aurait été mieux d'instaurer un système de mouvement interne atomique (avec un signal OVE(int row, int row) ou équivalent) ce qui simplifierait énormément la programmation et serait 100 fois plus intuitif et nous évitant des jours entiers à être bloqué :aie:.

Citation:

---

Envoyé par koala01

L'idéal est donc peut etre de passer par un QSelectionModel qui aurait comme objectif de garder les informations le temps que tout se remette en place ;)

---

C'est un peu particulier, je n'avais pas besoin des informations contenues mais t'identifier les éléments.
En gros une lecture de playlist aléatoire avec chaque élément ne pouvant passer qu'une seule fois. J'utilise déjà l'AccessibleDescription pour le chemin de la chanson.
Bon, pour le moment j'ai une solution qui marche, je ne la changerais pas mais cela reste très intéressant de voir comment j'aurais pu faire autrement.

Citation:

---

Envoyé par Neckara

Je comprend la logique mais dans un sens il aurait été mieux d'instaurer un système de mouvement interne atomique (avec un signal OVE(int row, int row) ou équivalent) ce qui simplifierait énormément la programmation et serait 100 fois plus intuitif et nous évitant des jours entiers à être bloqué :aie:.

---

Je n'en disconviens pas..

Mais le but de mon intervention était surtout de t'aider à comprendre le pourquoi de ton problème ;)

Citation:

---

C'est un peu particulier, je n'avais pas besoin des informations contenues mais t'identifier les éléments.
En gros une lecture de playlist aléatoire avec chaque élément ne pouvant passer qu'une seule fois. J'utilise déjà l'AccessibleDescription pour le chemin de la chanson.
Bon, pour le moment j'ai une solution qui marche, je ne la changerais pas mais cela reste très intéressant de voir comment j'aurais pu faire autrement.

---

J'avouerai ne pas avoir très longtemps pensé à cela, ce qui fait que, si tu comptes sur moi pour avoir une solution "correcte", tu seras de la revue :aie:

Mais bon, je garde malgré tout la question à l'esprit, on ne sait jamais ;)