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

RC1 Fehlerthread

maierkurt

Geowizard
MiK schrieb:
pfeffer schrieb:
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.
treten diese beiden Phänomene mit der ungepatchten Version nicht auf?

Ich habe jetzt noch ein bisschen getestet. Ohne diesen Patch aber ansonstem aktuellem SVN-Stand, habe ich beide Phänomene nicht. Irgendwie bringt diese Pfadangabe den PDA aus dem Tritt. Die Auswahl von root anstatt dem aktuellen Verzeichnis ist ja auch schon falsch.
Nur damit ich es jetzt richtig verstanden habe: Der Patch von Pfeffer diente nur dazu, Probleme bei der Profilpfadangabe zu umgehen, wenn der Pfad in der pref.xml nicht stimmt?

Ich habe auf dem PC und dem PDA (WM 6, ARM-Version) jeweils mit und ohne Patch getestet: CW schlägt immer das Cachewolfverzeichnis vor. Auch beendet das Programm bei klick auf cancel korrekt.


Gruß, maierkurt
 

greiol

Geoguru
Version: Windows
Vorgang: GPX PQ Import
Beobachtetes Verhalten: Das Fenster "Geladene Caches" enthält bis zum Ende des Imports den Text "Geladene Caches. 0" anschliessend werden aber brav alle Caches in der Liste angezeigt. Sollte da nicht eigentlich hoch-/mitgezählt werden?
 

MiK

Geoguru
greiol schrieb:
Vorgang: GPX PQ Import
Beobachtetes Verhalten: Das Fenster "Geladene Caches" enthält bis zum Ende des Imports den Text "Geladene Caches. 0" anschliessend werden aber brav alle Caches in der Liste angezeigt. Sollte da nicht eigentlich hoch-/mitgezählt werden?
Ich habe keine Ahnung, wie der GPX-Import funktioniert, aber ich kann vom Code her bestätigen, dass da niemals etwas anderes als 0 stehen kann...
 

pfeffer

Geowizard
greiol schrieb:
Version: Windows
Vorgang: GPX PQ Import
Beobachtetes Verhalten: Das Fenster "Geladene Caches" enthält bis zum Ende des Imports den Text "Geladene Caches. 0" anschliessend werden aber brav alle Caches in der Liste angezeigt. Sollte da nicht eigentlich hoch-/mitgezählt werden?
Manchmal wundert man sich als Programmierer doch, warum dieser Fehler nicht schon lange gemeldet wurde - scheint wohl eine nicht allzu oft genutzte Funktion zu sein...

Patch anbei, @ DEV: bitte begutachten

Gruß,
Pfeffer.
 

Anhänge

  • gpx-import-show-numbers.zip
    958 Bytes · Aufrufe: 6

MiK

Geoguru
Vom Code her sieht es gut aus. (allerdings ist eine alte preferences.java mit in den Patch gerutscht, die damit nichts zu tun hat.) Ich konnte es aber mangels GC-GPX nicht selbst testen.

Noch etwas ist mir aufgefallen: Du hast die ersten beiden Stellen, an denen String 4000 genutzt wird nicht an den neuen String angepasst.
 

2cachefix

Geomaster
pfeffer schrieb:
greiol schrieb:
Version: Windows
Vorgang: GPX PQ Import
Beobachtetes Verhalten: Das Fenster "Geladene Caches" enthält bis zum Ende des Imports den Text "Geladene Caches. 0" anschliessend werden aber brav alle Caches in der Liste angezeigt. Sollte da nicht eigentlich hoch-/mitgezählt werden?
Manchmal wundert man sich als Programmierer doch, warum dieser Fehler nicht schon lange gemeldet wurde - scheint wohl eine nicht allzu oft genutzte Funktion zu sein...

Patch anbei, @ DEV: bitte begutachten

Gruß,
Pfeffer.

Das hat es wohl noch nie richtig getan. Siehe hier http://www.geoclub.de/viewtopic.php?f=40&t=12354&st=0&sk=t&sd=a&hilit=z%C3%A4hler&start=10
Ich habe es aber wohl versäumt das als Bug zu deklarieren.
 

Kappler

Geowizard
Folgendes Szenario:
CW wird gestartet, das letzte Profil automatisch geladen.
Jetzt wird weder diekt der Cachewolf beendet.

Nun 2 Möglichkeiten:
- im Profil war kein Filter aktiv => beenden und gut ist (was man ja auch so erwarten würde)
- Ein Filter war aktiv und wird automatisch beim Laden wieder angewandt => beim Beenden wird erst mal das Profil gespeichert (was besonders bei größeren Profilen auf dem PDA nervt)

Ursache (in MainForm.java):
Code:
public void doIt(){
...
	profile.readIndex();
	pref.curCentrePt.set(profile.centre);
	profile.updateBearingDistance();
	profile.restoreFilter();
	//profile.hasUnsavedChanges=false;
	setTitle("Cachewolf "+Version.getRelease()+" - "+profile.name);
...
Dadurch, dass die Zeile
Code:
profile.hasUnsavedChanges=false;
rauskommentiert ist, wird das Profil durch restoreFilter() als geändert markiert und entsprechend und konsequent später gespeichert.

Hat diese Rauskommentierung einen tieferen Sinn? (irgendwann muss sich wohl mal jemand was dabei gedacht haben...)
 

MiK

Geoguru
Das ist relativ neu. Ein Patch von Pfeffer, den ich für ihn commitet habe mit r1406. War wohl zu spät...

Diesen Commit sollte sich Pfeffer noch einmal anschauen. Vielleicht sind in den Patch ein paar Zeilen gerutscht, di da überhaupt nicht dazu gehören.
 

pfeffer

Geowizard
nein, das war Absicht und ist notwendig (glaub ich), damit nach dem Erstellen eines neuen Profils das neue Zentrum gespeichert wird. Ich habe den entsprechenden hasUnsavedChanges in die readIndex verschoben, die hasUnsavedChanges=false nur setzt, wenn sie tatsächlich die index.xml gelesen hat und es nicht ändert, wenn es keine gab.

Gruß,
Pfeffer.
 

pfeffer

Geowizard
MiK schrieb:
Vom Code her sieht es gut aus. (allerdings ist eine alte preferences.java mit in den Patch gerutscht, die damit nichts zu tun hat.) Ich konnte es aber mangels GC-GPX nicht selbst testen.

Noch etwas ist mir aufgefallen: Du hast die ersten beiden Stellen, an denen String 4000 genutzt wird nicht an den neuen String angepasst.
Mit Deinen Änderungsvorschlägen grade committet (r1413). Zusätzlich war ich so frei noch eine Meldung zu internationalisieren.

Pfeffer.
 

pfeffer

Geowizard
Kappler schrieb:
Folgendes Szenario:
CW wird gestartet, das letzte Profil automatisch geladen.
Jetzt wird weder diekt der Cachewolf beendet.

Nun 2 Möglichkeiten:
- im Profil war kein Filter aktiv => beenden und gut ist (was man ja auch so erwarten würde)
- Ein Filter war aktiv und wird automatisch beim Laden wieder angewandt => beim Beenden wird erst mal das Profil gespeichert (was besonders bei größeren Profilen auf dem PDA nervt)

Ursache (in MainForm.java):
danke für das Feststellen der genauen Ursache. Habe mit r1414 nach MiKs Review einen Patch dafür eingespielt.

Gruß,
Pfeffer.
 

lahmer

Geocacher
Zum einen würde ich gern nochmal auf meinen Bugreport vom Mi 23. Apr 2008, 23:23 aufmerksam machen (nur dass der nicht untergeht ;) )

Außerdem ist mir noch eine Kleinigkeit aufgefallen: Wenn ich einen Cache als gefunden deklariere, werden automatisch als zugehörigen Stages, Final, Parkplatz, usw als gefunden deklariert... wenn ich hingegen eine Stage als gefunden deklariere, ist nur genau dieser Eintrag als gefunden deklariert, alle weiteren zu dem Cache gehörigen Einträge sind weiterhin ohne Status...
Meiner Meinung nach ein wenig intuitives Verhalten :irre:
 

MiK

Geoguru
lahmer schrieb:
Zum einen würde ich gern nochmal auf meinen Bugreport vom Mi 23. Apr 2008, 23:23 aufmerksam machen (nur dass der nicht untergeht ;) )
Das ist dann wohl dieser: http://www.geoclub.de/viewtopic.php?p=380515#p380515

lahmer schrieb:
Außerdem ist mir noch eine Kleinigkeit aufgefallen: Wenn ich einen Cache als gefunden deklariere, werden automatisch als zugehörigen Stages, Final, Parkplatz, usw als gefunden deklariert... wenn ich hingegen eine Stage als gefunden deklariere, ist nur genau dieser Eintrag als gefunden deklariert, alle weiteren zu dem Cache gehörigen Einträge sind weiterhin ohne Status...
Meiner Meinung nach ein wenig intuitives Verhalten :irre:
Warum? Ich kann doch schon eine einzelne Stage gefunden haben, ohne dass ich den ganzen Cache schon habe. Wenn man aber den Hauptcache gefunden hat, braucht man auch die einzelnen Stationen nicht mehr suchen.
 

pfeffer

Geowizard
MiK schrieb:
lahmer schrieb:
Zum einen würde ich gern nochmal auf meinen Bugreport vom Mi 23. Apr 2008, 23:23 aufmerksam machen (nur dass der nicht untergeht ;) )
Das ist dann wohl dieser: http://www.geoclub.de/viewtopic.php?p=380515#p380515

Ich nehme an, dass das Problem gelöst wird, in dem man in "public void doFilter()" selectionChanged auf true setzt.

Gruß,
Pfeffer.
 

MiK

Geoguru
Das reicht nicht aus. z.B. beim Aufheben des Filters wird dies nicht aufgerufen. Und auch bei ein paar anderen Änderungen des Filters wird kein doFilter aufgerufen.
 

MiK

Geoguru
Ich hoffe ich habe alle Stellen erwischt und es nicht zu oft gesetzt. Bitte schaut mal drüber:
 

Anhänge

  • IconsInMap.zip
    970 Bytes · Aufrufe: 7

lahmer

Geocacher
MiK schrieb:
lahmer schrieb:
Außerdem ist mir noch eine Kleinigkeit aufgefallen: Wenn ich einen Cache als gefunden deklariere, werden automatisch als zugehörigen Stages, Final, Parkplatz, usw als gefunden deklariert... wenn ich hingegen eine Stage als gefunden deklariere, ist nur genau dieser Eintrag als gefunden deklariert, alle weiteren zu dem Cache gehörigen Einträge sind weiterhin ohne Status...
Meiner Meinung nach ein wenig intuitives Verhalten :irre:
Warum? Ich kann doch schon eine einzelne Stage gefunden haben, ohne dass ich den ganzen Cache schon habe. Wenn man aber den Hauptcache gefunden hat, braucht man auch die einzelnen Stationen nicht mehr suchen.
Hm.. ich bin zwar noch nie auf die Idee gekommen, einzelne Stages als gefunden zu deklarieren, gebe aber zu, dass das nicht allzu abwegig klingt ;)
Aufgefallen ist es mir allerdings vor allem beim Final... in dem Fall finde ich es doch ein wenig komisch, wenn ich nur den Final, nicht aber den Hauptwegpunkt als gefunden deklarieren möchte... und genau so läuft es momentan...
wäre es denn evtl. möglich, im Fall des Finals eine Ausnahme zu machen... oder denke ich einfach nur ein wenig anders als andere :???:
 
Oben