Oh man is this a strange one. I have a user defined type that I write
out to a file and read in via VBA. The type is all fixed lengths
strings and integers. It has read in fine in VB6 and VBA for years. I
recently changed the type to include another fixed length string and an
array of integers. Still writes out and reads in just fine in VB6,
however when I read it in with VBA, it reads in 2 bytes more than it
should. There is no rhyme or reason to it. Anyone experience this
before?

Thanks

Post the code you are using.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com


wrote in message
oups.com...
Oh man is this a strange one. I have a user defined type that
I write
out to a file and read in via VBA. The type is all fixed
lengths
strings and integers. It has read in fine in VB6 and VBA for
years. I
recently changed the type to include another fixed length
string and an
array of integers. Still writes out and reads in just fine in
VB6,
however when I read it in with VBA, it reads in 2 bytes more
than it
should. There is no rhyme or reason to it. Anyone experience
this
before?

Thanks

I am running into one of the strangest issues I have seen in a long
time. I have a user defined type that I utilize in VB6 and write out to
a binary file.

The Type is...


VBA:
Type SECTIONDB ' Job Section List Database
SectionNum As Integer ' Section number
Multiplier As Long ' Multiplier
SpecName As String * 8 ' Spec name
ZoneName As String * 60 ' Zone name
Division As String * 20 ' Variable Zone Identifier
Subzone As String * 40 ' Subzone description
AssemblyName As String * 60 ' Assembly name
Notes As String * 100 ' User notes (remarks)
Flags As Integer ' Section flags
BaseHours As Double ' Base hours for section
AdjustHoursV(3) As Double ' Adjusted hours for section
FactorV(3) As Single ' User labor factor for section
JobHoursV(3) As Double ' Total job hours
ExceptCnt As Integer ' Exception count
ScaleFactor As Long ' Scale (1"=x')
RefSizeV(13) As Integer ' Reference sizes
VarDesc(13) As String * 16 ' Variable Size Descriptions
OrderNum As Integer ' Zone Order
RFU As String * 60 ' Reserved space for future use
End Type

The file is written in VB as such..

VBA:
Dim I As Integer
Dim FD As Integer
Dim Magic As Integer

On Error Resume Next
DeleteFile Path
FD = FreeFile
Open Path For Binary Access Write As FD
If Err < ERR_NONE And Err < ERR_NOTFOUND Then Goto
StoreSectionDB_Error
On Error Goto StoreSectionDB_Error
Magic = SECTIONDB_MAGIC
Put FD, 1, Magic
Put FD, , SectionVCnt
Put FD, , SectionNum
For I = 0 To SectionVCnt - 1
Put FD, , SectionV(I)
Next I
Close FD
The Magic,SectionVcnt,SectionNum are simply integers, so the file
created is 3 integers then as many of these user types as needed.

In excel I read this in as one would expect...


VBA:
FD = FreeFile()
Open PathName For Binary Access Read As FD
Get FD, 1, Magic
Get FD, , SectionVCnt
Get FD, , SectionNum
ReDim SectionV(SectionNum)
For i = 0 To SectionVCnt - 1
Get FD, , SectionRec
Next i

This has worked without issue for many years. However, after my last
upgrade to the SectionDB user type, suddenly when I read in the
sections, they are offset by 2 bytes, for no reason that I can find,
the header of the files is still those 3 integers. The first section
read's in just fine, but the rest are offset.

And this file reads in exactly right in VB6.

Any insight would be greatly appreciated.

Thanks

Reading Binary File bug

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

After a little more digging, I find the offset is actually 2 bytes.
What I did was set up both VB and VBA to show me the file position as
it was being read in. With the exact same file the following is
reported. Keep in mind there are 3 integers at the start of the file,
and the SectionDB is 704 bytes, verfified in both VB and VBA using a
len(SectionRec) call.
File Position...................VB.........VBA
Get FD, 1, Magic.............3...........3
Get FD, , SectionVCnt......5...........5
Get FD, , SectionNum.......7...........7
Get FD, , SectionRec........711........713
Get FD, , SectionRec........1415.......1419
Get FD, , SectionRec........2119.......2125

So each call in VBA adds another 2 bytes to the offset, VBA knows the
length of the SectionRec type is 704, so why the heck is it getting
these extra two bytes for?

Any Help would be appreciated

Quick follow up, I still can't reliably repro this every time, however
when I do get it, I can get it continuously in that session, until I
close excel, and I have found I can reliably get it to stop happening
if I rename the Vardesc array in the SectionDB type to AckDesc. I can
only guess that the name Vardesc is somehow triggering excel to think
their is a Variant variable when there is not.