Announcement

Collapse
No announcement yet.

Strange user defined type bug?

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

  • Florent Heyworth
    replied
    Very strange indeed!

    If you want a quick workaround just use TYPE TableType DWORD
    to force DWORD type alignement. It seems as though the
    TableType.Filename elements are overwriting array memory.

    Cheers

    Florent

    ------------------

    Leave a comment:


  • Peter Manders
    replied
    My guess is you need to DIM or REDIM before you can use PRESERVE, but it doesn't explain this.

    I haven't tried if it would fix this behaviour, I just think it's illogical to PRESERVE something that doesn't exist yet.


    Peter.


    ------------------
    [email protected]

    Leave a comment:


  • jhilb
    Guest replied
    Thanks Charles. I give up... If anyone else can shed some light please do.

    Guess I am going to back to the 'old' way (4 arrays).

    ------------------

    Leave a comment:


  • jhilb
    Guest replied
    Correct. I was just playing with this again.

    If I leave one of the LONG declarations in (removing the other one) OR if I put other declarations in between the two LONG declarations it works. It also works when I change the LONGs to INTs.

    As far as I can tell, PBDLL doesn't like two LONG declarations next to each other in a user defined type. Actually, it's the initialization (Tables(X).LKFileHandle = 0) that goes wrong. I'm fairly sure this is a bug. I mean, I can't understand why this shouldn't work, but it doesn't.


    ------------------

    Leave a comment:


  • Charles Dietz
    replied
    Jeff,

    I used the following code to get the strange behavior you observed.
    If I change either of the first two element lengths to any thing but
    70 and 8, it works. My guess that the first element length needed to
    be a multiple of 8 was wrong. Very strange, indeed.

    Code:
    #COMPILE EXE
    #DIM ALL
    
    TYPE TableType
       TableName AS STRING * 70
       FILENAME AS STRING * 8
       LKFileHandle AS LONG
       OVFileHandle AS LONG
    END TYPE
    
    GLOBAL Tables() AS TableType
    GLOBAL TotalTables AS LONG
    DECLARE FUNCTION rvOpen() AS INTEGER
    
    FUNCTION PBMAIN
       LOCAL Temp AS LONG
       STATIC keep AS LONG
       TotalTables = 0
       FOR Temp = 1 TO 5
          INCR TotalTables
          REDIM PRESERVE Tables(1 TO TotalTables)
          Tables(TotalTables).TableName = "TABLE " + STR$(TotalTables)
          Tables(TotalTables).FileName = "BLAH"
          Tables(TotalTables).LKFileHandle = 0
          Tables(TotalTables).OVFileHandle = 0
          'MSGBOX Tables(TotalTables).TableName, , "DEBUG"
          'MSGBOX Tables(1).TableName, , "DEBUG"
       NEXT
       rvopen
    END FUNCTION
    
    FUNCTION rvOpen () EXPORT AS INTEGER
       LOCAL ThisTable AS LONG
       FOR ThisTable = 1 TO TotalTables
          MSGBOX Tables(ThisTable).TableName, , "DEBUG"
       NEXT
       rvOpen = -1 'success
    END FUNCTION
    ------------------

    Leave a comment:


  • Charles Dietz
    replied
    Jeff,

    If you change the first member of the structure to a length of 64,
    or I suppose, any multiple of 8, it works. I'm not sure why, maybe
    someone with more smarts can help. But I can tell you this, the
    init does not populate the tables array correctly, as you can verify
    by setting the first MSGBOX to

    MSGBOX Tables(1).TableName, , "DEBUG"


    ------------------

    Leave a comment:


  • jhilb
    Guest started a topic Strange user defined type bug?

    Strange user defined type bug?

    When I run the code below, the Init populates the Tables array of user type TableType correctly.

    But the Open routine doesn't display the correct information when accessing the same array again. The strings seems to 'run' into each other.

    However, removing the two LONGs from TableType works. Any suggestions? I think this is a bug. Code seems simple enough to me.

    These are the results I am getting for Tables.Filename when the LONGs are in the type declaration...

    Tables(1).Filename "TABLE 1TABLE 2TABLE 3TABLE 4TABLE 5"
    Tables(2).Filename "TABLE 2TABLE 3TABLE 4TABLE 5"
    Tables(3).Filename "TABLE 3TABLE 4TABLE 5"
    Tables(4).Filename "TABLE 4TABLE 5"
    Tables(5).Filename "TABLE 5"

    And when I removed the two LONGS from the TableType definition these are my results...they are as I would have expected.

    Tables(1).Filename "TABLE 1"
    Tables(2).Filename "TABLE 2"
    Tables(3).Filename "TABLE 3"
    Tables(4).Filename "TABLE 4"
    Tables(5).Filename "TABLE 5"

    Thanks,
    Jeff


    ----------------------------------------------------------

    #REGISTER ALL
    #COMPILE DLL
    #DIM ALL
    #INCLUDE "WIN32API.INC"
    #INCLUDE "VBAPI32.INC"

    TYPE TableType
    TableName as String * 70
    FileName as String * 8
    LKFileHandle as Long
    OVFileHandle as Long
    END TYPE

    Global Tables() as TableType
    Global TotalTables as Long

    FUNCTION rvInit () EXPORT AS INTEGER
    Dim Temp as Long
    TotalTables = 0
    FOR Temp = 1 to 5
    INCR TotalTables
    ReDim Preserve Tables(1 TO TotalTables)
    Tables(TotalTables).TableName = "TABLE " + str$(TotalTables)
    Tables(TotalTables).FileName = "BLAH"
    Tables(TotalTables).LKFileHandle = 0
    Tables(TotalTables).OVFileHandle = 0

    msgbox Tables(TotalTables).TableName, , "DEBUG"
    NEXT

    rvInit = -1 ' success
    END FUNCTION

    FUNCTION rvOpen () EXPORT AS INTEGER
    Dim ThisTable as Long
    For ThisTable = 1 to TotalTables
    msgbox Tables(ThisTable).TableName, , "DEBUG"
    Next

    rvOpen = -1 'success

    END FUNCTION


    ------------------
Working...
X