Mudlet: Durch das Verschieben von Skripten und Ordnern werden andere gelöscht

Ja, großer. Passiert dies auch bei echten Gegenständen oder nur bei den leeren 'New Triggers'?

In der Tat. So habe ich es bemerkt .. 😢

Dies ist nur ein kleines kurzes Beispiel für Ihren Vergleich.

Außerdem habe ich festgestellt, dass in einigen Fällen nur einige (aber nicht alle) der verschobenen Elemente nach dem Schließen und Öffnen des Profils wieder angezeigt werden. Das erneute Öffnen des Skript-Editors reicht nicht aus.

Ein weiterer möglicherweise verwandter Folgefehler, den ich bemerkt habe, ist, dass das Kopieren / Einfügen ebenfalls fehlerhaft ist. Wenn ich Skript A aus dem Unterordner B / C kopiere und es in den Unterordner D / E einfügen möchte, wird der Zielordner stattdessen verschoben den ursprünglichen Ordner und fügen Sie das Skript dort wie B / C / D / E / A ein

In den letzten Commits gibt es nur wenige, die diesen Codebereich berühren.
Suchen Sie, wo Sie kompilierte Versionen der jüngsten Entwicklung für einen Kreuzvergleich abrufen können, um sie einzugrenzen.

Ich habe es halbiert auf b33b6c8dc3928a6aaa2fcc6ae182e54ec89b5768. @SlySven , könntest du dir das

Kann ich diese wieder öffnen - die PR / Commit , dass die Schuldigen sein nicht möglich beurteilt wurde , scheint der Täter zu sein - AFAICT.

Angesichts der Art der Fehler vermute ich jedoch, dass die erste der beiden Methoden entfernt wurde:

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

(Der zweite ist leer von aktuellem Code und ist ein Dummy)

Das Seltsame ist, dass diese Methoden definiert sind - aber anscheinend nicht von irgendwoher aufgerufen werden -, weshalb ich dachte, es wäre in Ordnung, sie herauszuschneiden ...

... jedoch, da Qt (void) QTreeWidget::rowsAboutToBeRemoved(const QModelIndex& parent, int start, int end) als [override virtual protected] dokumentiert, habe ich das böse Gefühl, von einer C ++ - Funktion gebissen zu werden, die mich überrascht hat!

Nun ja, ohne diese Änderungen erneut einreichen, dann können wir erneut testen.

Fügen Sie hier möglicherweise einen Link als kurzen Kommentar hinzu, warum wir die leere Funktion benötigen.

Okay, können wir überprüfen, ob der Ersatz für den PR # 4383, dh # 4415, dieses Problem / diesen Fehler NICHT anzeigt ...?

Fügen Sie hier möglicherweise einen Link als kurzen Kommentar hinzu, warum wir die leere Funktion benötigen.

Nachdem ich mir die Finger verbrannt habe, lege ich es einfach zurück und lasse es ...!

Nach dem Zusammenführen von 4415 kehrte dieser Fehler immer noch nicht zurück. Hurra!