eigentlich ging es mir im beispiel darum zu zeigen, dass das aufrufen ein einzigen funktion in zweistelliger anzahl von verschiedenen stellen für eine eintize benutzeraktion es nicht einfacher macht herauszufinden was da eigentlich passiert. es muss ja nicht gleich auf eins runtergebrochen werden, aber vielleicht kommen wir mit der hälfte aus. aber dafür muss erst mal wieder der besuch aus dem haus sein.
-
Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.
[dev] Umbenennen von Wegpunkten
- Ersteller UncleOwen
- Erstellt am
zumindest 5. kann ich inzwischen (teilweise) beantworten.greiol schrieb:
der wegpunkt verschwindet in myTableModel.updateRows()
am eingang ist cacheDB.size() noch 1. aber am ende sind sortDB.size() und notVisibleDB.size() beide 0
der cache fällt raus, weil ch.mainCache != null wahr ist, was für einen addi ohne parent aber nicht der fall sein sollte.
verloren geht die info weil in DetailsPanel.saveDirtyWaypoint() bei einem wechsel zum addi Profile.setAddiRef(CacheHolder ch) aufgerufen wird und da wird die info dann scheinbar falsch gesetzt. blame weist mich dort als letzten änderer in rev 2060 aus, aber da der bug schon älter ist, muss ich mir wohl den vorherigen code auch ansehen - nach dem aufstehen.
radio eriwan. es sollte keine geben, aber wir geben dem user genug werkzeuge an die hand um welche zu erzeugen. also sollten wir auch damit umgehen können.pfeffer schrieb:
inzwischen dürfte zumindest das oben genannte problem aber gelöst sein.
entstehen könne solche punkte beim löschen (es ist möglich den hauptwegpunkt ohne die addis zu löschen) und durch eingabe im detailspanel. wir hatten auch noch lustige effekte wenn man versucht hat den addi GC1234 zum cache OC1234 anzulegen.
das zusammenspiel von profil, cachedb, hashdb, den einzelnen caches und der gui ist bestenfalls verwirrend. aber wir kriegen das schon noch hin.
pfeffer
Geowizard
sollten wir an den Stellen nicht einfach den Nutzer fragen, was mit den Addis passieren soll?
1. Hauptwegpunkt löschen: "Addis mitlöschen?"
2. Detailspanel: "Kein Hauptwegpunkt oder Addi gewählt - lege neuen Hauptwegpunkt an" Außerdem Addi disablen als Typ, wenn kein Hauptwegpunkt gewählt ist.
Noch eine Stelle?
Gruß,
Pfeffer.
1. Hauptwegpunkt löschen: "Addis mitlöschen?"
2. Detailspanel: "Kein Hauptwegpunkt oder Addi gewählt - lege neuen Hauptwegpunkt an" Außerdem Addi disablen als Typ, wenn kein Hauptwegpunkt gewählt ist.
Noch eine Stelle?
Gruß,
Pfeffer.
damit rennst du bei mir offene türen einpfeffer schrieb:
und eine ordentliche meldung sollte sicherlich am ende stehen. derzeit wird der wegpunkt als incomplete markiert und mit einer warnung in der liste dargestellt - das ist schon mal mehr als wir vorher hatten.und damit kommen wir auch so langsam an einen punkt wo wir die meldung ausgeben können. bisher hatten wir in dem bereich
- ein paar if ohne else (die sorgten für das verschwinden der punkte)
- keine garantierte syncronisierung von cachedb und hashdb (das ist immer noch so, vor allem beim umbenennen)
- ein addi GC1234 für OC1234 hat immer sich selber als "hauptcache" gefunden weil nie geprüft wurde ob der vermeintliche hauptwegpunkt der punkt selber war oder ob der hauptwegpunkt überhaupt ein hauptwegpunkt war
- und dann hatten wir noch ein paar exceptions weil a.b.c ausgegeben wurde ohne zu prüfen ob a.b nicht schon null war (entweder prüfen oder try drum herum, wobei wir ja schon festgestellt haben, dass prüfen schneller ist)
- teilweise gab es den code dann auch noch per cut & paste an drei verschiedenen stellen.
das ist bisher imho durchgehend code dem es an robustheit fehlt(e) und der exceptions bestenfalls planlos verursacht hat. das ändert sich nun nach und nach und am ende werden wir hoffentlich eine robuste lösung und eine brauchbare fehlermeldung haben.
