• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

Positionierung in Liste nach ausblenden eines Caches

Engywuck

Geowizard
Mir ist aufgefallen: Wenn ich einen Cache z.B. auf die Blacklist setze, dann ist mein aktuell in der Liste selektierter Cache danach wieder der erste - weil das Programm den, auf dem es das letzte Mal stand, in der Liste nicht mehr findet.
Das ist insbesondere dann lästig, wenn man eine große Liste durchgeht, die ungeeigneten per Blacklist rauswirft und dann immer wieder an die Stelle scrollen muss, wo man zuletzt war. Mein Erwartungswert wäre, dass ich dann den Cache davor in der Liste angezeigt bekomme. Ich interpretiere das mal als Fehler bzw. zumindest als schwer fehlendes Feature ;-)
Diesbezüglich habe ich ein Stück Code geschrieben, was das Problem behebt. Aber da ich mir hier nicht ganz so sicher bin, ob ich da was fundamentales übersehen habe, bitte ich um ein kurzes Review. (Da sich die Änderungen innerhalb einer Methode abspielen, sollte der Aufwand überschaubar sein...)

Grüße,
Engywuck
 

Anhänge

  • TableUpdPosition.zip
    900 Bytes · Aufrufe: 6
OP
Engywuck

Engywuck

Geowizard
Hier nochmal nach dem Einbau einiger kleiner aber feiner Verbesserungsvorschläge von skg. Merci!

Grüße,
Engywuck
 

Anhänge

  • TableUpdPosition.zip
    948 Bytes · Aufrufe: 4
OP
Engywuck

Engywuck

Geowizard
Da keine weiteren Proteste kamen, habe ich das mal Commited. Ab Build 1448 für die Allgemeinheit testbar.

Grüße,
Engywuck
 

pfeffer

Geowizard
Ich habe noch ein paar Anmerkungen dazu:

1. es muss doch einen effizienteren Weg geben. zB, sich vor myMod.updateRows(); die Zeile in der Liste merken und hinterher (falls der vorher gewählte nicht mehr sichtbar ist) eine Zeile drüber auswählen.

2. Falls es nicht unumgänglich ist, die komplette, sichtbare Datenbank zu kopieren, dann muss sie leider wegen eines Bugs in der GarbageCollection hinterher wieder gelöscht werden, in dem alle Elemente des Vectors = null gesetzt werden.

Gruß,
Pfeffer.
 
OP
Engywuck

Engywuck

Geowizard
pfeffer schrieb:
1. es muss doch einen effizienteren Weg geben. zB, sich vor myMod.updateRows(); die Zeile in der Liste merken und hinterher (falls der vorher gewählte nicht mehr sichtbar ist) eine Zeile drüber auswählen.
Hab ich auch drüber nachgedacht. Mir ist aber nix eingefallen. Schließlich weiß ich nicht, was das Anwenden der Filter auf die Caches mit der Sichtbarkeit anstellt - das kann ja sehr unterschiedlich sein, und daher kann man nach Anwenden der Filteroperation nicht mehr wissen, welcher Cache vorher sichtbar war. Irgendwie muss man es sich also merken. Das jedoch kann man aber vielleicht intelligenter lösen.
Übrigens: Aufgrund eines Hinweises von Skg merkt man sich hier nur die Caches bis zur ausgewählten Zeile.

pfeffer schrieb:
2. Falls es nicht unumgänglich ist, die komplette, sichtbare Datenbank zu kopieren, dann muss sie leider wegen eines Bugs in der GarbageCollection hinterher wieder gelöscht werden, in dem alle Elemente des Vectors = null gesetzt werden.
Interessanter Hinweis. Würde das dann nicht auch auf sortDB und filteredDB in myTableModel zutreffen? Das ist doch ein sehr ähnlich gelagerter Fall.

Gruß,
Engywuck
 

pfeffer

Geowizard
Da diese Routine relativ häufig aufgerufen wird, finde ich es ziemlich doof, da so eine zeitraubende Geschichte einzubauen.

dazu fallen mir 2 Dinge ein:
1. vielleicht könntest Du Vm.ArrayCopy verwenden: das ist nativ und deswegen erheblich schneller
2. anstatt den Cache auszuwählen, der vor dem Aufruf genau darüber stand, könnte man doch einfach, wenn der Cache weggefiltert wurde, die gleiche Zeile wie vorher (oder von mir aus eine drüber) auswählen, oder? - Das wäre wesentlich weniger rechenintensiv und (ich denke) genauso intuitiv, oder? (dann muss man zusätzlich den Fall bedenken, dass durch das Filtern es sein könnte, dass es weniger angezeigte Wegpunkte geben könnte als die Zeile, die vorher ausgewählt war. Dann würde ich erwarte, dass die letzte auswählt wird)

Gruß,
Pfeffer.
 

MiK

Geoguru
Wenn die Funktion zu deutlichen Verzögerungen führt, würde ich sie ganz weglassen. So schlimm fand ich es nicht, dass nach dem wegfiltern zur ersten Stelle gesprungen wurde. Einfach zur gleichen Zeilennummer zu springen halte ich für sinnlos. Oft filtert man doch recht viel auf einmal weg. Dann hat die gleiche Zeilennummer nicht viel mit der ursprünglichen Position in der Liste zu tun.

Also: Entweder das ganze funktioniert richtig und schnell oder ich würde es ganz weglassen.
 
OP
Engywuck

Engywuck

Geowizard
Ich hab es (schon vor dem Commit) natürlich mal ausprobiert. In meinem Profil mit 700 Caches konnte ich auf meinem PDA keine Verlangsamung bemerken. Man sollte auch die Kirche etwas im Dorf lassen: Hier wird einmal beim Listenupdate ein Vektor mit vielleicht ein paar 100 Einträgen erzeugt. Das macht den Kohl nicht so richtig fett.
Da gibts sicher andere Stellen, wo wir noch mehr sparen können. Mit Cache-Typen als ints, z.B. ;-)

Grüße,
Engywuck
 
OP
Engywuck

Engywuck

Geowizard
Ich habe noch mal über Pfeffers Bedenken nachgedacht und kann eine zweiten Lösungsansatz bieten.
Vorteil: Es gibt keine extra-Schleife, in der Caches gemerkt werden.
Nachteil: Es gibt ein neues Feld (Typ short) in Klasse CacheHolder, somit einen Hauch mehr Speicherverbrauch.

Was von beiden Varianten besser ist: Keine Ahnung ;-)

Grüße,
Engywuck
 

Anhänge

  • TableUpdPosition.zip
    1,3 KB · Aufrufe: 5

mirabilos

Geocacher
Dann sollte man vielleicht dokumentieren, daß ein Profil maximal 64 Ki Caches
enthalten kann… und nen Überlauf abfangen.
 
OP
Engywuck

Engywuck

Geowizard
mirabilos schrieb:
Dann sollte man vielleicht dokumentieren, daß ein Profil maximal 64 Ki Caches
enthalten kann… und nen Überlauf abfangen.
Wer alle Caches Deutschlands in einem Profil verwalten will, der hat sowieso einen an der Klatsche und es nicht besser verdient ;-)

Engywuck
 

mirabilos

Geocacher
Ich mein ja nur… irgendwann sind Limits immer doof.
Ich zitiere: „640K ought to be enough for everyone.“
Vielleicht weißt Du, was ich meine.

Ich komm schon allein mit OC und den meisten GCs in
einem 12km Umkreis auf weit über 1000 Caches hier…
wenn dann noch TC und NC dazukämen und man die
Steigerungsrate dazunimmt sind 20000 auch nicht mehr
fern. Und ich weiß noch, daß ich 1990, als mein Vater
mir seinen alten EURO PC geschenkt hat, weil er sich
den EURO XT mit einer 20 MiB Festplatte geholt hat,
wir beide dachten, die würde man nie vollkriegen…
 

salzkammergut

Geomaster
@Mirabilos: Du hast ja recht, dass Grenzen schneller erreicht werden als man denkt. Nur: Wenn wir CW wirklich mit 64K (bei short eigentlich nur 32K) oder mehr Caches nutzen wollen, müssen wir auf eine Datenbank umstellen. Die Speicherung der Daten im XML-Format ist nur für kleine Datenmengen effizient. Das ist dann aber eine grössere Änderung.

salzkammergut
 

mirabilos

Geocacher
Hm okay, ist auch ein Argument. Ich stand eher auf dem Punkt,
daß man nicht Limits einbauen sollte, wo keine wären… aber das
Starten von CW wird auch immer langsamer, mit all den neuen
Features, mehr Caches, aber gerade auch den Workarounds ;-)

Deshalb hab ich auch nur geschrieben, daß man das dokumentieren
sollte. Einfach nur, daß sich hinterher keiner beschwert. Und halt beim
Zufügen prüfen, ob die 32 Ki (danke für die Korrektur) voll sind.
 
OP
Engywuck

Engywuck

Geowizard
mirabilos schrieb:
Ich stand eher auf dem Punkt,
daß man nicht Limits einbauen sollte, wo keine wären…
Prinzipiell hast Du natürlich recht. Aber wenn Du Deinem 20 Jahre alten Lada Matsch-und-Schnee-Reifen aufziehst, halte ich den Aufkleber "mit diesen Reifen nicht schneller als 160 km/h fahren" dennoch für entbehrlich...
Zum anderen: Hier handelt es sich ja "nur" um einen kleinen Hilfsindex. Wenn hier der Cast schief geht, dann haut maximal die Neupositionierung nach dem Ausfiltern des selektierten Caches an eine unvorhergesehe Stelle - die Funktionalität des Cachewolfs als solche wird nicht beeinträchtigt.

Grüße,
Engywuck
 
Oben