Qbasicnews.com

i'm opening a file for binary, and i've been having troubles for a few days. I think i'm a step closer, and i'm wondering if this is maybe a compiler bug instead of a problem with my own code.

Basically, my code works fine up to here:

Code:
FOR y = 1 TO activetilesets

GET #filenum,, til

GET #filenum,, templength

tileset(til) = SPACE$(templength)

GET #filenum,, tileset(til)

numsets(til) = 1

NEXT

til is supposed to return the tileset label, templength the length of the name of the tileset. However, it seems that templength doesn't seem to return the right number... instead of 7, it returns 1, or 0 probably, since it won't be printed. I thought it might be a faulty map, but after i replaced it with a new one, it still had troubles. I thoroughly tested it on qb, and it works perfectly, and so it should work thereotically with fb as well, after i change all the variables to short. thereotically. I and several other people looked at the code, and we all agree that there's nothing wrong with it.

To see what kind of problem is being produced in the first place, please go to my map loader problems thread a few stories down. here's a link...

http://forum.qbasicnews.com/viewtopic.php?t=9021

plus here is alot more information on the problem, including several more things i found but i'm too tired to type up... it's 2:30 here...

thanks in advance.

*sigh*

This should either go in very large print in a readme file or in a FAQ or something...

Reading a string of length 'n' will read 'n + 1' bytes from a file when used with GET #.

just solved the problem, it was my fault. When i first created the tileset array, i did this:

dim shared tileset(4) as string * 1

this is what did it. No amount of spacing could of fixed it. thanks DrV anyways though!

barok

DrV

barok