BUG LIST for BASEC v0.20 --------------------------------------------------------------------------- Contact author: William Yu BASEC homepage: http://www.basicguru.com/abc/basec.html There are some bugs which are actually design decisions, but you should be aware of what they are anyway (they're denoted with '+'). Some design decisions were carried over from my previous version 0.02 All other versions were a partial rewrite of the older compiler. To patch some of these bugs would require another partial rewrite. Some known bugs (denoted '*'), these are the most noticeable: * Expressions need to be of the SAME TYPE for the ENTIRE expression: Example: IF i>0 AND a$="huh?" THEN ?"whatever" END IF Need to be separated to: IF i>0 THEN IF a$="huh?" THEN ?"whatever" END IF This is a major flaw that I overlooked. * Undeclared string variables... Although I can't quite explain it, there are such events when an undeclared string variable may cause problems, especially when reading from input (inkey$, input$, get$). Try TICTAC.BAS but remove the key$="" on line 13. In other cases it poses no problems at all. + BASEC doesn't recognize the NULL character, ie. chr$(0) So when you use INKEY$ to read extended keys, like upArrow, it won't return the NULL character. Although considered a flaw, I never intended to support the NULL character, just to make life easier... Okay fine, it's a flaw ;-) * IF THEN ... ELSE ... At the moment, ELSE cannot be on the same line + RND(n) If you choose to use the RND function without the n argument, the random number will be returned to 5 decimal places (.12345) unlike the 7 for QB/PB. This is a design decision, I could extend this to 10 or more decimal places, but it would eat up CPU time. I think 5 is good enough. * No fixed string array At the moment all string arrays are fixed to 255 characters... This is not really a bug, just a laziness on my part. + TIMER bug? This is not really a bug, but I have no idea where QB/PB gets their TIMER value from... BASEC's TIMER begins at 0 everytime the program starts. + PRINT does not accept commas as a formatting statement All numbers are printed as is, with no formatting, or extra spacing. These aren't flaws, just design decisions. For compatibility reasons, the comma has the same functionality as using the semi-colon. + EXTENDED data type is there for PB compatibility reasons, it has the same functionality as DOUBLE, but eats up 10 bytes nonetheless. So if you had GET #1,,Extended## It would read 10 bytes. + STEP can only take one argument (numeric variable or a number) Example: FOR I = 1 to 100 STEP 52 MOD 50 ' only takes the 52 n = 52 MOD 50 ' use this instead FOR I = 1 to 100 STEP n This is a design issue from my previous version that I'm too lazy to resolve. If it's a variable, it cannot be an array. + INPUT a$ For the time being, INPUT will have the same functionality as LINE INPUT. That means INPUT will only take one return value, and commas will not be excluded from the string. Again, this is due to my laziness.