onTimeChanged bekommt falsche Werte

  • Antworten:7
p a
  • Forum-Beiträge: 131

08.02.2012, 14:54:05 via Website

Hallo,

ich bin gerade dabei mir einen eigenen TimePickerDialog zu schreiben, hab hier allerdings das Problem dass er beim Minuten einstellen immer wieder in eine Endlosschleife läuft und dann natürlich mit einem "StackOverflow" aussteigt

Hier ist mal der Code (in html gepackt und preformatiert):
http://dl.dropbox.com/u/55496033/TimePicker.html

Anscheinend wird der onTimeChanged immer wieder eine falsche Zahl übergeben, obwohl ich den Parameter eigentlich explizit auf eine 0 bzw. eine 30 setze wodurch eigentlich die Rekursion enden sollte.
Er bekommt halt immer wieder eine 1 bzw. 31 übergeben, wodurch er halt immer wieder durch den Default läuft und sich dann immer wieder selbst aufruft.
Plan wäre halt dass er z.B. mit 42 in minuteOfHour anfängt, dann wird 0 in this.minute geschrieben und beim Wiederaufruf wird this.minute als Parameter übergeben. Dann ist beim nächsten Durchlauf minuteOfHour 0, er setzt es wieder in this.minute ein und das war's.

Hat jemand eine Idee was ich da falsch mache???

— geändert am 08.02.2012, 14:58:26

Antworten
Felix
  • Forum-Beiträge: 259

08.02.2012, 20:40:58 via Website

Tach!

Anscheinend wird der onTimeChanged immer wieder eine falsche Zahl übergeben, obwohl ich den Parameter eigentlich explizit auf eine 0 bzw. eine 30 setze wodurch eigentlich die Rekursion enden sollte.

Du musst schon genauer und nachvollziehbarer beschreiben, wenn du eine genaue Antwort haben möchtest. Wenn ich raten soll, meinst du den Parameter minuteOfHour und übergibst ihn über zeitÄndern(). Allerdings nimmst du dort die Werte aus einer Eigenschaft. Und von der kann niemand wissen, was sie enthält, außer dem, der sich die Sache mit einem Debugger anschaut.

Apropos Debugger, du würdest dir das Leben einfacher machen, wenn du dir statt tausend und einem Log.v()-Aufruf die Sache mit dem Debugger anschauen würdest. Setz dir Breakpoints an strategisch wichtige Stellen (mindestens da wo der fragliche Wert erzeugt wird) und verfolge seine Änderungen beim schrittweisen Abarbeiten des Codes.


Felix.

Antworten
p a
  • Forum-Beiträge: 131

09.02.2012, 09:24:16 via Website

Was der Debugger mir verrät verrät das Log mir auch und beim Loggen sitze ich nicht 15 Minuten da und klick mich durch die Einzelschritte.
Ich bin auch schon mit dem Debugger dadurch, aber wirklich neue Erkenntnisse brachte dass auch nicht, es wird halt einfach der falsche Wert im ZeitÄndern() übergeben, sowohl an onTimeChanged als auch an updateTime und ich blicke halt nicht durch woher der Wert kommt.
Vorallem gehe ich bei Stunden und beim DatePickerDialog mit der gleichen Logik daran und da funktioniert alles anstandslos.

— geändert am 09.02.2012, 09:25:42

Antworten
Rafael K.
  • Forum-Beiträge: 2.359

09.02.2012, 09:39:46 via Website

Genau das ist doch das gute am Debugger.
Du hast die ganze Zeit die Werte von this.minute im Auge und kannst beobachten wann die sich auf unvorhergesehen Werte ändern.
Dann gibt es nämlich ein gelbes Highlight.

Ich habe schon vergessen, wann ich das letzte mal mit Log Ausgaben debuggt habe.
Auf irgendeinem Uralt-Server meine ich, wo man sich nicht per Remote-Debugger hinverbinden konnte :D

Antworten
p a
  • Forum-Beiträge: 131

09.02.2012, 09:43:13 via Website

Wie gesagt, ich bin auch schon mit dem Debugger durchgelaufen, der hat die ganze Zeit den richtigen Wert drin, bis zum Neuaufruf der Funktion, da steht dann plötzlich wieder der falsche drin.

Antworten
Rafael K.
  • Forum-Beiträge: 2.359

09.02.2012, 09:55:17 via Website

p a
Wie gesagt, ich bin auch schon mit dem Debugger durchgelaufen, der hat die ganze Zeit den richtigen Wert drin, bis zum Neuaufruf der Funktion, da steht dann plötzlich wieder der falsche drin.
Also in meiner Anfangszeit habe ich auch öfter versucht der JVM Fehler zu unterstellen, aber die funktioniert leider verdammt gut und auch deterministisch, wenn man keine Threads verwendet. Am Ende lag der Fehler immer in meiner Programmierung :D

Guck dir doch mal den Aufruf-Stack an, wenn der falsche Wert drinsteht.
Vielleicht ist der Aufruf garnicht Teil deiner Rekursion, sondern ein Systemaufruf (ich nehme an onTimeChanged ist eine überschriebene Methode).

Noch generell:
Ich würde sowas einfaches nicht mit einer Rekursion lösen, Rekursion ist idR. teurer als iteratives Vorgehen.
und auf garkeinen Fall würde ich callBackMethoden der Superklasse (die auch noch super. Aufrufe enthalten) als Rekursionsmethode verwenden.
Das sind Methoden, die auch vom System verwendet werden und die potenziell in mehreren Threads aufgerufen werden, was zu beliebigen Seiteneffekten führen kann.

Antworten
Felix
  • Forum-Beiträge: 259

09.02.2012, 11:19:09 via Website

Tach!

p a
Was der Debugger mir verrät verrät das Log mir auch und beim Loggen sitze ich nicht 15 Minuten da und klick mich durch die Einzelschritte.

Jeder wie er mag. Mir wäre es zu aufwendig, die Log-Ausgaben einzufügen und hinterher wieder zu entfernen. Außerdem finde ich es einfacher, die markierte Programmzeile vor Augen zu haben, als Log-Ausgaben individuell zu gestalten um sie dann manuell zur Code-Stelle zuordnen zu können und müssen. Und am Ende muss der ganze Mist auch wieder raus.

Ich bin auch schon mit dem Debugger dadurch, aber wirklich neue Erkenntnisse brachte dass auch nicht, es wird halt einfach der falsche Wert im ZeitÄndern() übergeben, sowohl an onTimeChanged als auch an updateTime und ich blicke halt nicht durch woher der Wert kommt.

Du musst doch wissen, von woher bestimmte Programmteile aufgerufen werden. Selbst wenn es nicht dein Code ist, ist es wichtig, sowas zu wissen. Wenn also irgendwo ein Wert falsch ankommt, musst du weiter zurückgehen. Er wird ja irgendwo erzeugt. Beim Debugger hilft dir, wie schon erwähnt, der Aufruf-Stack, wenn du dir nicht sicher bist, wer wen aufruft.


Felix.

Antworten
ramon opp
  • Forum-Beiträge: 1

12.02.2012, 17:12:46 via App

Codes

Antworten