Version 1.0 - was fehlt noch?

[huzzel]

Das geht ja auch schon jetzt über das Kontextmenü der Listenansicht: "Alle markieren" und dann "Markierte aktualisieren". Um den Status zu überprüfen müßte sowieso jeder Cache geladen werden - der Unterschied zu "Markierte aktualisieren" ist dann nur mehr daß beim Aktualisieren alle Logs (und nicht nur die letzten 5) geladen werden.

Gruß
skg

OK, ich hole weiter aus:
Ich dachte mir das so:
Beim spidern wird doch erst die Überischtsseite geladen und erst dann die einzelnen Caches.
Auf der Übersichtsseite ist doch schon ersichtlich, ob ein Cache noch (oder wieder) aktiv ist. So müsste ja keine einzige Cachebeschreibung geladen werden.

Oder lieg ich mit meinen Überlegungen total daneben, dann obiges einfach streichen

 

[Robin888]

- Copy'n'Paste

Das hat mich auch schon oft gestört. Das ist aber eine Eigenheit der EWE-internen Funktionen.

:-/ Ok. Vielleicht ändert sich das mit EVE!?

- Der Skeleton-Befehl

Wenn keine Wegpunkte angegeben sind, dann sollte man am besten sk benutzen und die Wegpunkte nicht selbst anlegen, sondern vom Solver anlegen lassen.

Warum am besten?
Der Solver legt doch keine Wegpunkte an! Nur IF-Schleifen. Und wenn man den Befehl so benutzt, dann stimmt die Reihenfolge der WPs nicht mehr, da der sk() mit 01 beginnt zu zählen, die Waypoint standardmäßig aber mit 00. Außerdem muss man die Namen der Stationen *noch* zweimal angeben.

"Am besten" wäre es, wenn man die Wegpunkte für die Stationen eingibt/ergänzt und dann den Befehl ausführt. Dann sind alle Bezeichnungen so wie sie sein sollen und man kann sofort damit arbeiten.
Bis vor kurzem hat das auch so funktioniert.

Hast Du die Stationen als Addis eingefügt? Dann funktioniert der sk() Befehl genauso wie wenn GC die Addis liefert.

Ja. Also "Addi:Stage" zumeist. Die Wegpunkte werden auch zugeordnet. Deswegen verstehe ich auch nicht, wieso sie nicht von sk() akzeptiert werden.


Ein schönes Beispiel ist "Moorerlebnis" (GC16NNK). Dort wird nur die Station 6 übermittelt. Gibt man nun sk() ein geht alles glatt.
Fügt man eine Addi: Stage ein (0016NNK) gibt der Befehl *nichts* mehr aus.

- Schließen ohne Speichern

Kannst Du das reproduzieren? Wie beendest Du? Über das Schliessen Kreuz rechts oben oder über das Menü "Anwendung"->"Beenden"? (Das "Schliessen" Kreuz kannst Du in den Präferenzen deaktivieren).

Daran scheint's zu liegen. Am PC fragt er offenbar konsequent nach, auf dem PDA wird er durch das X einfach gekillt. Das X zu kastrieren würde das Problem umgehen, ja.

- Filter beim Start

Ob der Filter beim Starten aktiv ist, hängt davon ab, in welchem Status der Filter beim letzten Speichern war. Versuche mal den Filter zu aktivieren und dann mit "Speichern und Beenden" zu schließen.

Grad versucht. Erst scheint es geklappt zu heban, aber bei einem anderen Profil dann doch nicht. Dreimal "Speichern & Beenden", dreimal Filter verdreht.
Dazu kommt, daß der Filter grundsätzlich umgekehrt angewendet wird, sobald ich einen Cache aktualisiere!

- Darstellung der Cache-Beschreibung

Die HTML-Darstellung kann schon öfters sinnvoll sein. Außerdem müsste man sonst ja auch erstmal das HTML der Webseite in vernünftigen Plaintext übersetzen. Das Problem ist, wie schon so oft, der schlechte HTML-Renderer von EWE.

Ich habe schon mitbekommen, daß EWE hier der Flaschenhals ist. Aber da HTML lediglich Formatierungen enthält, sollte es das Listing nicht verzerren, wenn auf die Formatierung schlicht verzichtet wird. (Von Umbrüchen mal abgesehen, aber die sind ja das kleinste Problem.)

Generell ist die HTML Darstellung ein Schwachpunkt der EWE Umgebung.
Versuch mal die Cachebeschreibung im IE darzustellen. Siehe dazu auch diesen Fred: http://www.geoclub.de/ftopic21200.html

Die Idee mit dem IE ist theoretisch gut. Aber praktisch ist der Befehl "Im Browser offline öffnen" auf meinem PDA ausgegraut. Und genau dort könne ich ihn gebrauchen. Am Desktop kann ich mir die Beschreibung auch online ansehen.
Unterwegs kann ich mir also bloß den Quelltext in der .xml-Datei ansehen. Das ist auch schon beliebig umständlich.

Und in dem Thread geht es darum, daß <sup> nicht interpretiert wird und eine ² auf einmal als 2 dargestellt wurde. Ein Blick in die .xml-Datei könnte das Problem unterwegs lösen, wenn man weiß was <sup> bewirkt.

Aber es wirft die Frage auf, welche Tags interpretiert *werden*.
Das einzig "sinnvolle" was mir einfällt, was man in Plaintext nicht zufriedenstellend umsetzen könnte sind Tabellen und weiße Schrift um Hints zu verstecken. Zweiteres wird aber eher unpraktikabel sein, da es erstens ROT13 gibt und zweitens der Hintergrund auf GC.com nicht weiß ist. ;-)

Ansonsten sehe ich den Mehrwert von HTML noch nicht. Warum also den Flaschenhals nicht weglassen?

BTW: Ich hatte mal einen Cache, bei dem Hinweise als Kommentar im Quelltext des Listings versteckt waren. Diese Kommentare waren nicht nur nicht interpretiert, sondern tatsächlich einfach weg! Keine Chance diesen Cache ohne Zugriff auf das Listing online zu lösen. (Wie bei Ausdrucken natürlich auch nicht.)
Es gibt also immer Caches, die sich nicht zu 100% portieren lassen.


- Stehenbleiben der Aufzeichung

Das konnte ich jetzt noch nicht beobachten. Wenn es läuft (und die Empfangsbedingungen passen) dann läuft CW bei mir flüssig stundenlang durch.

Leider(/Zum Glück?) passiert es nicht oft genug zum reproduzieren.
Ich hatte es aber tatsächlich schon, daß wir auf Wegen unterwegs waren und ich nach regelmässigem Blick auf die Karte felsenfest davon überzeugt war, daß wir uns der Station nährten. Bis ich bemerkte, daß sich die angezeigte Entfernung nicht mehr änderte. Da waren wir schon ein paar hundert Meter in die falsche Richtung gelaufen. Wenig später nochmal. So ein überflüssiger Kilometer bei Eiseskälte hat was... erfrischendes.
Geholfen hat IIRC ein Neustart der Messung im Cachewolf. Nur leider war der eingezeichnete Weg dann weg.

 

[pfeffer]

- Stehenbleiben der Aufzeichung

Das konnte ich jetzt noch nicht beobachten. Wenn es läuft (und die Empfangsbedingungen passen) dann läuft CW bei mir flüssig stundenlang durch.

Leider(/Zum Glück?) passiert es nicht oft genug zum reproduzieren.
Ich hatte es aber tatsächlich schon, daß wir auf Wegen unterwegs waren und ich nach regelmässigem Blick auf die Karte felsenfest davon überzeugt war, daß wir uns der Station nährten. Bis ich bemerkte, daß sich die angezeigte Entfernung nicht mehr änderte. Da waren wir schon ein paar hundert Meter in die falsche Richtung gelaufen. Wenig später nochmal. So ein überflüssiger Kilometer bei Eiseskälte hat was... erfrischendes.
Geholfen hat IIRC ein Neustart der Messung im Cachewolf. Nur leider war der eingezeichnete Weg dann weg.

Was meinst Du genau mit "Neustart der Messung im Cachewolf"? Ein Druck auf "Stop" und "Start" im Goto-Panel?
Eigentlich dürfte dadurch der Track nicht verloren gehen.
Meine Ursachen-Vermutung ist: evtl. ist nach langer Aufzeichnung der PDA zu langsam, um rechtzeitig alle Punkte wiederzugeben, oder ein Ereignis zwischendurch dauert so lang, dass der PDA danach erstmal alte Daten vom GPS verarbeitet...

Gruß,
Pfeffer.

 

[Robin888]

Was meinst Du genau mit "Neustart der Messung im Cachewolf"? Ein Druck auf "Stop" und "Start" im Goto-Panel?
Eigentlich dürfte dadurch der Track nicht verloren gehen.

Genau das. Ob der Track verloren ging weiß ich nicht mehr 100%ig. Ist auch zweitrangig.

Meine Ursachen-Vermutung ist: evtl. ist nach langer Aufzeichnung der PDA zu langsam, um rechtzeitig alle Punkte wiederzugeben, oder ein Ereignis zwischendurch dauert so lang, dass der PDA danach erstmal alte Daten vom GPS verarbeitet...

Ersteres ist schwer zu widerlegen, würde mich aber wundern. Vom Gefühl her sind schon speicherkritischere Situationen aufgetaucht.
(Ich bin mir jetzt nicht sicher, aber ich meine der Bewegungspfeil tanzte noch hin und her, aber die Position wurde nicht mehr aktualisiert. Ergibt das einen Sinn?)
Zweiteres verstehe ich nicht ganz. Das führt argumentativ doch auch nur darauf zurück, daß der PDA ausgelastet ist, oder?

Robin(888)

 

[MiK]

- Der Skeleton-Befehl

Wenn keine Wegpunkte angegeben sind, dann sollte man am besten sk benutzen und die Wegpunkte nicht selbst anlegen, sondern vom Solver anlegen lassen.

Warum am besten?
Der Solver legt doch keine Wegpunkte an!

Ich weiß nicht, ob sich da etwas geändert hat. Aber früher war es so, dass Wegpunkte, die im Solver mit Koordinaten gefüllt wurden, vorher aber noch nicht vorhanden waren, dann auch angelegt wurden. Das müsste man mal testen, ob das noch so funktioniert.

- Darstellung der Cache-Beschreibung

Die HTML-Darstellung kann schon öfters sinnvoll sein. Außerdem müsste man sonst ja auch erstmal das HTML der Webseite in vernünftigen Plaintext übersetzen. Das Problem ist, wie schon so oft, der schlechte HTML-Renderer von EWE.

Ich habe schon mitbekommen, daß EWE hier der Flaschenhals ist. Aber da HTML lediglich Formatierungen enthält, sollte es das Listing nicht verzerren, wenn auf die Formatierung schlicht verzichtet wird. (Von Umbrüchen mal abgesehen, aber die sind ja das kleinste Problem.)

Du möchtest also einfach das HTML plain anzeigen, ohne es vorher explizit nach Plaintext zu konvertieren? Das kann dann schnell sehr hässlich werden. Das ist keine Lösung. Das könnte höchstens eine Zusatzoption für Problemfälle sein.

- Stehenbleiben der Aufzeichung

Das konnte ich jetzt noch nicht beobachten. Wenn es läuft (und die Empfangsbedingungen passen) dann läuft CW bei mir flüssig stundenlang durch.

Leider(/Zum Glück?) passiert es nicht oft genug zum reproduzieren.
Ich hatte es aber tatsächlich schon, daß wir auf Wegen unterwegs waren und ich nach regelmässigem Blick auf die Karte felsenfest davon überzeugt war, daß wir uns der Station nährten. Bis ich bemerkte, daß sich die angezeigte Entfernung nicht mehr änderte. Da waren wir schon ein paar hundert Meter in die falsche Richtung gelaufen. Wenig später nochmal. So ein überflüssiger Kilometer bei Eiseskälte hat was... erfrischendes.
Geholfen hat IIRC ein Neustart der Messung im Cachewolf. Nur leider war der eingezeichnete Weg dann weg.

Zum Thema Eiseskälte: Dabei verhält sich mein PDA ganz von alleine manchmal seltsam...
Ansonsten: Du kannst in solchen Situationen einmal versuchen, was passiert, wenn Du die Karte etwas verschiebst. Ich hatte schon das Problem, dass die in der Karte eingeblendeten Daten nach einem Kartenwechsel erst aktualisiert wurden, wenn die Karte das erste mal verschoben wurde. Bei großem Maßstab kann es sein, dass das erst nach einer größeren Wegstrecke passiert. Dieses Problem müssen wir mal näher untersuchen. Wäre gut zu wissen, ob dies auch bei Dir das Problem ist.

 

[salzkammergut]

... Und wenn man den Befehl so benutzt, dann stimmt die Reihenfolge der WPs nicht mehr, da der sk() mit 01 beginnt zu zählen, die Waypoint standardmäßig aber mit 00.

Geändert: Die Zählung von sk() beginnt jetzt auch bei 00.

Außerdem muss man die Namen der Stationen *noch* zweimal angeben.

Das verstehe ich nicht. Kannst Du das bitte erklären.

Fügt man eine Addi: Stage ein (0016NNK) gibt der Befehl *nichts* mehr aus.

Das war ein Bug. Ursache: Die Datei 0016NNK.xml existiert nicht. Ist gefixt.

Grüße
salzkammergut

 

[Robin888]

- Der Skeleton-Befehl

Ich weiß nicht, ob sich da etwas geändert hat. Aber früher war es so, dass Wegpunkte, die im Solver mit Koordinaten gefüllt wurden, vorher aber noch nicht vorhanden waren, dann auch angelegt wurden. Das müsste man mal testen, ob das noch so funktioniert.

Hab' ich. Funktioniert nicht.

- Darstellung der Cache-Beschreibung

Du möchtest also einfach das HTML plain anzeigen, ohne es vorher explizit nach Plaintext zu konvertieren?

Das habe ich nicht gemeint. Die Konvertierung könnte ja schon beim Import geschehen.

Aber wie es aussieht kann ich mit salzkammerguts Lösung leben.

- Stehenbleiben der Aufzeichung

Ansonsten: Du kannst in solchen Situationen einmal versuchen, was passiert, wenn Du die Karte etwas verschiebst. Ich hatte schon das Problem, dass die in der Karte eingeblendeten Daten nach einem Kartenwechsel erst aktualisiert wurden, wenn die Karte das erste mal verschoben wurde. Bei großem Maßstab kann es sein, dass das erst nach einer größeren Wegstrecke passiert. Dieses Problem müssen wir mal näher untersuchen. Wäre gut zu wissen, ob dies auch bei Dir das Problem ist.

Wenn es nochmal passiert, werde ich es ausprobieren. Aber wie gesagt: Da das Problem noch nicht reproduzierbar ist, muss ich warten, bis es wieder auftritt.

Robin(888)

 

[Robin888]

Die Zählung von sk() beginnt jetzt auch bei 00.

Gute Sache. Besser wäre vielleicht gewesen die Waypoints bei 01 starten zu lassen, da das etwas intuitiver ist (die meisten Multis beginnen mit der ersten Station), aber das ist auch nicht so tragisch.

Außerdem muss man die Namen der Stationen *noch* zweimal angeben.

Das verstehe ich nicht. Kannst Du das bitte erklären.

Naja, erstmal legt(e) man einen Waypoint 00xxxx an und nennt ihn "Punkt 1 (Mauer)".
Dann führt(e) man sk aus und erhält folgende Schleife:

IF $01xxxx="" THEN
  $01xxxx = ""
  "Stage 1 = " $01xxxx
  goto($01xxxx); STOP
ENDIF

Möchte aber haben:

IF $00xxxx="" THEN
  $00xxxx = ""
  "Punkt 1 (Mauer)= " $00xxxx
  goto($00xxxx); STOP
ENDIF

Dann muss(te) man zumindest an vier Stellen den Wegpunkt und an einer Stelle den Namen ändern. (Ich dachte an zweien.) Für jede Station.

Fügt man eine Addi: Stage ein (0016NNK) gibt der Befehl *nichts* mehr aus.

Das war ein Bug. Ursache: Die Datei 0016NNK.xml existiert nicht. Ist gefixt.

Cool!
Damit hat sich obiges erledigt.

Übrigens: Die DEG/RAD-Switch ist auch gut. Kann man bestimmt mal gebrauchen!

Robin(888)[/code]

 

[salzkammergut]

[Naja, erstmal legt(e) man einen Waypoint 00xxxx an und nennt ihn "Punkt 1 (Mauer)".
Dann führt(e) man sk aus und erhält folgende Schleife:

Warum führst Du sk aus? Wenn der Cache Addis enthält wie in diesem Fall ist das numerische Argument für sk() nicht notwendig. Also einfach: sk(). Der sk() Befehl mit dem numerischen Argument ist gedacht für den Fall, daß keine Addis existieren.

Ein "IF"-Befehl ist übrigens keine "Schleife", da er immer nur einmal durchlaufen wird. Siehe auch Wikipedia - Schleife

Grüße
skg

 

[Robin888]

Warum führst Du sk aus? Wenn der Cache Addis enthält wie in diesem Fall ist das numerische Argument für sk() nicht notwendig. Also einfach: sk(). Der sk() Befehl mit dem numerischen Argument ist gedacht für den Fall, daß keine Addis existieren.

Wie gesagt, das hat sich jetzt ja erledigt. Aber als der leere Aufruf von sk() nicht funktionierte (also bis heute morgen. ;-)) war das der einzige Ausweg.

Ein "IF"-Befehl ist übrigens keine "Schleife", da er immer nur einmal durchlaufen wird.

Das ist mir wohl bewusst. ich wusste halt nur nicht, wie ich ganzen Code-Teil zwischen IF und ENDIF bezeichnen sollte.
Ist IF-Block besser?

Robin(888)

 

[salzkammergut]

Ich habe normalerweise nicht suchbare und gefundene Caches ausgefiltert. Starte ich den Cachewolf werden jedoch grundsätzlich die gefilterten Caches angezeigt, und ich muss den Filter erstmal neu "anwenden" um mein gewünschtes Ergebnis zu erzielen.

Ich habe die Speicherung des Filters überarbeitet. Der aktuelle Status des Filters sollte jetzt immer richtig gespeichert werden. Bitte prüfe noch mal ob Du Deine Probleme reproduzieren kannst und poste das Ergebnis.

Grüße
skg

 

[Robin888]

Ich habe die Speicherung des Filters überarbeitet. Der aktuelle Status des Filters sollte jetzt immer richtig gespeichert werden. Bitte prüfe noch mal ob Du Deine Probleme reproduzieren kannst und poste das Ergebnis.

Also:
Das Verhalten nach dem Aktualisieren ist jetzt genau *umgekehrt*. %-)
Wenn ich Caches aktualisiere, dann ist hinterher der Filter positiv aktiv.

Das Speichern klappt auch noch nicht so ganz. Es folgen die Verhaltensweisen für: Filterzustand X, Speichern&Beenden, Neustart => Filterzustand Y

Filterzustand: Filter positiv aktiv
Resultat nach Speichern und Neustart: Filter positiv aktiv

Filterzustand: Filter negativ aktiv
Resultat nach Speichern und Neustart: Filter positiv aktiv

Filterzustand: Filter aufgehoben
Resultat nach Speichern und Neustart: Filter aufgehoben

Filterzustand: Alles gefiltert
Resultat nach Speichern und Neustart: Alles gefiltert

Also noch nicht astrein.

Und Bilder kann ich in der Cachebeschreibung auch keine sehen, obwohl die Option aktiv ist.
(Option deaktivieren, speichern, Neustart, aktivieren, speichern, Neustart hat auch nicht geholfen.

Robin(888)

 

[salzkammergut]

Danke. Auf die Invertierung hatte ich doch glatt vergessen.

Das Problem mit den Bildern sollte auch geklärt sein. Es hat zwar in der Entwicklungsumgebung und am PDA funktioniert aber aus unerfindlichen Gründen in der Windows exe Datei nicht. Ich habe es jetzt anders gelöst, sodaß auch die statisch gelinkte exe Datei funktioniert.

Gruß
skg

 

[Robin888]

Ups! Wollte ich noch dazuschreiben, daß ich es mit der Win32-VErsion ausprobiert habe. Hab's dann aber vergessen.
Ich werd's bei einer der nächsten Updates ausprobieren.

Robin(888)

 

[huzzel]

Wie wäre es, wenn man verschiedene Standardfilter definieren könnte (so 2-3 Stück)?

 

[Engywuck]

Oder auch schön: Das Filter-Menü bekommt die beiden Funktionen "Laden" und "Speichern", dann kann man sich beliebig viele Filter erstellen und immer den gewünschten Laden.

Engywuck

 

[huzzel]

Oder auch schön: Das Filter-Menü bekommt die beiden Funktionen "Laden" und "Speichern", dann kann man sich beliebig viele Filter erstellen und immer den gewünschten Laden.

Engywuck

Dann fände ich gut, wenn man auf 2 oder 3 direkt zugreifen kann (z.B. die letzten 3 gespeicherten).

 

[MiK]

Eigentlich geht es in diesem Thread um Fehler, die unbedingt noch für die 1.0 gefixt werden müssen. (Und um Anleitung und Übersetzung, die noch fertiggestellt werden müssen.) Aber nicht um neue Features.

 

[huzzel]

Da das Thema wieder aufkam, schieb ich ihn doch einfach mal wieder vor

Zum Thema:
Bei einem gestrigen Event habe ich mit 2 Cachern gesprochen. Der eine hat den Cachewolf gerade erst installiert, der andere will ihn bald installieren.
Bei dem Gespräch mit dem ersten kam heraus, dass das nervigste für ihn ist, dass die Kartenansicht so ewig auf "suche beste Karte" steht.
Ist da vllt noch was zu machen?