BE 437 Bugs ?

[pfeffer]

Blau ist Nord
Fahrtrichtung habe ich für Überflüssig gehalten, sieht man viel zuverlässiger auf dem Track
Waypoint wird, wenn er gesetzt ist, mit hellblauer Verbindunglinie vom GPS-Pos zum WayPoint angezeigt.

Mir gefallen die Pfeile nicht und die Farbe der Pfeile auch nicht.
Bessere Ideen sind willommen.

Ich wollte es einheitlich machen, gleiche Farben nehmen wie auf der Goto-Seite. Aber die gefällt mir auch nicht. Ich möchte eigentlich auf der Goto-Seite viel größere Pfeile, einen schwarzen Hintergrund und einen sehr hellen Wegrichtungspfeil. (dunkler Hintergrund spart viel Strom, heller Richtungpfeil, damit er auch in der Sonne gut zu erkennen ist). Außerdem möchte ich, dass sich die Kompassrose (per Option) nach der Bewegungsrichtung dreht.
Aber dazu machen wir lieber einen anderen Thread auf.
@Albsucher: nimm 2. mal als Bug auf, ich kümmere mich dann da drum.
1. weiß ich nicht, ob es schon als Bug drin steht, sonst aufnehmen.
3. kann man Caches in der Liste per Hand umsortieren? - war mir nicht klar.

Gruß,
Pfeffer.

Gruß,
Pfeffer.

 

[Bilbowolf]

Die Blacklist Geschichte habe ich heute gefixt. Wird in der nächsten BE vorhanden sein.

 

[minzus]

Ihr seid echt der Wahnsinn!
Die Entwicklung ist ja kaum noch zu verfolgen! :shock:

@Pfeffer:
Kompassrose in Laufrichtung wäre Super!
Ich trau es mich ja fast nicht vorschlagen, aber klasse wäre für's Nachtcachen auch der Mond statt der Sonne!

 

[Bilbowolf]

der Mond statt der Sonne!

Ist bereits bei den Feature Requests drin.

 

[pfeffer]

@Albsucher: danke, irreführende Fehlermeldung beim Kartenimport habe ich beseitigt und insgesamt das Fehlermanegamnt beim Kartenimport verbessert (SVN 453). Bitte testen.

Gruß,
Pfeffer.

 

[Christian und die Wutze]

Da ich gestern endlich meinen Zaurus erhalten habe, habe ich doch auch gleich mit der BE437 gespielt...
Der Import der GPX Dateien von OC hat bei mir folgende Probleme:
Die Koordinaten des Caches werden falsch eingelesen. Die Koordinaten erhalten an die Minuten noch ein e-318 angehängt. Wechselt man dann auf die Detailansicht und zurück auf die Listen wechselt Location zu "not set".
Die Umlaute werden auch nicht richtig angezeigt. Da sehe ich unter Windows und auf dem Z nur "?". Im Cachenamen werden die Umlaute angezeigt.

Ich hoffe, die Fehler waren nicht schon irgendwo beschrieben. Auf die schnelle habe ich nichts gesehen...

 

[Christian und die Wutze]

Befehl zurück: die Umlaute sind nur in einer Cachebeschreibung falsch. Hat wohl eher etwas damit zu tun...

 

[Kalli]

Befehl zurück: die Umlaute sind nur in einer Cachebeschreibung falsch. Hat wohl eher etwas damit zu tun...

Kannst Du mal posten, welcher Cache das ist, dann schau ich trotzdem mal drüber.

Wegen den Koordinaten: Welche Ländereinstellungen hast Du auf dem Zaurus? Es sollte eigentlich keine Probleme mehr mit deutschen und englischen Einstellungen mehr geben, aber zur Sicherheit könntest Du mal auf Deutsch umschalten, falls er auf Englisch steht. Stichwort ist hier der Dezimalseparator, also "," (Komma) oder "." (Punkt).

 

[Christian und die Wutze]

Der Cache ist Rotkäppchen. Der Umlaut im Titel wird richtig dargestellt, in der Beschreibung nicht.

Ländereinstellungen auf dem Zaurus waren natürlich englisch. Ich mag kein Dezimalkomma, da ich dann immer ASCII Daten von Kollegen aus Übersee erst filtern muss, bevor die in Excel geladen werden können... Teste ich aber mal aus. Danke!

Edit: Typo und: Auf Windows benutze ich auch den Dezimalpunkt, da funtkioniert es.

 

[Christian und die Wutze]

Ich habe keine Ahnung, ob Ihr etwas geändert habt, oder mein Spielen erfolgreich war: Nach Löschen aller Relikte auf dem Zaurus und Installation der BE484 kann ich jetzt im Profil meine Koordinaten eingeben und auch richtig die GPX-Dateien von OC einlesen.

Dann kann ich ja jetzt anfangen, mit dem Cachewolf zu cachen!
Wo sind auf OC doch gleich die Caches um Yokohama zu finden?

 

[Kalli]

Der Cache ist Rotkäppchen. Der Umlaut im Titel wird richtig dargestellt, in der Beschreibung nicht.

Der HTML-Anzeiger von Ewe kann nicht mit Umlauten umgehen, wenn die HTML-Escape-Sequenzen genutzt werden (keine Ahnung, wie das richtig heißt).
In der Überschrift des Caches in dem GPX-File steht "Rotkäpchen", in der Beschreibung "Rotkäpchen", daraus wird dann beim GPX-Import "Rotkäpchen" (da sorgt der XML-Parser für). Ich habe mal eine Suche durch meine Cachedatenbank gemacht, so eine Kodierung gibts nur bei wenigen Caches. Da an der Anzeige demnächst (nach der Freigabe der 0.9n) gearbeitet wird, möchte ich daran auch erst mal nichts ändern.

 

[Christian und die Wutze]

Ich habe mir so etwas schon gedacht. Ist auch nicht weiter tragisch, damit kann ich vorerst leben. Vielen Dank!

 

[pfeffer]

@Kalli: ich fänd's schon gut, wenn Du diesen Bug beheben würdest. Ich sehe nicht, dass das mit dem Browser für uns eine Lösung ist. Und meine Variante (Bild) eignet sich a) nicht für die Cachebeschriebung und b) verwendet sie den HTML-parser, den wir jetzt auch verwenden.

Gruß,
Pfeffer.

 

[Kalli]

@Kalli: ich fänd's schon gut, wenn Du diesen Bug beheben würdest. Ich sehe nicht, dass das mit dem Browser für uns eine Lösung ist. Und meine Variante (Bild) eignet sich a) nicht für die Cachebeschriebung und b) verwendet sie den HTML-parser, den wir jetzt auch verwenden.

Gruß,
Pfeffer.

Ich schau übers WE noch mal rein, eigentlich sollte sich das Problem mit den Methoden aus SafeXML beheben lassen.

 

[salzkammergut]

Da kann ich auch noch was dazu sagen nachdem ich den Code (den ich irgendwo im Internet gefunden hatte) in SafeXML eingecheckt habe. SafeXML hat keinen Bug, der Bug liegt im OC XML Generator.

Die korrekte entity für ein "ä" ist "ä" und nicht "ä". Letztere kommt zustande, wenn die Umwandlung in Sonderzeichen zweimal stattfindet, also: Zuerst "ä" nach "ä" und dann das Sonderzeichen & noch einmal in "&" ergibt "ä. Das ist aber falsch!

Der Fehler liegt also beim XML-Exporter von OC und nicht in SafeXML. Schaut Euch dazu auch bitte den Quelltext des Caches (siehe Link weiter oben) an. Da kommt kein "ä" vor sondern nur das korrekte "ä"

Zum Thema SafeXML: Wir sollten es nicht wieder langsamer machen, nur weil woanders ein Bug steckt!

Derzeit wird nach einem & gesucht und der darauffolgende Text bis zum schließenden ; als HTML entity konvertiert. Es wäre kein Problem eine Abfrage einzubauen, die das "&" erkennt und dann einen Sonderfall daraus macht. Aber: Wie gesagt, der Bug liegt bei OC und nicht im CacheWolf!

 

[Kalli]

So habe ich das auch gesehen und wollte deshalb erst mal die Finger von lassen. Ich sehe auch keinen Fehler in SafeXML, ich wollte nur die Methoden nutzen, um einen Workaround zu haben. Ich hätte die Sache dann auch beim GPX-Import klargestellt und nicht beim Aufruf des Beschreibungsfensters.
Was man noch beachten sollte, ist, das XML den "&" auch escaped. Eigentlich müssten die Daten in CDATA drinstehen.

Ich mach mal folgendes: Ich poste das Problem einfach mal ins oc.de-Entwicklerforum und lass den CacheWolf-Code in Ruhe. Das Problem tritt auch nicht wirklich häufig auf.

 

[Christian und die Wutze]

Trotzdem möchte ich die Gelegenheit nutzen, und allen für die schnelle Analyse des Problems danken (obwohl ihr schon genug um die Ohren habt)!

 

[Kalli]

Ich habs mir nochmal angeschaut und checke gleich den Fix ein. Es ist definitiv ein Problem vom Ewe-HTML-Display.
Begründung:
- Tritt auch bei GPX-Files von gc.com auf, z.B. hier
- Wenn man einen HTML-Export macht und sich die HTML-Files im Browser anschaut, sind die Umlaute richtig.

Ich habs jetzt so gelöst, dass beim Import (GPX, Spider, OC.de-Sync) aus "HTML-Umlauten" "richtige" Umlaute werden. Wo möglich, wird noch abgefragt, ob die Beschreibung überhaupt in HTML vorliegt.

 

[Christian und die Wutze]

Danke!
Ich habe gleich noch einen Wunsch:
Ich habe vorhin auf meinem XP Laptop Caches gespidert, (wegen des \ Bugs noch die Dateien manuell umbenannt, ) und mit dem CW auf Windows angeschaut. wunderbar. Dann habe ich das Verzeichnis auf die Speicherkarte kopiert und mit dem Zaurus geöffnet. Leider findet er wieder die Files nicht. Mir ist dann aufgefallen, das auf dem Zaurus die Dateinamen jetzt alle aus Kleinbuchstaben bestehen, CW aber Files mit Großbuchstaben sucht. Kann man CW das irgendwie beibringen, dass der auch nach der jeweils anderen Version sucht, wenn die Datei nicht gefunden wurde?

 

[greiol]

das wäre genial. denn ich habe ein ähnliches problem hier.

mein homelaufwerk liegt auf einem samba server. wenn ich caches unter windows eingelesen habe und will mir die dann unter linux ansehen fehlen die meisten dateien. richtig geil wird es dann wenn ich die pq unter linux nochmal einlese und anschliessend unter windows weiterarbeite.