Having solved that I immediately ran into another problem. It seems dynamic arrays do not increase the length in bytes of the structure they are part of?
Example:
I need the structure to be the correct size for the data I'm loading into it, else the program crashes.
The arrays only need to be redimmed to one of two possible sizes but I'd rather not have two seperate, nearly identical structures, and two sets of code to deal with them.
Example:
Private Type something1 'Length = 80
a As Long
b As Long
c(27) As Byte
d(35) As Byte
e As Long
f As Long
End Type
Private Type something2 'Length = 916
a As Long
b As Long
c(799) As Byte
d(99) As Byte
e As Long
f As Long
End Type
Private Type something3 'Length = 24 (no matter what redimmed to)
a As Long
b As Long
c() As Byte
d() As Byte
e As Long
f As Long
End Type
Private Sub Form_Load()
Dim Example1 As something1
Dim Example2 As something2
Dim Example3 As something3
Dim Example4 As something3
Dim Example5 As something3
ReDim Example4.c(27)
ReDim Example4.d(35)
ReDim Example5.c(799)
ReDim Example5.d(99)
MsgBox LenB(Example1)
MsgBox LenB(Example2)
MsgBox LenB(Example3)
MsgBox LenB(Example4)
MsgBox LenB(Example5)
End Sub
I need the structure to be the correct size for the data I'm loading into it, else the program crashes.
The arrays only need to be redimmed to one of two possible sizes but I'd rather not have two seperate, nearly identical structures, and two sets of code to deal with them.
Hmmm, how odd. Must be to do with the way VB deals with ReDimmed arrays, ie maybe it doesn't actually increase the size of the original, it just creates a new one and points the old one to the new one or something...I don't know.
How about the following:
This is 24 because we know that the four LONG variables are each 4 bytes and it must use one four byte space to hold the variable to be redimmed, thus 6 x 4 = 24.
Why not use this to find out the size:
Of course, this will fail if Example1.c and Example1.d have not been redimmed already, but if you ReDim them straight away, even just to 1, then this will overcome that.
EDIT:
Just checked to make sure I am right (I may not be)
lenb(example1) = 4 : I would expect this.
lenb(example1) = 8 : I would expect this too.
lenb(example1) = 12 : again, what I expected.
But:
lenb(example1) = 12 : this I was expecting to be 16!
Only when you add another variable (ie e(1) as Byte) does it move to 16, and then you can add another one (ie f(1) as byte) and it stays at 16!)
Oh dear, seems not to be as simple as I thought.
Tim
How about the following:
Private Type something3 'Length = 24 (no matter what redimmed to)
a As Long
b As Long
c() As Byte
d() As Byte
e As Long
f As Long
End Type
Dim Example1 as something3
This is 24 because we know that the four LONG variables are each 4 bytes and it must use one four byte space to hold the variable to be redimmed, thus 6 x 4 = 24.
Why not use this to find out the size:
arrlength = UBOUND(Example1.c) + UBOUND(Example1.d) + 16Of course, this will fail if Example1.c and Example1.d have not been redimmed already, but if you ReDim them straight away, even just to 1, then this will overcome that.
EDIT:
Just checked to make sure I am right (I may not be)
Private Type something1
a As Long
End Type
dim Example1 as something1
lenb(example1) = 4 : I would expect this.
Private Type something1
a As Long
b As Long
End Type
dim Example1 as something1
lenb(example1) = 8 : I would expect this too.
Private Type something1
a As Long
b As Long
c(1) as Byte
End Type
dim example1 as something1
lenb(example1) = 12 : again, what I expected.
But:
Private Type something1
a As Long
b As Long
c(1) as Byte
d(1) as Byte
End Type
dim example1 as something1
lenb(example1) = 12 : this I was expecting to be 16!
Only when you add another variable (ie e(1) as Byte) does it move to 16, and then you can add another one (ie f(1) as byte) and it stays at 16!)
Oh dear, seems not to be as simple as I thought.
Tim
I think it pre-allocates memory for the structure in blocks of 4 bytes. It picks the smallest size that fill fit the structure, then pads the rest with zeros (although quite where these zeros live, I'm unsure). Perhaps at the end, as that is how it seems to work the exe sizes (but in blocks of 4096 bytes) at compile time.
I have come up with a solution to the issue though. By reading data into the type (using this example still) up until B, then looping through reading x bytes at a time I fill the C array. Trouble is that the dynamic arrays must be the last elements in the struct if I want to fill the rest of it in one easy chunk (which I definately want to do as the actual type is considerably larger than my example).
So I need to use this:
I have come up with a solution to the issue though. By reading data into the type (using this example still) up until B, then looping through reading x bytes at a time I fill the C array. Trouble is that the dynamic arrays must be the last elements in the struct if I want to fill the rest of it in one easy chunk (which I definately want to do as the actual type is considerably larger than my example).
So I need to use this:
Private Type something
a As Long
b As Long
c() As Byte
d() As Byte
End Type
Private Type something_contd
e As Long
f As Long
End Type
What about
Tim
Private Type something
a As Long
b As Long
e as Long
f as Long
c() As Byte
d() As Byte
End Type
Tim
Maybe this helps. Search for Section 6: "Passing and Returning User-Defined Types". (Disclaimer: I have never programmed in VB, so I can be completely wrong ).
).How about throwing away those dynamic types/structures and using classes instead? Dynamic stuff will be easier, can do functions/subs too and more object oriented.
All depends on what you're doing.. so I'm just throwing ideas out there.
All depends on what you're doing.. so I'm just throwing ideas out there.
Sounds great, only I was taught very little VB6 at University; I'm mostly self-taught. And I've never touched on classes. Since I've nearly finished getting the program working with my current solution, I'll have to read up on classes some other time. Something I should probably know. I remember the revelation when I discovered UDTs, made my life so much easier. 
I will have to kick my Uni up the arse for teaching us (not even all the basics of) seven languages instead of getting to know one or two reasonably well. I mean what good is knowing smatterings of C, C++, VB6, x86 Assemly, JavaScript, Perl and PHP, if we're not confident enough to do anything with them (without extensive extra learning)? Likewise HTML was never taught beyond the basics of HTML 4 transitional, with a little CSS thrown in for good measure.
/rant
I will have to kick my Uni up the arse for teaching us (not even all the basics of) seven languages instead of getting to know one or two reasonably well. I mean what good is knowing smatterings of C, C++, VB6, x86 Assemly, JavaScript, Perl and PHP, if we're not confident enough to do anything with them (without extensive extra learning)? Likewise HTML was never taught beyond the basics of HTML 4 transitional, with a little CSS thrown in for good measure.
/rantSounds like they spread everything a little thin.
Yep, classes are a vital thing to learn. UDTs in VB have some nasty properties when you pass them about or need to pass them through a domain boundary etc. I think they are stack based and not heap again which bring massive disadvantages.
That said VB classes are very limited compare to real OO languages, they are really a COM wrapper. You can't inherit from them or use virtual routing or any of the real power that OO languages give you.
1
2
VB6 Help
(34 posts, started )
FGED GREDG RDFGDR GSFDG