FB II Compiler
Create a string longer than 255 chars
DIM RECORD LStringOf course that's pretty straight forward. The problem is the wrapper routines to deal with these. You'll have to write functions to store the strings and get the strings and so forth. But it does provide the same functionality as a normal string with more programmer work. I've thought about implementing these for awhile in FB but my project in C has been taking all my programming time (and interest). If you really wanted robust strings with all the effort that is required in C to do string manipulation (C handles strings poorly IMHO) you could implement them in the same way with a pointer allocated based on the size of the string you want to store. Then you step through the pointer until you find the first null character. If it were me I'd use the record approach...
DIM END RECORD .lstrSize
How about using handle (or pointer)?
I always use handle to handle strings (texts) which over 255 characters.
If the max length was fixed and not so large, you may use pointer.
myStrLen% = 0
myStrPtr& = @myStrBlk
a$ = "test string"
BLOCKMOVE @a$+1,myStrPtr&,LEN(a$) '"put a$ to myStr ptr
myStrLen% = LEN(a$)
b$ = "hello?"
LONG IF LEN(b$)+myStrLen%<=360
myStrLen% = myStrLen% + LEN(b$)
CALL PARAMTEXT("String is too long!","","","")
id% = FN STOPALERT(1,0)
Been there and did this.
First two bytes are the length and the other 360 are for the string
to clear string (if necessary) use DEF BLOCKFILL
blockmove strPtr, myString + 2, strLen
strLen = peek word (myString)
I have stored text using a method similar to that which others have described, namely, a block of memory with a length byte first, followed by the text, one byte per "letter". If I can do it, anyone can :)
The reason you may have had difficulty, Tedd, is that you have to watch your number of single bytes so you don't end up with the compiler being left with an odd address at the end of various parts of code. At least that is a problem that I had.
To prevent that problem, I always made my text part an even number of bytes, preceded by a 2 byte length integer, which always keeps things even. I can't think of any other reasons why it wouldn't work for you. Try it again and see :),