Strange user defined type bug?

[jhilb]

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


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

[Charles Dietz]

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"


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

[Charles Dietz]

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.

#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

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

[jhilb]

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.


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

[jhilb]

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).

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

[Peter Manders]

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]

[Florent Heyworth]

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

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