Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[DiskJuggler]

I've tried and put Set Buffer 210 in. So this would be 10k more. The compiled program still exits with an illegal call, probably because one variable is trashed or zero.

Is there a way to re-set all internal structures etc. of AMOS at runtime? Could it be a stack issue? I do not use any fancy recursion stuff. Or, another idea, is there a limit on the number of arguments for a procedure?

[DiskJuggler]

I think i found it. I made a booboo!
I was just searching through all arguments i use in procedures and it seems i had used one or two beeing declared GLOBAL despite not needed to be really GLOBALs, SHARED in some Procs would have been enough.

So, i keep on testing. Sorry to bother you with a non-bug.

[SamuraiCrow]

@DiskJuggler

I'm glad you found the culprit.

[DiskJuggler]

Thank you.

Is the "STR$() adds a Space" already tackled? It seems to be common as i stumble upon workarounds on this all the time.

[SamuraiCrow]

Thank you.

Is the "STR$() adds a Space" already tackled? It seems to be common as i stumble upon workarounds on this all the time.

It's the sign character.  That's why there is a space.  Negative numbers have no space because it's occupied by the minus.

[LuisCoCo]

* Recently I found an error in Amos, I do not know if it is documented.
Using DirFirst and DirNext with file that have 2 times point, like for example File.00001.IFF, a search of * .IFF fails, because it searches from left to right.

In FSel$ too

On the other hand, in AmigaDos the same DirFirst command does it correctly.

[SamuraiCrow]

Replied on the BitBucket bug report.

[DarkN3mo]

Thank you.

Is the "STR$() adds a Space" already tackled? It seems to be common as i stumble upon workarounds on this all the time.

yes i just discover this bug !   damn !