Printable View
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
I misplaced my crystal ball.
Has anyone seen it?
Without it, i cannot divine the code responsible for parsing.....
Is this in office vba? Vb6 should not be affected by this?
Maybe the two machines have different regional date/time/decimal formats?
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:
Code:Private UDT1() As Row_Content
Private UDT2() As ProjectEntry
Private UDT3() As ProjectGroup
Code: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
Code: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:
Code: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
I made sure the UDTs only include:Quote:
Originally Posted by ahenry
- Strings
- Integers
- Longs
- Doubles
- Bytes
Maybe on the 64b computer its saving integers as 32b and not 16b.
Are you using Variants somewhere in the UDTs or during save/load?
https://docs.microsoft.com/en-us/off...a-type-summaryQuote:
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.
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
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
Agreed.Quote:
Originally Posted by ahenry
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?
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.
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