redim problem

[Chris Holbrook]

It is just possible that I'm missing the point with REDIM.

Using a REDIM statement to map a pointer array to results provided by a dll, the first use is

redim psz( 0 to 1) at dwresults

, then

redim psz( 0 to 999) at dwother

. This doesn't work, the ubound of psz stays at 1.

Making a "dummy" program which just toggles between the two redims works perfectly, of course.

Has anyone else had similar experiences with REDIM...AT?

[Michael Mattias]

Should give you an error on the REDIM with an ERR value.

but just guessing by the dataname....
'psz' data type is..... ASCIIZ PTR ?

I don't think arrays of ASCIIZ PTR (ambiguous length) are supported.

Heck, I don't know if arrays of ASCIIZ PTR * integer are .

[David L Morris]

Redim AT

Hi Chris

I seem to have no problems with this. You might recognize that it comes from one of your earlier contributions.

FUNCTION SaveResults(BYVAL dwSEP AS DWORD PTR) AS LONG
LOCAL i, j, lresult, n, nMaxRows, nMaxCols AS LONG
LOCAL pSEP AS SqliteEXecParms PTR, p AS DWORD
LOCAL pzX AS ASCIZ PTR, Res AS STRING
LOCAL X AS STRING, Headers AS STRING, msg AS STRING, psz() AS ASCIIZ PTR
LOCAL fNo AS LONG, fName AS STRING

pSEP = dwSEP
nMaxRows = @pSEP.rows
nMaxCols = @pSEP.cols
p = @pSEP.pSQLiteResults
pzX = @pSEP.psSQL

REDIM psz( 0 TO nMaxCols * (nMaxRows + 1) ) AT p

fName = "Results.txt"
fNo = FREEFILE
OPEN fName FOR OUTPUT AS #fNo
'Now get the rows
FOR j = 0 TO (UBOUND(psz()))
X = X + @psz(j) + $TAB
IF ((j + 1) MOD nMaxCols = 0) THEN X = X + $CRLF
NEXT
PRINT #fNo, X
CLOSE fNo
FUNCTION = -1
X = "Exit SaveResults now"
MSGBOX X

END FUNCTION

[Chris Holbrook]

I don't think arrays of ASCIIZ PTR (ambiguous length) are supported.

Just a 32-bit address surely, it is the thing it points to which is variable in length.

[Chris Holbrook]

I seem to have no problems with this. You might recognize that it comes from one of your earlier contributions.

Yes, that's pretty close to the current usage, but for some reason the redim is failing. My guess is that some other part of the application has gone off the rails and is interfering with it, so my current approach is to chop out code until I get it working again!

[Bob Zale]

Chris--

Be sure to include a specific scope (LOCAL...) and data type (LONG...) in the REDIM.

Bob Zale
PowerBASIC Inc.

[Chris Holbrook]

Be sure to include a specific scope (LOCAL...) and data type (LONG...) in the REDIM.

Thanks Bob, did that, found that if I commented out a listview column resize statement (which looks OK) in another SUB, the REDIM worked correctly. Am now thinking that something has messed up the heap or the call stack, which registers should I look at? (I'm a Z80 man)

[Michael Mattias]

Oh, I remember now, arrays of ambiguous-length ASCIIZ PTR are not supported as procedure parameters. At least they weren't last time I checked. (Pb 7x ?). I guess I should try again with 8x.

BTW this problem sounds like classic "memory corruption somewhere causing problems elsewhere."

What was the value of ERR following the REDIM?

[Chris Holbrook]

BTW this problem sounds like classic "memory corruption somewhere causing problems elsewhere."

my guess too.

What was the value of ERR following the REDIM?

zero! There's nothing wrong with the REDIM, but the next statement (SUB call) is the culprit. Or the next rock in the gully, to use the analogy where the real culprit is throwing rocks into a gully.

[Chris Holbrook]

Stack looks correct. looking back at dynamic memory usage.

[Michael Mattias]

Well, if ERR is 0 on the REDIM, I'd check ERR again with...

  REDIM psz (new bounds) 
  IF ERR = 0 THEN 
    ub = UBOUND (psz,1)
    IF ERR THEN
       oops, the array descriptor must be corrupted! 
    ELSEIF ub <> expected THEN 
       compiler bug?  Seems you should get ERR in one of these places
    ......

Alternate possibility is what Mr. Zale suggested: LOCAL/GLOBAL array name conflict.

MCM

[Chris Holbrook]

Thank goodness, it was just the idiot programmer after all.

[Michael Mattias]

Insufficient Self-Flogging Detail.

Inquiring Minds Want - no, Demand - to Know.