[uBasic] Zahlengröße / Endif-Problematik

[gehtnix]

Hallo,

gibt es irgendwelche Beschränkungen in uBasic mit Zahlengrößen? Habe da keinerlei Hinweise gefunden.
In unterem Beispiel stürtzt mir das Script mit einer Null mehr im Divisor ab.

Code: Alles auswählen

@title Test
@param i Sekunden
@default i 7920

i=i*10
print "i*10 =",i
i=i*1000
print "i*1000 =",i

C=i
print "C = ",C
sleep 2000

rem - aber nicht 3600000 - hier eine Null zu wenig
D=C/360000

print "D = ",D

end


Bin dankbar über nützliche Info zu dem Thema,

gruß gehtnix

[CHDKLover]

Hallo gehtnix,
hab mich gerade mit deinem Problem beschäftigt und bin zu folgendem Ergebnis gekommen:
Der uBasic Interpreter erkennt "nur" Zahlen die maximal 6 Ziffern haben. (Ist so eingestellt und würde sich auch verändern lassen, nur ist der Sinn fraglich).
Deshalb kannst du einfach folgenden Trick anwenden:
Um 3.600.000 Darstellen zu können beschreibst du es einfach mit 360.000*10 und schon sind alle Zahlen <=6 Stellen und keiner wird was daran auszusetzen haben.
Als Hinweis die größte Zahl die momentan per uBasic Script darstellbar ist 2.147.483.648 (2^32=4.294.967.296, aber noch durch 2 da es positive und negative Zahlen gibt)

CHDKLover

[gehtnix]

Hallo CHDKLover,

Danke für die Rückmeldung. Mit Deinem Tip kann man schon arbeiten.
Aber es ist Gut zu wissen, dass es so ist wie es ist.

gruß gehtnix

[gehtnix]

Hallo,

ich habe noch ein Problem an dem ich schon lange rumknobel.

Das H=1205 sind Sekunden die in Stunden (D) umgerechnet werden
Dann wird geprüft ob D größer 8 ist und dann sollte eine Meldung ausgegeben werden.
Das tut es auch wenn H=51205 also 14 Stunden oder eben größer 8 Stunden ist.
Wenn kleiner 8 Std. stürzt das Script mit"Parse err" ab.
So geht es "if D<8 then goto "sprung4"". Also der D-Wert ist korrekt.
Wieso, keine Ahnung!

Code: Alles auswählen

@title Test2
@param r USB-Taster 0=aus 1=ein
@default r 0

rem --- Werte für Taster
O=60
Y=30

H=1205

rem --- Wartezeit größer 8 Std.
I=H
gosub "stunde"

rem if D<8 then goto "sprung4"
if D>8 then
   cls
   print "************************"
   print "*      ACHTUNG !       *"
   print "*  Wartezeit > ",D," Std. *"
  if r=0 then print "*  >>>      =   Weiter *" else print "*  Lang      =    Weiter *"
  if r=0 then print "*  Set      =     Stop *" else print "*  Länger    =      Stop *"
   P=80
   if P<O and P>Y then goto "sprung4"
   if P>O or P<Y then
      cls
      end
   endif
endif

:sprung4
print "fertig"
end

:stunde
 B=I
 C=B/60
 D=C/60
 E=C-(D*60)
 F=B-(C*60)
 if F>25 then E=E+1
 return



gruß gehtnix

[CHDKLover]

Hallo gehtnix,
du hast recht es ist schon etwas merkwürdig das der Interpreter das Script nicht vollständig akzeptiert. Der Fehler scheint dann aufzutreten wenn mehrere verschachtelte Verzeigungen (if) auftreten, die nicht mit endif abgeschlossen werden.
So geht es erstmal:

Code: Alles auswählen

@title Test2
@param r USB-Taster 0=aus 1=ein
@default r 0

rem --- Werte für Taster
O=60
Y=30

H=1205

rem --- Wartezeit größer 8 Std.
I=H
gosub "stunde"

if D>8 then
   cls
   print "************************"
   print "*      ACHTUNG !       *"
   print "*  Wartezeit > ",D," Std. *"
   if r=0 then print "*  >>>      =   Weiter *" else print "*  Lang      =    Weiter *" endif
   if r=0 then print "*  Set      =     Stop *" else print "*  Länger    =      Stop *" endif
   P=80
   if P<O and P>Y then goto "sprung4" endif
   if P>O or P<Y then
      cls
      end
   endif
else
  goto "sprung4"
endif

:sprung4
  print "fertig"
end

:stunde
  B=I
  C=B/60
  D=C/60
  E=C-(D*60)
  F=B-(C*60)
  if F>25 then E=E+1
return

Das letzte if (if F>25 then E=E+1) braucht z.b. kein endif, da es nicht in einer Verschachtelten if Block steht.
Ich kann ja mal sehen ob ich das Problem irgendwie lösen kann.

CHDKLover

[gehtnix]

Hallo CHDKLover,

das ist ja eine"merkwürdige" Lösung, Danke.

Ich hatte noch eine Seltsamkeit die ich aber nicht mehr genau nachvollziehen kann. In einer ähnlich Kombination sollte er die Abfrage überspringen, blieb dann aber innerhalb der "if"-Abfrage an dem "end" hängen und beendete.
Alles zwischen "if" und "end" wurden richtigerweise ignoriert.

Sollte ich nochmals darauf stossen gibt es mehr dazu.

gruß gehtnix

[gehtnix]

Hallo CHDKLover,

habe Deinen endif-Rat befolgt, der auch in dem Test-bas lief.
Nur im gesamten Programm schaut es dann anders aus.
Es funktioniert wenn man ohne USB-Taster arbeitet!?
Mit USB-Taster wird aber beendet, mit der untenstehenden Meldung!?

"* Lang = Weiter *" - das ist OK aber die 1 und 0, weiß nicht woher die kommen!

Meldung auf TFT
--------------------------------------
* Lang = Weiter *1
0
Beendet

141 Parse err
--------------------------------------

Script anbei.
Gelöst habe ich das im Script dann mit einer anderen Abfrage (sprung), ohne endif

Anmerkung für Ladewillige - DAS SCRIPT HAT FEHLER !


Und noch eine Frage zu Case. Ist das zweimalige Case 1, siehe unten zulässig?

Code: Alles auswählen

select Z
   case 1; print "1"
   case 1; gosub "test2"
   case 2; print "2"
   case 2; gosub "test2"
end_select

Ich hatte das bereits im Script stehen und war der Meinung das es lief, unter Build juciphox ???
Jetzt, mit dem 479er geht es nicht mehr.
Daher die Frage ist das überhaupt erlaubt?

gruß gehtnix

[rudi]

Hallo gehtnix,
das ist hier schon eine weile alt, doch ich möchte deine Frage der Ordnung halber beantworten.

Leider funktioniert diese Konstruktion nicht. Wurde ein CASE ausgeführt, dann wird ein CASE_RUN-Fag gesetzt. Damit wird kein CASE und auch kein CASE_ELSE mehr ausgeführt.
Du hast recht, anfänglich funktionierte diese Variante noch. Seit dem Patch für die von dir gefunde REM-Problematik zwischen den CASE-Zeilen hat sich CHDKLover gegen diese Möglichkeit entschieden - und für die Abarbeitungsgeschwindigkeit.

Gruß Rudi

[gehtnix]

Hi Rudi,

so alt Kamellen, auf den Tag genau 13 Monate, gräbst Du jetzt aus. Ist aber schon Wüst was ich da so im Skript geschrieben habe.

Mit Deiner fachlichen Spürnase wärst Du doch bei setepontos bestens aufgehoben. Im Bugtracker hättest Du eine große Spielwiese.

Nur mal so (mit Absicht) für mich so dahingedacht........

gruß gehtnix