Mudlet: le déplacement de scripts et de dossiers en supprime d'autres

Oui, grand. Cela se produit-il également avec de vrais objets, ou simplement avec les «nouveaux déclencheurs» vierges?

En effet, c'est le cas. C'est comme ça que je l'ai remarqué .. 😢

Ceci est juste un petit exemple concis pour votre comparaison.

J'ai également noté d'autres manigances dans certains cas, seuls certains (mais pas tous) des éléments déplacés réapparaissent après la fermeture et l'ouverture du profil. Alors que la réouverture de l'éditeur de script ne suffira pas.

Une autre erreur de suivi peut-être liée que j'ai remarquée est le copier / coller cassé également en ce sens que si je copie le script A du sous-dossier B / C et que je veux le coller dans le sous-dossier D / E, il déplacera le dossier cible dans le dossier d'origine et collez-y le script comme B / C / D / E / A

En examinant les commits récents, rares sont ceux qui touchent ce domaine de code.
Recherche où trouver les versions compilées du développement récent pour une comparaison croisée afin de le réduire.

Je l'ai coupé en deux en b33b6c8dc3928a6aaa2fcc6ae182e54ec89b5768. @SlySven , pourriez-vous envisager de réparer?

Puis-je rouvrir ceci - le PR / Commit qui a été jugé coupable ne semblait pas possible d'en être l'auteur - AFAICT.

Cependant, étant donné la nature des échecs, je soupçonne qu'il s'agit de la suppression de la première de la paire de méthodes:

• (void) TTreeWidget::rowsAboutToBeRemoved(const QModelIndex& parent, int start, int end)
• (void) TTreeWidget::beginInsertRows(const QModelIndex& parent, int first, int last)

(Le second est vide de code réel et est un mannequin)

Ce qui est étrange , c'est que ces méthodes sont définies - mais ne semblent pas être appelées de n'importe où - c'est pourquoi j'ai pensé qu'il était acceptable de les exciser ...

... cependant, étant donné que Qt documente (void) QTreeWidget::rowsAboutToBeRemoved(const QModelIndex& parent, int start, int end) comme [override virtual protected] j'ai la mauvaise impression d'être mordu par une fonctionnalité C ++ qui m'a pris au dépourvu!

Eh bien oui, soumettez à nouveau sans ces mêmes changements, puis nous pouvons tester à nouveau.

Peut-être ajouter un lien ici comme un bref commentaire pourquoi nous avons besoin de la fonction vide.

D'accord, pouvons-nous vérifier que le remplacement du PR # 4383 c-à-d # 4415 n'affiche PAS ce problème / bogue ...?

Peut-être ajouter un lien ici comme un bref commentaire pourquoi nous avons besoin de la fonction vide.

Après m'être brûlé les doigts, je suis juste en train de le remettre et de le laisser tranquille ...!

Après la fusion de 4415, ce bogue n'est toujours pas revenu. Hourra!