Saving/Loading UDT(s) as text file, 32b and 64b system

[tonyd5]

I am storing and recalling large UDT arrays as text files... Using the PUT & GET functions.

The program using these text files to load previously parsed information.



After moving the program and UDT text files from a 32b computer to a 64bit computer they do not parse correctly.

How can I correct this so that UDT files read the same on both computers?


Thanks
Tony

[Zvoni]

I misplaced my crystal ball.
Has anyone seen it?
Without it, i cannot divine the code responsible for parsing.....

[dz32]

Is this in office vba? Vb6 should not be affected by this?

[ahenry]

Maybe the two machines have different regional date/time/decimal formats?

[tonyd5]

I didn't put the code to keep things straight forwarded... I believe the problem is with Put & Get functions differing on 32b & 64b systems.


Excel VBA.
No add-ins, no references.


Computer1:

• 64B
• Excel 2016
• Works
  

Computer2:

• 32B
• Excel 2007
• Works

Problem:

• Moving saved text files (created by Put) computer1<->computer2 does not work.
• When load using the Get it throws and error. Something like buffer full, I'm not at work and can't do it right now.
• Text files look different on each machine.
• The problem occurs with all UDT types.

Put and Get functions are called within a class.
The class code is programmatically created so that I can LOAD/SAVE any UDT() without manually changing anything. Its whole thing.

https://www.vbforums.com/showthread....g-loading-UDTs


UDT save/load Class code:

Private UDT1() As Row_Content
Private UDT2() As ProjectEntry
Private UDT3() As ProjectGroup

Private Sub myPut(filenumber, Optional recnumber As Variant)

If selUDT = 0 Then MsgBox ("UDT() is not set, cannot perform operation"): Exit Sub

On selUDT GoSub opt1, opt2, opt3    '<-- add additional types here
GoTo optFinished

opt1: Put #filenumber, recnumber, UDT1: Return
opt2: Put #filenumber, recnumber, UDT2: Return
opt3: Put #filenumber, recnumber, UDT3: Return
'<-- add additional types here
optFinished:

End Sub

Private Sub myGet(filenumber, Optional recnumber As Variant)

If selUDT = 0 Then MsgBox ("UDT() is not set, cannot perform operation"): Exit Sub

On selUDT GoSub opt1, opt2, opt3    '<-- add additional types here
GoTo optFinished

opt1: Get #filenumber, recnumber, UDT1: Return
opt2: Get #filenumber, recnumber, UDT2: Return
opt3: Get #filenumber, recnumber, UDT3: Return
'<-- add additional types here
optFinished:

End Sub

UDT(s) defined:

Public Type Row_Content

    row As Integer

    dateS As String
    offtime As String
    ontime As String
    JLSminutes As String
    
    '--------------
    customer_arr() As String
    location_arr() As String
    comments_arr() As String
    
    Ncust As Integer
    Nbox As Integer
    Ninfo As Integer
    '---------------
    
    ORG_cust_str As String
    ORG_box_str As String
    ORG_info_str As String
    User_Comment As String
    
    projs_indx() As Integer
    N_projs_indx As Integer
End Type




Public Type ProjectEntry

    row As Integer
    
    id As Long
    IDarr() As Byte
    
    position As String
    
    customer As String
    
    RAD As String
    
    str As String
    
    action As Integer 'ProjectAction
 
    i As Integer
    
    A As Integer
    b As Integer
    s As String
    
    NOTstr() As String
    Nstr_len As Integer
    
    calc_exposure As Double
    calc_durationHR As Double
    
    dateS As String
    
    cmprRow_Content As Row_Content
 
End Type


'-- for ProjectGrouper Class
Public Type projGroupItem

    str As String
    row As Integer
    cmprRow_Content As Row_Content
    pID() As Byte  '<-- probably will not be used
    
    action As Integer
    boxOpt() As String
    custOpt() As String
    
    '--
    curr_exposure As Double
    curr_durationHR As Double
End Type


Public Type ProjectGroup
    
    GrpItemsArr() As projGroupItem
    Nitems As Integer
    '
    curr_exposure As Double
    curr_durationHR As Double
    curr_TargetRadDate As String
End Type

[tonyd5]

Maybe the two machines have different regional date/time/decimal formats?

I made sure the UDTs only include:

• Strings
• Integers
• Longs
• Doubles
• Bytes

Maybe on the 64b computer its saving integers as 32b and not 16b.

[Arnoutdv]

Are you using Variants somewhere in the UDTs or during save/load?

Variant (with characters) -> 22 bytes + string length (24 bytes on 64-bit systems) -> Same range as for variable-length String

Note

Arrays of any data type require 20 bytes of memory plus 4 bytes for each array dimension plus the number of bytes occupied by the data itself. The memory occupied by the data can be calculated by multiplying the number of data elements by the size of each element.

For example, the data in a single-dimension array consisting of 4 Integer data elements of 2 bytes each occupies 8 bytes. The 8 bytes required for the data plus the 24 bytes of overhead brings the total memory requirement for the array to 32 bytes. On 64-bit platforms, SAFEARRAY's take up 24-bits (plus 4 bytes per Dim statement). The pvData member is an 8-byte pointer and it must be aligned on 8 byte boundaries.

https://docs.microsoft.com/en-us/off...a-type-summary

[Zvoni]

His String-Arrays.
As Arnout wrote: On 64-Bit Office the StrPtr of each Member is 8 Bytes, on 32-Bits-Office it's 4 bytes

Tony,
do a Debug.Print LenB(UDT1), LenB(UDT2), LenB(UDT3) .... on each machine

NotaBene: The Bitness of the OS is irrelevant, it's the Bitness of Office that's messing you up

[ahenry]

So what you're describing is that your structure's byte alignment is different in 32-bit and 64-bit VBA. You can verify this by looking at the actual differences in your files. So your options are:
1) Add padding to your structures so that the fields that you care about are placed in 64-bit alignment that happens to be in the same location for 32-bit or 64-bit. This may or may not be workable.
2) Define separate UDTs for 32-bit, 64-bit, reading 32-bit from 64-bit, and reading 64-bit from 32-bit.
3) Give up on your shortcut for serializing UDTs and use some other method.

See:
https://codekabinett.com/rdumps.php?...ion-vba-64-bit

[Zvoni]

3) Give up on your shortcut for serializing UDTs and use some other method.

Agreed.
If it has to be Text-Based, i'd go for JSON.
FWIW, this looks like some very crude try to implement something like a Database.

GoSub? Seriously?

[tonyd5]

I'll see if the UDTs are different lengths with LenB tomorrow. Should give some insight.

Doesn't have to be text based. Maybe if I save it as a binary file it will resolve it. The text formatting on the 32b system might be screwing it up.


This is for a program that interprets/deciphers user entries on an excel sheet. Uses big matrix operations to figure out what the heck the user input is trying to say.

It's slow to do this...

The point of saving/loading the UDTs so the program only has to parse newly added info, not the whole thing every time.
If the text files get erased the program is cool with it, though it takes 10-20 minutes to reparse everything.


Don't poo poo the UDT save/load Class. It makes coding much easier.

I can edit the user-defined-types without changing any save/load code.
I can add new types without making any new save/load code.
All the crazy GOTO stuff inside the Class is auto created code. Its like that for simplicity. Shouldn't have to open this class at all.

[dz32]

If it took me more than 2hrs to discern the problem with the black box routines in the different office versions
I would probably just switch over to write my own serializer for the data.

Start with small structures and unique test data in each field (numerics in hex values)
They load it in the other version and see where mismatch starts. Open file in hexeditor to see actual data dumped
And maybe some copymemory to byte arrays based on lenb to hexdump the actual data after loaded

Or write the same udt to different files in each version and diff with hexeditor