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

BUG: RC2 Error getenv

espe2310

Geocacher
Hallo Cachewolf Gemeinde,

gestern habe ich zum ersten Mal den Cachewolf auf meinem Medion Navi zum Laufen gebracht danke der Ewe-Modifikationen von Rheinkraxler.
Nach dem Aufspielen von RC2 heute morgen erscheint die Meldung:
Exception thrown in main() java.lang.NoSuchMethodeError: getenv

Naja, es ist halt kein vollständiges CE.
Das macht sich auch sonst bemerkbar:
- die Image-Anzeige kann ich nur brutal als Task killen, es gibt keinen Button
- der Sonnenstand bleibt bei 58 grd stehen, ich vermute mal, das Programm greift auf die innere Uhr zu.

Mal sehen, wie das ganze in der Praxis zu handhaben ist. Sieht auf jeden Fall sehr gut aus, es gibt aber noch viel zu lernen für mich.

Danke für das schöne Programm
Ernst
 

MiK

Geoguru
Erstmal ist das natürlich keine "offiziell" unterstützte Version. Aber vielleicht kann ja Rheinkraxler etwas machen.
espe2310 schrieb:
- die Image-Anzeige kann ich nur brutal als Task killen, es gibt keinen Button
Für solche Problemfälle wurde das Schließen der Bildanzeige zusätzlich in das Kontextmenü gelegt. Funktioniert das bei Dir?

espe2310 schrieb:
- der Sonnenstand bleibt bei 58 grd stehen, ich vermute mal, das Programm greift auf die innere Uhr zu.
Das kann ich Dir im Moment gar nicht sagen. Aber das Gerät hat schon eine funktionierende Uhr, oder? Dann wäre es "nur" ein Problem mit dem Zugriff darauf.
 

pfeffer

Geowizard
nein, CacheWolf greift nicht auf die Uhr zurück, die könnte ja falsch gehen. Vielmehr wird GPS-Emfpang benötigt, die Sats senden auch die UTC-Zeit. GPS-Empfang ist dafür ohnehin notwendig, weil die Sonnenrichtung vom Standpunkt auf der Erde abhängt.

Also: hattest Du Sat-Empfang?

Falls ja: stell bitte mal den NMEA-Log ein (unter Einstellungen/GPS/Log) und stell das Log hier ein. Vielleicht sendet Dein GPS die Zeitinfo nicht? - kann ich mir aber nicht vorstellen - habe das gerade nicht genau vor Augen, ob es Positionsdatensätze in NMEA gibt, die keine Uhrzeit enthalten)

zu getenv: das habe ich eingebaut, zum zu testen, ob es auf den verschiedenen Plattformen funktioniert. D.h. im Moment hat es keinerlei Funktionalität, außer dass es ins .log (nicht NMEA) schreibt, was es aus bestimmten Umgebungsvariablen gelesen hat (APPDATA, HOME). Funktioniert bei Dir trotzdem alles (insbesondere das Speichern der Präferenzen)?


Gruß,
Pfeffer.
 
OP
espe2310

espe2310

Geocacher
MiK schrieb:
Für solche Problemfälle wurde das Schließen der Bildanzeige zusätzlich in das Kontextmenü gelegt. Funktioniert das bei Dir?

Kontextmenü!!!! Das hatte ich noch nicht entdeckt. Das geht.

Meine erste Praxiserprobung war heute auch erfolgreich. Eben geloggt :)

Danke
Ernst
 
OP
espe2310

espe2310

Geocacher
pfeffer schrieb:
nein, CacheWolf greift nicht auf die Uhr zurück

Hallo Pfeffer,

danke für Deine schnelle und ausführliche Antwort.
Mit GPS eingeschaltet bleibt der Sonnenzeiger hängen. Jetzt auf 60 grd. Ein NMEA Log habe ich nicht hingekriegt, aber ganz klar werden Zeitdaten übertragen.
$GPGGA HHMMSS.000, ....
$GPRMS HHMMSS.000, ....
Das pendelt sich ganz schnell auf ganze Sekunden und damit .000 ein.

Nachdem ich dank MiK jetzt auch das Kontexmenü kenne :) ist mir die Mondstellung aufgefallen. Aber die ist doch ohne Datum nicht zu berechnen, oder? Kann es daran hapern? Alles andere läuft offenbar problemlos auch auf dem kastrierten Win CE (ausser dem Versionscheck - RC1).

RC2 kann ich nicht zum Starten bewegen. Nach der Fehlermeldung bezüglich getenv geht nichts mehr. Ich bin daher wieder zurück auf RC1.

Insgesamt lässt sich Cachewolf auch auf dem Navi gut bedienen. Bei mir ist Auto-Hide für die Win Startleiste abgeschaltet und ich drehe den Bildschirm. Damit kommt die Schriftgröße im Kompass auch auf lesbare Bereiche, obwohl es noch einen Tick größer sein könnte. Im Vergleich zu Glopus scheint der Kompass auch etwas träger (Sekundentakt?) zu sein, aber das ist sicher Gewohnheitssache. Dafür gibt es viele viele andere schöne Sachen. Und vermutlich noch einige von mir nicht entdeckte :)

Gruß
Ernst
 

pfeffer

Geowizard
Sonnenrichtgung geht auch nicht ohne Datum. Es wird auch in irgendeinem NMEA-Datensatz übertragen.

Wenn Du RC2 verwenden willst, dann starte es mal über eine Verknüpfung, bei der Du als Parameter "-C /<verz>", wobei <verz> durch den Pfad zu CacheWolf auf dem PNA zu ersetzen ist. Dann wird getenv nämlich nicht aufgerufen :)

Und bitte versuch das noch mit dem NMEA-log. Was hat denn dabei nicht geklappt?
EDIT: habe grad mal nachgeschaut: CacheWolf liest das Datum aus dem letzten String in $GPRMC

Gruß,
Pfeffer.
 
OP
espe2310

espe2310

Geocacher
pfeffer schrieb:
Wenn Du RC2 verwenden willst, dann starte es mal über eine Verknüpfung, bei der Du als Parameter "-C /<verz>", wobei <verz> durch den Pfad zu CacheWolf auf dem PNA zu ersetzen ist. Dann wird getenv nämlich nicht aufgerufen :)

Hallo Pfeffer,

so funktioniert der RC2. Danke. <verz> muss aber auch am Ende einen \ haben.

Hier mal 3 NMEA Zeilen (ein log-file finde ich nirgendwo...)
$GPGGA,132625.408,5036.4443,N,00644.6389,E,1,04,2.1,330.0,M,47.7,M,,0000*57
$GPRMC,132625.408,A,5036.4443,N,00644.6389,E,0.31,220.53,160608,,*06
$GPVTG,220.53,T,,M,0.31,N,0.6,K*62
Der RMC Satz sieht eigentlich vollständig aus....

Zur Zeit wir Sonne mit 63 deg und Mond mit 90 deg angezeigt.

Gruß
Ernst
 

rheinkraxler

Geocacher
Hallo Leute,
ich denke der rc2-getenv bug wurde in rev. 1481 eingeführt. Dort wurde die Einstellung der config-Datei verändert:

Code:
--- trunk/src/CacheWolf/Preferences.java	2008-05-24 19:58:49 UTC (rev 1480)
+++ trunk/src/CacheWolf/Preferences.java	2008-05-28 21:18:40 UTC (rev 1481)
@@ -36,6 +36,38 @@
 	}
 
 	private static Preferences _reference;
+	
+	private String pathToConfigFile;
+	
+	/**
+	 * Call this method to set the path of the config file <br>
+	 * If you call it with null it defaults to [program-dir]/pref.xml
+	 * if p is a directory "pref.xml" will automatically appended
+	 * @param p
+	 */
+	public void setPathToConfigFile(String p) {
+		String p_;
+		if (p == null) {
+			String test;
+			test = Vm.getenv("APPDATA", "/"); // returns in java-vm on win xp: c:\<dokumente und Einstellungen>\<username>\<application data>
+			log("Vm.getenv(APPDATA: " + test); // this works also in win32.exe (ewe-vm on win xp)
+			test = Vm.getenv("HOME", "/"); // This should return on *nix system the home dir
+			log("Vm.getenv(HOME: " + test);
+			test = System.getProperty("user.dir"); // return in java-vm on win xp: <working dir> or maybe <program dir> 
+			log("System.getProperty(user.dir: " + test); // in win32.exe -> null
+			test = System.getProperty("user.home"); // in MS-java-VM env variable $HOME is ignored and always <windir>\java returned, see http://support.microsoft.com/kb/177181/en-us/

Das Problem dabei ist: unter wince gibt es keine getenv-Funktion. Es sollten daher eigentlich alle WinCE-Geräre betroffen sein (ich hab ein PDA mit vollst. WinCE und ein PNA/Navi getestet) Man könnte so was zwar nachrüsten, aber wozu?

Da mir der tiefere Sinn der extrem "verkomplizierten" Pfadbeschaffung auch verschlossen bleibt, plädiere ich für die einfachste Lösung: die config-Daten liegen immer im Programmverzeichnis, meinetwegen im Unterverzeichnis .\config.
Grüße Rheinkraxler
 

MiK

Geoguru
rheinkraxler schrieb:
Da mir der tiefere Sinn der extrem "verkomplizierten" Pfadbeschaffung auch verschlossen bleibt, plädiere ich für die einfachste Lösung: die config-Daten liegen immer im Programmverzeichnis, meinetwegen im Unterverzeichnis .\config.
Es ging gerade darum, dass die Konfig nicht mehr im Programmverzeichnis liegen muss. Im Moment sind die getenv Abfragen noch sinnlos und als Alternative zum Programmverzeichnis steht nur die direkte Angabe per Commandline zur Verfügung. In Zukunft soll aber durchaus automatisch im Homeverzeichnis per Umgebungsvariable gesucht werden.

Das Auskommentieren dieser Zeilen würde ich sogar ohne weiteren RC für die 1.0 verantworten, aber früher oder später wird darauf zurückgegriffen werden. Deswegen wäre es bestimmt sinnvoll, wenn es in Deiner WinCE-Version einen Workaround dafür geben würde.
 

rheinkraxler

Geocacher
Hallo MiK,
na gut, hab die Diskussion dazu nicht verfolgt. Aber ich würde eine komplette Änderung des Codes vorziehen. Wenn schon so viele Fälle unterschieden werden, dann doch gleich getrennt nach Systemen. ewe ist m.E. nicht gerade der perfekte Ort für diesen Patch, falls es jedoch in "normalen" java-Versionen eine entsprechende Funktion gibt baue ich was ein.
Anderer Vorschlag: exception handling. Wenn cw die exception von ewe korrekt abfängt, sollte es möglich sein, geeignete default-Werte quasi automatisch zu generieren.
Wie auch immer, ich hab mir heute mal den Quelltext geladen. Hab zwar keine Zeit tiefer einzusteigen, aber vielleicht reicht es ja für bessere Kommentare ;)
rheinkraxler
 
OP
espe2310

espe2310

Geocacher
MiK schrieb:
Das Auskommentieren dieser Zeilen würde ich sogar ohne weiteren RC für die 1.0 verantworten, aber früher oder später wird darauf zurückgegriffen werden. Deswegen wäre es bestimmt sinnvoll, wenn es in Deiner WinCE-Version einen Workaround dafür geben würde.

Mir persönlich reicht der vorhandene Workaround: Startparameter -C
Der sollte dann aber drin bleiben.

Gruß
Ernst
 

MiK

Geoguru
In der allerneuesten Version r1522 sind die getenv draußen. Die sollte eigentlich wieder gehen. Wenn ich noch eine Kleinigkeit mit Pfeffer geklärt habe, kommt dann daraus das Release.
 

pfeffer

Geowizard
habe die Sonnenstands-Problematik abgetrennt, findet sich jetz hier: http://www.geoclub.de/viewtopic.php?f=40&t=27532

Gruß,
Pfeffer.
 
Oben