if (currToken.equals("$GPGSV")){
//Vm.debug("In $$GPGSV");
i = 0;
while(ex.endOfSearch() != true){
currToken = ex.findNext();
i++;
if (currToken.length()==0) continue; // sometimes there are 2 colons directly one after the other like ",," (e.g. loox)
switch (i){
case 3: this.numSatsInView = Convert.toInt(currToken); interpreted = true; break;
} // switch
} // while
=============> if (Fix > 0) this.set(latNS, latDeg, latMin, "0", lonEW, lonDeg, lonMin, "0", CWPoint.DMM);
} // if
//Vm.debug("End of examine");
} //while
Bei mir sind die führenden Nullen nicht nötig. Das muss an etwas anderem liegen. Ich habe gerade Deine Beispielzeile abgetippt und sie wird bei mir ohne Probleme interpretiert.snaky schrieb:Mit der 008 habe ich nur das Problem, dass CW die 2 Nullen unbedingt braucht, um die Koordinaten zu akzeptieren. Das ist aber nicht weiter schlimm.
Du meinst, es ist ein Bug, dass man "Parse" klicken muss, damit die Eingabe geparst wird?snaky schrieb:Der Bug ist, dass man neue (nicht ganz konforme, z. B. weil eben genau nicht 008°, sondern 8° angegeben wurde) Koors eingibt, auf Apply klickt, die Daten aber wieder auf die alten Koors (die des Hauptwegpunktes) zurückgesetzt werden - und das ohne Rückmeldung.
Oh ja, in die Falle bin ich auch schon öfters getreten. Ein Mitcacher von mir auch. Ich musste ihm erst erklären, zuerst parse, dann anwenden. Ist nicht ganz intuitiv.Du meinst, es ist ein Bug, dass man "Parse" klicken muss, damit die Eingabe geparst wird?
automatisch parsen geht aber nicht, weil er manchmal fehler macht dabei und beim parsen das eingefügte überschrieben wird.Du meinst, es ist ein Bug, dass man "Parse" klicken muss, damit die Eingabe geparst wird?
MiK schrieb:Bei mir sind die führenden Nullen nicht nötig. Das muss an etwas anderem liegen. Ich habe gerade Deine Beispielzeile abgetippt und sie wird bei mir ohne Probleme interpretiert.
Du meinst, es ist ein Bug, dass man "Parse" klicken muss, damit die Eingabe geparst wird?
Das waren auch meine Gedanken. Ich bin auch schon die NMEA-Logs durchgegangen, alles ok. Ich hatte an allen Stellen wo die Koordinaten gesetzt werden, Abfragen auf "0.0" einprogrammiert: der Fehler trat immer nur bei der einen Zeile auf. Fix ==0 && latDec == 0 dürfte wie Du schon sagtest nie auftreten. Ich werde mal eine Nacht drüber schlafen.Allerdings kann ich nicht erkennen, wie er Ursache Deines Problems sein sollte. Fix wird schließlich nur gesetzt, wenn auch die Koordinaten gelesen werden. - ahh - ich glaub ich hab's: Kann es sein, dass Dein GPS im $GPRMC oder im $GPGGA zwar fix meldet, aber anstelle der Koos einfach nix, also ",," an der Stelle? vielleicht passiert das in ungünstigen Momenten beim Übergang zum Fix?
Da dies bei blöden GPS auf jeden Fall zu dem von Dir beschriebenen Verhalten führen kann, habe ich den Patch schon gemachtpfeffer schrieb:Dann könnte nämlich der Fix erkannt und danach das setzen von lat/lon scheitern.
Wenn Du das als Ursache überprfüen könntest, dann mache ich einen entsprechenden patch.
habe ich einen Patch für, anbei.rautaxe schrieb:1. Installation, ich hatte einfach das PC-Verzeichnis auf den PDA geschoben und
dann die ARM.exe rüberkopiert. Dies führ dazu, das er beim Aufstarten das Profile verzeichnis wissen möchte, denn das stand noch auf "D:\....." (vom PC), das Problem
ist, dass ich es nicht geschafft hab das Verzeichnis nach /Speicherkarte/cachewolf...
zu wechseln, da er immer noch den Laufwerksbuchstaben vorne hat.
Lösung: die pref.xml manuell löschen, dann konnte ich auch wieder auf die PPC Verzeichnisse zugreifen.
bei mir war es auf dem PC das Programmverzeichnis von Cachewolf, auf dem PDA auch das Root-Vrzeichnis.MiK schrieb:Welches Verzeichnis sollte dann vorausgewählt sein mit diesem Patch? Ich hätte das Cachewolf-Verzeichnis erwartet. Aber bei mir ist es das root-Verzeichnis.
verschwindet automatisch? - hmm, an anderer Stelle könnten wir es gut gebrauchen...MiK schrieb:Seltsamer finde ich aber das verhalten, wenn ich mehrere Sekunden nichts auswähle. Dann beendet sich der Dialog von alleine und in der Titelleiste steht "untitled".
treten diese beiden Phänomene mit der ungepatchten Version nicht auf?MiK schrieb:Edit2: Wenn ich auf "Cancel" klicke, beendet sich erstmal Cachewolf scheinbar. Kurze Zeit später kommt dann doch das Cachewolf-Fenster im "untitled"-Status.
So toll ist es aber auch nicht. Das Verzeichnis sollte möglichst leer sein. Oder zumindest keine Unterordner enthalten, da diese alle als Profile angezeigt werden.pfeffer schrieb:bei mir war es auf dem PC das Programmverzeichnis von Cachewolf, auf dem PDA auch das Root-Vrzeichnis.
Ich bin mir selbst unschlüssig, was das beste ist. Am liebsten hätte ich ~home. Aber da habe ich Angst, dass wir Probleme auf unterschiedlichen Platformen bekommen. Wenn es das Haupt-Verz ist, dann ist es recht deutlich, dass der Anwender sich selbst was aussuchen soll. Wenn es das Programmverz. ist, dann verleitet es zum "ok" klicken - was eigentlich auch nicht so schlimm ist.
Mit dem RC1 kann ich es zumindest nicht nachstellen. Kann aber auch an einem der anderen Patches liegen.pfeffer schrieb:treten diese beiden Phänomene mit der ungepatchten Version nicht auf?MiK schrieb:Edit2: Wenn ich auf "Cancel" klicke, beendet sich erstmal Cachewolf scheinbar. Kurze Zeit später kommt dann doch das Cachewolf-Fenster im "untitled"-Status.
MiK schrieb:Der Grund war: Im Kontextmenü sollten nur noch Sachen stehen, die sich auf den aktuell gewählten Cache beziehen. ....
pfeffer schrieb:treten diese beiden Phänomene mit der ungepatchten Version nicht auf?MiK schrieb:Edit2: Wenn ich auf "Cancel" klicke, beendet sich erstmal Cachewolf scheinbar. Kurze Zeit später kommt dann doch das Cachewolf-Fenster im "untitled"-Status.