Zur Reproduktion des Fehlers (Version 6.3.6 Build 4382, vermutlich aber auch älter)
Ich befinde mich in der Bibliothekssicht von mAirListDB und habe einen Ordner mit vielen Einträgen ausgewählt. Ich scrolle zu einem Song weiter unten, markiere diesen und mit SHIFT einen weiteren, so dass ein Block von mehreren Titeln ausgewählt ist. Dann wähle ich “Massenbearbeitung” über das Kontextmenü und ändere etwas. Nach dem Speichern der Änderung über “OK” komme ich zurück in die Liste. In dieser ist nun nur noch das erste Element meiner Auswahl markiert. Da ich aber die gleiche Auswahl wie zuvor noch in einen anderen Ordner verschieben möchte, markiere ich nochmal mit SHIFT das letzte Element und erwarte, wieder den gleichen Block markiert zu haben!
Pustekuchen! Der Block enthält alle Titel von ganz oben bis zu dem zuletzt markierten Element. Das sieht man aber nur bei geeigneter Scrollposition und auch dann nur, wenn man darauf achtet.
Ich habe auf diese Weise versehentlich mehr als 1000 Titel in einen anderen Ordner verschoben, was nur durch Einspielen eines (glücklicherweise) aktuellen Datenbankbackups zu beheben war.
Mir passiert das sicher kein zweites Mal, aber anderen mag Ähnliches passieren und die haben dann kein aktuelles Backup der Datenbank…
@dwsw
hmm… so einen Fehler kenn ich gar nicht von der mAirList-Daenbank.
Was mir jetzt ganz spontan einfällt, update mal auf die Version 6.3.10.
Dann müsstest du es noch mal in der Datenbank probieren, ob es so funktioniert, wie es soll.
Denn die 6.3.6 ist ja nun auch schon ein paar Tage alt.
ich habe das eben mal nachgestellt und kann die Beobachtung bestätigen.
(OT-Empfehlung: Ich habe mich an solch Windows-untypisches Verhalten an manchen Stellen von mAirList mittlerweile gewöhnt. Mit einer kurzfristigen Abhilfe rechne ich nicht. Fazit: damit leben. In Hessen sagt man: Bevor isch misch uffresch, isses mir lieber egal)
Ich habe die Problemstellung an Torben weitergeleitet. Mit einer Reaktion ist vielleicht erst nächste Woche zu rechnen, weil er diese Woche mal das mit diesem “Urlaub” probieren möge (die älteren unter euch erinnern sich vielleicht noch, was das ist).
Ein Jahr Homeschooling und gewisse Einschränkungen hinterlassen auf Dauer doch Spuren - und ohne Torben funktioniert die Weiterentwicklung von mAirList nun mal nicht.
Das wurde als Feature-Request eingestellt und auch prompt als “New” markiert, damit es zu gegebener Zeit abgearbeitet werden kann.
Eben gerade, damit es nicht in Vergessenheit gerät.
“Feature Request” ist vielleicht zu weit gegriffen. Aber wir wollen ja doch noch einen Unterschied machen zwischen “kritischer Bug, der uns hier alle gerade am Senden hindert” und “Unschönheit, die schon seit 15 Jahren besteht, bis jetzt aber noch niemand zur Sprache gebracht hat”. Ok?
Natürlich habe ich diese ganzen Bäume/Listen nicht selbst programmiert, sondern verwende eine relativ verbreitete Open-Source-Komponente (Virtual Treeview) dafür.
Ich habe etwas recherchiert, und sie besitzt tatsächlich eine Option, um das Verhalten der Windows-ListViews abzubilden, dass ein Rechtsklick auf ein Element dieses zunächst markiert. (Auch wenn ich glaube, dass das in früheren Windows-Versionen noch anders war.)
Leider ist die Option standardmäßig ausgeschaltet. Für einen Großteil der in mAirList vorkommenden Listen-GUIs kann ich sie zentral an einer Stelle in meinem Code einschalten, weil diese alle von derselbenen (von mir programmierten) Basisklasse abgeleitet sind. Bei weiterhin vielen anderen müsste ich das aber getrennt für jeden TreeView in jedem Dialog machen, was sehr zeitaufwändig wäre.
Ich beschränke mich daher im Moment auf die wichtigsten Dialoge (ab Build 4427 dann), und bei den anderen werde ich es nach und nach im “Vorübergehen” erledigen. Sollte es irgendwo besonders übel aufstoßen, bitte melden.
Das müßte aber vor XP gewesen sein! (Auf dieser Version lief die Software, mit der mir das anderenorts geschilderte Mißgeschick widerfuhr. Ich weiß das, da ich es damals verifiziert hatte, bevor ich beim Studiobetrieb ein Faß aufmachte.)
Tatsache ist: In diesen Zeiten, in denen man sich schon “Urlaub” nehmen muss, um mal in Ruhe durchs Forum zu schauen, fällt die eine oder andere Kleinigkeiten hinten rüber. Daher müssen wir wirklich etwas vorfiltern und priorisieren.
Ihr könnt uns dabei helfen, indem ihr von euch aus schon versucht, die gemeldeten Dinge (und wir sind für jedes Feedback dankbar!) richtig als Bug, Unschönheit oder Feature Request einzuordnen, und den dahinterstehenden Nachdruck passend zu dosieren.
Die Sache mit dem Rechtsklick fällt für mich definitiv in die Kategorie “Unschönheit, mit der man im Zweifel noch ein bisschen länger leben kann”.
Zumal sie offenbar schon seit 15 Jahren bestand und niemand sie bisher zur Sprache gebracht hat. Diese Tatsache, in Verbindung mit dem Hinweis auf “erhebliche Fehlbedienung mit Datenverlust” (warum hat das dann vorher noch nie jemand bemängelt?) hat dann vermutlich dazu geführt, dass es hier als Feature Request eingestuft wurde. Also quasi eine Sache, die man bei Gelegenheit mal erledigen kann, wie eben die ganzen kleinen Feature-Wünsche, die hier regelmäßig geäußert werden. (Wir unterscheiden im internen Workflow intern nur zwischen Bug und Feature-Wunsch, sowas wie “Unschönheit” haben wir aktuell nicht.)
Leider sind es wirklich genau diese Kleinigkeiten, die aus Zeitmangel liegen bleiben. Denn gleichzeitig bin ich auch in der Pflicht, mich um “große” Neuerungen (sowohl mAirList-Features, als auch andere Produkte) zu kümmern, damit wir auch in Zukunft noch Geld verdienen und den ganzen Laden hier am Laufen halten. Und ab nächste Woche ist dann in NRW wieder Homeschooling angesagt…
alt.
