Data types are not a solution, because your problem is conversion...
let's say you have band=200, and you increase by 10... This is what you do ()
(you keep "pausa" stored...)
1) What is the current band? 1/pausa = 1/0.005 = 200
2) Let's add 10: band = 200+10 = 210
3) What's pausa? 1/band = 1/210 = 0.0047619047619047619047619047619048 (I don't know Gambas' precision, but let's say that it uses something like 0.004775)
4) Let's display band! What's band? (you recalculate it from pausa, this is an error) 1/pausa = 1/0.004775 = 209.424XXXX
In the end, 209 will come out of it.
The numbers in this example are not 100% what BaShare uses, but is can be a good explanation of why we see this strange behavior.
I don't understand why you perform another calculation in step 4? You already now the new band at that stage, because it is either the original Vbanda+10, or MaxBanda. If you didn't recalculate this, but just reuse the value, we wouldn't have this bug...
And even better, instead of getting the current band from "pausa", you could store it in a global (I don't like it) or read it from what you have displayed in the interface. That way, you will always calculate pausa from the REAL band that is displayed...
I haven't tested the fix you put in rev 107, but I am almost sure that this will not remove this bug. We just cannot confirm that it will not happen with bigger numbers... The solution is to change the way pausa and banda get stored/calculated/displayed.
Data types are not a solution, because your problem is conversion...
let's say you have band=200, and you increase by 10... This is what you do ()
(you keep "pausa" stored...)
1) What is the current band? 1/pausa = 1/0.005 = 200 047619047619047 619048 (I don't know Gambas' precision, but let's say that it uses something like 0.004775)
2) Let's add 10: band = 200+10 = 210
3) What's pausa? 1/band = 1/210 = 0.0047619047619
4) Let's display band! What's band? (you recalculate it from pausa, this is an error) 1/pausa = 1/0.004775 = 209.424XXXX
In the end, 209 will come out of it.
The numbers in this example are not 100% what BaShare uses, but is can be a good explanation of why we see this strange behavior.
I don't understand why you perform another calculation in step 4? You already now the new band at that stage, because it is either the original Vbanda+10, or MaxBanda. If you didn't recalculate this, but just reuse the value, we wouldn't have this bug...
And even better, instead of getting the current band from "pausa", you could store it in a global (I don't like it) or read it from what you have displayed in the interface. That way, you will always calculate pausa from the REAL band that is displayed...
I haven't tested the fix you put in rev 107, but I am almost sure that this will not remove this bug. We just cannot confirm that it will not happen with bigger numbers... The solution is to change the way pausa and banda get stored/ calculated/ displayed.