Announcement

Collapse
No announcement yet.

redim problem

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • redim problem

    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?

  • #2
    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 .
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      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

      Comment


      • #4
        Originally posted by Michael Mattias View Post
        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.

        Comment


        • #5
          Originally posted by David L Morris View Post
          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!

          Comment


          • #6
            Chris--

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

            Bob Zale
            PowerBASIC Inc.

            Comment


            • #7
              Originally posted by Bob Zale View Post
              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)

              Comment


              • #8
                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?
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  Originally posted by Michael Mattias View Post
                  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.

                  Comment


                  • #10
                    Stack looks correct. looking back at dynamic memory usage.

                    Comment


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

                      Code:
                        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
                      Last edited by Michael Mattias; 18 Jun 2008, 09:19 AM.
                      Michael Mattias
                      Tal Systems (retired)
                      Port Washington WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment


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

                        Comment


                        • #13
                          Insufficient Self-Flogging Detail.

                          Inquiring Minds Want - no, Demand - to Know.
                          Michael Mattias
                          Tal Systems (retired)
                          Port Washington WI USA
                          [email protected]
                          http://www.talsystems.com

                          Comment

                          Working...
                          X