v1ctor, I'm sending you my code tonight. The odd stuff with strings keep happenning.
I've pictured what happens, more or less:
1.- Affected are variable length strings.
2.- LEN and comparisons don't work with "damaged" strings.
3.- Damaged strings can be "repaired" using fixed length strings:
Code:
FixLength = VarLength: VarLength = FixLength
so I guess that assignation works fine.
With "damaged strings" I mean what I posted before:
Code:
Assignation Contents Len function Comparison
---------------------------------------------------------------------------------
w$ = "TOWN" -> TOWN# LEN(w$) = 4 ; IF w$ = "TOWN" -> true
w$ = "ANOTHER VAL" -> ANOTHER VAL# LEN(w$) = 11 ; IF w$ = "TOWN" -> false
w$ = "TOWN" -> TOWN#ER VAL# LEN(w$) = 11 ; IF w$ = "TOWN" -> false !!!
Code:
dim dbgFile as string
print DATE$
dbgFile = DATE$+"."+TIME$
print dbgFile
sleep
end
Output:
Quote:12-07-2004
12-07-20.22:33:16
date$ was allocating 2 chars less than needed, never copy&paste code.. i wrote time$ first and then used most of code to write date$ in 3 minutes.. fixed
DIM SHARED PlayerSprites() AS INTEGER
says error. expected expression, found )
I think it expects array dimensions. Well I ain't giving any! :-p .. does work if I use COMMON
but I tried figuring out why
FOR P = 1 TO NumPlayers
gives me an error 'expecting scalars'
hmm wait I DIMmed P to integer and now the error is gone X-) .. defint gone somewhere? .. hmm.. I guess it's me. But now I did find something else..
I said
COMMON SHARED Ground() AS INTEGER
and
REDIM Ground(Size1616, 13) AS INTEGER
and I used the expression
Ground(0, 9) in like:
SVGAPut Bomb(P, b).X, Bomb(P, b).Y, VARPTR(Ground(0, 9)), VARSEG(Ground(0, 9))
gives me error wrong number of dimensions. The reason I use COMMON SHARED is actually just an arctifact from using modules. Should be valid code though.
(I know I need to throw out SVGAPut and those varptr's are gone too then. porting isn't that simple as it sounds :-p)
Greetings,
Badjas
DIM Temp(420), Temp2(420)
...
REDIM Temp(672)
...
gives me duplicated definition error on the redim statement
VARSEG() does not exist, FB thinks it's an array - due the ambiguity with undeclared variables - but was not dimensioned.
I never used "dim array() as anytype", didn't know QB allowed that.. living and learning - writing a compiler w/o an specification isn't simple.
DIM bleh(constant expression)
then
REDIM bleh(expression)
won't work if $dynamic wasn't used (all that is shown at docs/keywords.txt, nobody reads it).
bleh() will never be dynamic - QB allocates ALL arrays inside procs as dynamic, FB doesn't do that, there's enough stack to use and its way faster than calling the OS to do the allocation.
:oops: mea maxima culpa
thanks for explaining I should get back to work
wait.. '$DYNAMIC is there.. or .. now that I put '$DYNAMIC in the sub the error goes away.. I see. okay :-)
declare sub resetscreen ()
dim a as string
dim level as integer
dim loadlevel as integer
dim p as integer
IF a <> "" THEN
SELECT CASE ASC(Right$(a, 1))
CASE 13:
LoadLevel = Level
EXIT SUB
CASE 27: ReSetScreen: END
CASE 72: Level = Level - 1: IF Level = 0 THEN Level = 15
CASE 80: Level = Level + 1: IF Level = 16 THEN Level = 1
CASE ELSE: P = 0
END SELECT
end if
print p
END
sub resetscreen ()
end sub
----------
that crashes for me anyway. using v0.06 (and btw with version numbering, I'd regard version 0.10 as the successor to 0.9. Just treating the decimal part like it was a number. now you have a 99 versions limitation)
ehm.. I made that program by copying some code from a bigger program to narrow down the error I got on the CASE ELSE line but that error is now hidden by the crash. the error on the CASE ELSE line is 'invalid data type' and 'expected end if' (but perhaps I'm just really rusty at basic)
EXIT SUB outside a proc, will have to add a check for that.. it's trying to jump to an label that doesn't exist, then the access violation..
What's wrong with having a 0.100 version?
