For()
.Loopy stuff
EndIf condition
doesn't work.

I don't know if it was already reported so I report it.
I'm using a TI-84+SE and my friend is using a TI-83+, both of us have Axe 0.5.3.
When we do "Output(0,Y,K>Dec" with 0<Y<7 and 0<K<200, it displays the K in the wrong column.
When K<10, it displays it in the fifth column. When 9<K<100, it displays it in the fourth column, etc.
I wanted to make a gif with Wabbitemu but everything is normal with Wabbitemu I made a mistake somewhere.
I thought it was the fault of my calc, that's why I tries GarbageCollecting and RamClear, but the bug persisted. So I tried with my friend's calc but there was the same bug.
(At least, when I say "Output(0,etc", it writes in 5 and when I say "Output(1,etc", it writes in 6).
Has anyone else got that bug ?

Good to know. Thank you (You got a +1).
Hey, I'm a living ERR:Syntax ! I said that the "bug" wasn't in Wabbitemu but it is (fortunately).
I don't know what I typed to make it display the 0 in the first column (maybe this ").
What a noob I am.

Quote from: Hot_Dog on June 06, 2011, 11:02:46 pm

This is a weird one...but if bit 1 of (IY + appFlags) is not set, sometimes text drawn with Output( or Disp( will disappear when the program calls for user input (keyword Input).  My guess is Output( and Disp( do not automatically update TextShadow, and B_CALL($4E5E) will only show what was stored into the text buffer.

I think Quigibo could add a "set 1, (IY + appFlags)" at the start of the input routine to fix it.   Thanks for the bug report!

Couldn't hurt.  It's interesting, though, I'm almost sure that B_CALL($4E53) sets it automatically after it gets input

Hmm, I was just thinking about this, and Hot Dog, is there any chance you were on a Math Print OS?

No chance.  This was a Ti-83+.

Oh yeah, I forgot to mention that!  Bit 3 controls if auto backups should be turned on or not when using the CompileOP1 entry point.  Axe always saves the current setting configuration when it exits so if you want it to restore the original settings, you'd have to read and then modify the Axe appvar, which contains a single byte: the setting.  Maybe I'll change that for 1.0.0 though since I see how that can be annoying.

I tried to do a Copy( with a {Y1+offset} in the length argument. Axe compiled it, but the program instantly crashed, regardless of where the statement was. In general, Axe doesn't like nesting {} and doesn't always give an error.

Edit: Hmm, now I can't duplicate the Copy( crashing.

Here's the fragment of code I was writing when I came across the problem. It works fine now, by the way. It does some pretty evil things. Points to anybody who can identify what it's doing. Y1 is supplied as an argument.
Data(24,7,8,8,8,5,5,8,8,0,0,0,2,4,7,0,0,0,0,0,0,0,5,0,1)->Str2
.
.
.
If (Y1+1)r>Asm(EFE542)
 Disp Str4
 Goto UDE
End
0->{$8478}
Fill($8478,0)
{Y1+3}->A
A->{$8478}
!If {A+Str2) and 4
 If {A+Str2} and 8
  Goto UDT
 End
 Disp "Not supported.",i
 Goto UDE
End
Copy(Y1+10,$8479,{Y1+9})
If Asm(EFF14221000038012C)
 Disp Str3
 Goto UDE
End
{Y1+9}->C
{Y1+C+10}r->A
{Y1+3}->B
C+10->D
If {B+Str2} and 2
 A*8+A->A
 $31->{C+$8478}
End
If B=13
 A*2->A
End
$15->{$8478}
AAsm(EF6A4EED53E28922E089)
{Y1+3}->{V}
Copy(Y1+D,W,A+2)
If {B+Str2} and 2
 0->{V-C-6}
End