Hello!

I am saving an array to a file and then load it again.


     Open sPath For Binary As #iFile1

     If uLoad Then
         Get #iFile1, , uArray
     Else
         Put #iFile1, , uArray
     End If

My array looks like this:

Redim myArr(1 to 3) as long
myArr(1) = 100
myArr(2) = 500
myArr(3) = 10000

When I load it again, I say:

Redim MyNewArr(1 to 3) and call the above sub.

For some reason, MyNewArr now looks like this:

MyNewArr(0) = 100
MyNewArr(1) = 500
MyNewArr(2) = 3

When I try to access MyNewArr(3) an out of bounds error is thrown.

Can somebody please tell me how to save my array correctly so that it 
will start at 1 again, just like I declared it when redimming it?

Thank you!

on 9/11/2010, Boris P. supposed :
> Hello!
>
> I am saving an array to a file and then load it again.
>
>
>      Open sPath For Binary As #iFile1
>
>      If uLoad Then
>          Get #iFile1, , uArray
>      Else
>          Put #iFile1, , uArray
>      End If
>
> My array looks like this:
>
> Redim myArr(1 to 3) as long
> myArr(1) = 100
> myArr(2) = 500
> myArr(3) = 10000
>
> When I load it again, I say:
>
> Redim MyNewArr(1 to 3) and call the above sub.
>
> For some reason, MyNewArr now looks like this:
>
> MyNewArr(0) = 100
> MyNewArr(1) = 500
> MyNewArr(2) = 3
>
> When I try to access MyNewArr(3) an out of bounds error is thrown.
>
> Can somebody please tell me how to save my array correctly so that it will 
> start at 1 again, just like I declared it when redimming it?
>
> Thank you!

By default arrays are zero based. So a 3 element array will always 
begin with 0 and end with 2. You have to declare Option Base to 1 if 
you want to go that way. However, I strongly recommend you modify your 
thinking to use the default zero base. (It'll make life much 
easier!<g>)

-- 
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

GS wrote:
> on 9/11/2010, Boris P. supposed :
>> Hello!
>>
>> I am saving an array to a file and then load it again.
>>
>>
>>      Open sPath For Binary As #iFile1
>>
>>      If uLoad Then
>>          Get #iFile1, , uArray
>>      Else
>>          Put #iFile1, , uArray
>>      End If
>>
>> My array looks like this:
>>
>> Redim myArr(1 to 3) as long
>> myArr(1) = 100
>> myArr(2) = 500
>> myArr(3) = 10000
>>
>> When I load it again, I say:
>>
>> Redim MyNewArr(1 to 3) and call the above sub.
>>
>> For some reason, MyNewArr now looks like this:
>>
>> MyNewArr(0) = 100
>> MyNewArr(1) = 500
>> MyNewArr(2) = 3
>>
>> When I try to access MyNewArr(3) an out of bounds error is thrown.
>>
>> Can somebody please tell me how to save my array correctly so that it 
>> will start at 1 again, just like I declared it when redimming it?
>>
>> Thank you!
> 
> By default arrays are zero based. So a 3 element array will always begin 
> with 0 and end with 2. You have to declare Option Base to 1 if you want 
> to go that way. However, I strongly recommend you modify your thinking 
> to use the default zero base. (It'll make life much easier!<g>)

I'd say "it depends" on whether to use 0- or 1-based indexing, dependent 
upon the problem domain.

Note that ReDim() should _not_ be used except for redimensioning, not 
for initial declarations  -- see the Caution discussion in the language 
reference manual for ReDim.

In short, the above code snippet should start w/ a

Dim myArr() As Long
ReDim myArr(1 to 3)

There's a problem w/ the code and the symptoms described as well--I 
strongly suspect the code isn't as typed in (and can tell it isn't 
copied and pasted as the capitalization for keywords isn't consistent w/ 
the VB stylistic pattern).

The statement

Redim MyNewArr(1 to 3)

isn't complete, either, as the "As Long" clause is missing and the 
existence of the (1 To 3) if it were in the actual code would preclude 
the appearance of MyNewArr(0) as the upper and lower bound subscripts 
are explicitly given.

I suspect that what you _actually_ have is

ReDim MyNewArr(3)

instead which would behave as GS notes assuming there is no

Option Base 1

statement in effect.

Lesson to be learned -- when posting code that is to demonstrate a 
symptom, post the actual code and the symptom, not a paraphrasing of it.

--

"GS" <gesansom@netscape.net> wrote in message 
news:i6gr11$u8s$1@news.eternal-september.org...
> on 9/11/2010, Boris P. supposed :

>
> By default arrays are zero based. So a 3 element array will always begin 
> with 0 and end with 2. You have to declare Option Base to 1 if you want to 
> go that way. However, I strongly recommend you modify your thinking to use 
> the default zero base. (It'll make life much easier!<g>)


No, that's incorrect. If you do NOT specify a lower bound, only then the 
default is 0.  Otherwise, the lower bound is whatever you specify in your 
Dim/ReDim. Option Base 1 just means that if you DON'T specify the lower 
bound, it will default to 1 instead of 0.

I also can't agree with your recommendation. In some cases, sure, the array 
should be 0-based.  For example, if syncing it to something that is 0-based 
(a listbox, for example). Otherwise, I personally view it as "programmer's 
preference".

-- 
Mike
 

MikeD submitted this idea :
>
> "GS" <gesansom@netscape.net> wrote in message 
> news:i6gr11$u8s$1@news.eternal-september.org...
>> on 9/11/2010, Boris P. supposed :
>
>>
>> By default arrays are zero based. So a 3 element array will always begin 
>> with 0 and end with 2. You have to declare Option Base to 1 if you want to 
>> go that way. However, I strongly recommend you modify your thinking to use 
>> the default zero base. (It'll make life much easier!<g>)
>
>
> No, that's incorrect. If you do NOT specify a lower bound, only then the 
> default is 0.

That was implied in the context of the OP's problem! Dumping a file 
into an array with 'Get' will result in a zero-based array UNLESS 
Option Base 1 is declared. That's all I was responding to.

>  Otherwise, the lower bound is whatever you specify in your 
> Dim/ReDim. Option Base 1 just means that if you DON'T specify the lower 
> bound, it will default to 1 instead of 0.

No disagreement here.

>
> I also can't agree with your recommendation. In some cases, sure, the array 
> should be 0-based.  For example, if syncing it to something that is 0-based 
> (a listbox, for example). Otherwise, I personally view it as "programmer's 
> preference".

And as a programmer's preference, it was my recommendation to not use 
it 'generally speaking'! Again, no disagreement that it does have a 
place if one chooses to accept the resposibility of managing it in 
those cases. Personally, I've never found any practical reasons to 
suffice using Option Base 1.<g>

Not to raise contention.., but just to clarify!

-- 
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

GS wrote:
....

> That was implied in the context of the OP's problem! Dumping a file into 
> an array with 'Get' will result in a zero-based array UNLESS Option Base 
> 1 is declared. That's all I was responding to.
....

The Get doesn't really have anything to do with...unless the variable 
has been declared as a variable, it's a scalar and only a single value 
will be returned on the Get (ignoring the details of descriptors for 
dynamic strings/arrays or UDTs).

The dimensions of the array are based on the Dim or ReDim used and the 
Option Base in effect at the time.

The problem w/ OP's posting is that his posted code doesn't reflect the 
actual code--it's missing the definition of the calling sequence in the 
subroutine snippet and the location with respect to that of where he 
looked at the data and how.  The array name he complains of isn't the 
same as the array name in the routine so it isn't that that caused the 
problem.

There's also the problem noted above of whether he's reading/writing the 
same type of array -- if it was dynamic on Put, it needs to be dynamic 
matching on Get or he's going to get the descriptor information 
confounded w/ the data.  Conversely, if Put a fixed-sized array, only 
the data (no descriptors) will be written and trying to read it into a 
dynamic array will confound the data w/ descriptors the other direction.

The upshot still is, OP needs to post the actual code to be able to see 
precisely what caused the specific symptom(s) but he's got problems of 
inconsistency and poor practice at a minimum...

--

dpb wrote:
....

> The Get doesn't really have anything to do with...unless the variable 
> has been declared as a variable, ...

That of course was intended to read "declared as an array, ..."

--

Well stated.., and I agree.

Sorry I wasn't giving focus past the use of 'Get' and 'Put' in the 
concept of the posted code so much as how the array[s] were dimmed 
going to and coming back from the file.

As far as I'm concerned, my experience bears out that both you and Mike 
D have made valid points that I fully agree with. Personally, I've 
never mixed static/dynamic arrays in this usage knowing that Put/Get 
require everything be the same both ways or there's going to be 
problems.

Just seemed the LBound/UBound issue was related to the Option Base used 
(or not used)<g>

-- 
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

Yes, you're right, thanks! I did make the mistake of typing (0 to 3) 
instead of (1 to 3).
I am glad I mistyped it and you noticed that it was not copied!

The reason why I use 1-based arrays is that else I can never say if an 
array is actually empty!

Let's take a real-life sample:

I have a public var name colMyCustomers() which is made of udts

Public Type udtCustomer
	FirstName as string
	LastName as string
	(etc...)
End Type

public sub GetCustomers()

	Redim colCustomers(0)

	dim r as dhrichclient.crecordset
	set r = cn.openrecordset("SELECT * FROM customers")

	redim colCustomers(1 to r.recordcount)
	dim l&
	for l = 1 to r.recordcount
		colCustomers(l).firstname = r!customer_firstname
		colCustomers(l).lastname = r!customer_lastname
		(etc...)
  	r.movenext
	next l

end sub

The later in the code when I access the array, I can simply say

For l = 1 to ubound(colcustomer)
	etc...
Next l

When the array is still empty, it will simply skip it.
What would I do if the array was 0 based?

I would have to store in another variable if the array is really empty 
or has 1 customer (=colCustomer(0)).

And if I had not redimmed the array to 0 (Redim colCustomers(0)), any 
attemps to do something like this

For l = 1 to ubound(colcustomer)
	etc...
Next l

would throw an error because the array is not dimmed.

Anything wrong with my method?



dpb wrote:
> GS wrote:
>> on 9/11/2010, Boris P. supposed :
>>> Hello!
>>>
>>> I am saving an array to a file and then load it again.
>>>
>>>
>>> Open sPath For Binary As #iFile1
>>>
>>> If uLoad Then
>>> Get #iFile1, , uArray
>>> Else
>>> Put #iFile1, , uArray
>>> End If
>>>
>>> My array looks like this:
>>>
>>> Redim myArr(1 to 3) as long
>>> myArr(1) = 100
>>> myArr(2) = 500
>>> myArr(3) = 10000
>>>
>>> When I load it again, I say:
>>>
>>> Redim MyNewArr(1 to 3) and call the above sub.
>>>
>>> For some reason, MyNewArr now looks like this:
>>>
>>> MyNewArr(0) = 100
>>> MyNewArr(1) = 500
>>> MyNewArr(2) = 3
>>>
>>> When I try to access MyNewArr(3) an out of bounds error is thrown.
>>>
>>> Can somebody please tell me how to save my array correctly so that it
>>> will start at 1 again, just like I declared it when redimming it?
>>>
>>> Thank you!
>>
>> By default arrays are zero based. So a 3 element array will always
>> begin with 0 and end with 2. You have to declare Option Base to 1 if
>> you want to go that way. However, I strongly recommend you modify your
>> thinking to use the default zero base. (It'll make life much easier!<g>)
>
> I'd say "it depends" on whether to use 0- or 1-based indexing, dependent
> upon the problem domain.
>
> Note that ReDim() should _not_ be used except for redimensioning, not
> for initial declarations -- see the Caution discussion in the language
> reference manual for ReDim.
>
> In short, the above code snippet should start w/ a
>
> Dim myArr() As Long
> ReDim myArr(1 to 3)
>
> There's a problem w/ the code and the symptoms described as well--I
> strongly suspect the code isn't as typed in (and can tell it isn't
> copied and pasted as the capitalization for keywords isn't consistent w/
> the VB stylistic pattern).
>
> The statement
>
> Redim MyNewArr(1 to 3)
>
> isn't complete, either, as the "As Long" clause is missing and the
> existence of the (1 To 3) if it were in the actual code would preclude
> the appearance of MyNewArr(0) as the upper and lower bound subscripts
> are explicitly given.
>
> I suspect that what you _actually_ have is
>
> ReDim MyNewArr(3)
>
> instead which would behave as GS notes assuming there is no
>
> Option Base 1
>
> statement in effect.
>
> Lesson to be learned -- when posting code that is to demonstrate a
> symptom, post the actual code and the symptom, not a paraphrasing of it.
>
> --

dpb wrote:
> GS wrote:
> ...
>
>> That was implied in the context of the OP's problem! Dumping a file
>> into an array with 'Get' will result in a zero-based array UNLESS
>> Option Base 1 is declared. That's all I was responding to.
> ...
>
> The Get doesn't really have anything to do with...unless the variable
> has been declared as a variable, it's a scalar and only a single value
> will be returned on the Get (ignoring the details of descriptors for
> dynamic strings/arrays or UDTs).
>
> The dimensions of the array are based on the Dim or ReDim used and the
> Option Base in effect at the time.
>
> The problem w/ OP's posting is that his posted code doesn't reflect the
> actual code--it's missing the definition of the calling sequence in the
> subroutine snippet and the location with respect to that of where he
> looked at the data and how. The array name he complains of isn't the
> same as the array name in the routine so it isn't that that caused the
> problem.
>
> There's also the problem noted above of whether he's reading/writing the
> same type of array -- if it was dynamic on Put, it needs to be dynamic
> matching on Get or he's going to get the descriptor information
> confounded w/ the data. Conversely, if Put a fixed-sized array, only the
> data (no descriptors) will be written and trying to read it into a
> dynamic array will confound the data w/ descriptors the other direction.
>
> The upshot still is, OP needs to post the actual code to be able to see
> precisely what caused the specific symptom(s) but he's got problems of
> inconsistency and poor practice at a minimum...
>
> --


My code is huge and I cannot post it without leaving out things, and to 
make it clear, I rewrote it on the fly.

But my actual problem was that when I declared/ dimmed/ redimmed it, I chose

Redim (1 to ...)
and saved it this way.

But before loading it again from the file on the disk, I said "Redim (0 
to ...)"

This caused the array to start at 0 instead of 1.

Learnt something...

Normally, I only use DBs to write my data, not binary files, that's why 
your statement of "lack of consistency and practice" is right in this case.

But the actual problem remains:

How would one know if an array is empty when it's zero based???

I don't understand people who use 0-based arrays because they have to 
use another variable to check if the array is really empty.

With 0-based I mean arrays that have data in the index 0 position.
I do use 0-based arrays as well, but it doesn't contain data at that 
position.

I only use it to check if the array is "empty" or not.

Perhaps everybody will understand my way of coding with this sample.
I think it's really beautiful code:

Private Sub Form_Load()

     Dim s() As String
     ReDim s(0)

     Debug.Print "We have " & UBound(s) & " items"
     Dim l&
     For l = 1 To UBound(s)
         'if array is redimmed to 0, it will simply skip here
         Debug.Print "Item value " & l & " is " & s(l)
     Next l

     ReDim s(1)
     Debug.Print "We have " & UBound(s) & " items"
     For l = 1 To UBound(s)
         Debug.Print "Item value " & l & " is " & s(l)
     Next l

End Sub

"dpb" <none@non.net> wrote in message 
news:i6hbvp$ovo$1@news.eternal-september.org...

> There's also the problem noted above of whether
> he's reading/writing the same type of array -- if it
> was dynamic on Put, it needs to be dynamic matching on Get or he's going 
> to get the descriptor
> information confounded w/ the data.  Conversely,
> if Put a fixed-sized array, only the data (no descriptors)
> will be written and trying to read it into a dynamic
> array will confound the data w/ descriptors . . .

Actually that is not true (unless the array happens to be a member of a UDT, 
which in the OP's case it does not appear to be). When writing an ordinary 
array (one that is not a member of a UDT) then Put writes /exactly/ the same 
data to the file regardless of whether that array is dynamic or fixed size.

For example, if the array is an array of Longs containing three elements 
then exactly 12 bytes will be written to the file, regardless of whether the 
array is dynamic or fixed size, and for a three element array of Doubles the 
data written would be 24 bytes, again regardless of whether it was a dynamic 
or fixed size array. Similarly, the data written to file for each element of 
a three element array of Variants would be a two byte value representing the 
Data Type of the element followed by however many bytes the contents of that 
specific element requires (which of course depends on its data type). But 
even then, exactly the same data would be written to the file regardless of 
whether the array was dynamic or fixed size.

Mike

"Boris P." <bpnotvalid@nospamhotmail.com> wrote in message 
news:%23GNuk8kULHA.4872@TK2MSFTNGP02.phx.gbl...

> My code is huge and I cannot post it without leaving
> out things, and to make it clear, I rewrote it on the fly.
> But my actual problem was that when I declared/
> dimmed/ redimmed it, I chose Redim (1 to ...) and
> saved it this way. But before loading it again from the
> file on the disk, I said "Redim (0 to ...)"

Well that is not what you said in your original post. In fact you said 
something quite different, and it is NOT because you failed to post your 
full project code (which is perfectly understandable) but it is in fact 
because you ADDED some code that was not actually there! If you post the 
wrong code, and especially if (as you did) you tell us you used code that 
you did not actually use, then you should expect the wrong answer! In any 
case, what you have just said still does NOT explain why after saving the 
following data . . .

           myArr(1) = 100
           myArr(2) = 500
           myArr(3) = 10000

.. . . you got back the following data . . .

           MyNewArr(0) containing the value 100
           MyNewArr(1) containing the value 500
           MyNewArr(2) containing the value 3

Where the hell did the "3" come from! What you did was to post code that you 
were not actually using, and also post results that you were not actually 
getting!

> My code is huge and I cannot post it without leaving
> out things, and to make it clear, I rewrote it on the fly.

Yes. We understand that you cannot post everything, but you really should do 
your best to post all of the code and declarations that are appropriate to 
the specific small part of the project you are having problems with, and you 
very definitely should write the code you are about to post into an actual 
VB code window, and you should check the results that the code you have just 
typed actually returns in a running VB project, so that you do not end up 
posting code that you did not actually use, or missing out important parts, 
and also so that you do not end up posting results that did not actually 
happen!

One other example example in this particular case is that we had no idea 
whether you had properly initially declared your dynamic arrays rather than 
using Redim on the fly to do it, and in view of the line Redim myArr(1 to 3) 
as Long which was contained in your posted code we quite reasonably assumed 
that you had not properly initially declared them (since it is not usual to 
specify the data type again in a Redim statement). In your case you 
specified the data type in the Redim statement for one array but you did not 
specify the data type in your Redim statement for the other array, an 
inconsistency which made it appear that you might possibly be using Redim on 
the fly rather than initially properly declaring your dynamic arrays, and an 
inconsistency which led us to make other quite reasonable assumptions about 
your code which were probably not correct, for example the assumption that 
MyNewArr might actually be an array of Variants. Now I know that if it was 
an array of Variants then you would have had other problems in your code 
that you did not appear to be having if your posted results of the Get were 
correct, but the fact that one of the values returned in your posted results 
was the number 3, which was clearly not what you were actually getting, 
caused us to treat those posted results with suspicion anyway.

If you want to get the best answers then you should post your question in 
the best way you can, otherwise you will end up having everyone else 
guessing what you have actually done and unnecessarily running around in 
circles on your behalf.

Essentially, if you want people to do some work answering your question (as 
the people here do) then you should be prepared to do at least a similar 
amount of work asking it.

Mike

Boris P. wrote:
> But the actual problem remains:
>
> How would one know if an array is empty when it's zero based???
>
> I don't understand people who use 0-based arrays because they have
> to use another variable to check if the array is really empty.

Or they use error trapping (errors are information, not failures). Or
they probe the SAFEARRAY structure -- as does our Stamina library,
which has a function (DxArrayDims) that returns the number of
dimensions in an array. It returns 0 if the array is currently
undimmed.

There's nothing wrong what you're doing, but some (like me) find it a
bit odd.

-- 
     Jim Mack
     MicroDexterity Inc     www.microdexterity.com

"Boris P." <bpnotvalid@nospamhotmail.com> wrote in message 
news:eqmkeHlULHA.4576@TK2MSFTNGP04.phx.gbl...

> Perhaps everybody will understand my way of coding
> with this sample. I think it's really beautiful code:
>     Dim s() As String
>     ReDim s(0) Debug.Print "We have " & UBound(s) & " items"
>     Dim l&
>     For l = 1 To UBound(s)
>         'if array is redimmed to 0, it will simply skip here
>         Debug.Print "Item value " & l & " is " & s(l)
>     Next l

Well, each to his own I suppose. The contents of a file only really make 
sense to code that knows the format of the data, and since it is your own 
data and your own file then that's okay. It's just a bit unusual. By the 
way, your code above will fail with a Subscript Out Of Range error if you 
happen to paste it into a module that is using Option Base 1.

Mike

 From a certain project size on and with lots of tweaks like subclassing 
and altering tables, VB6 crashes at simple errors, that's why I try to 
avoid errors like hell.

Jim Mack:
> Boris P. wrote:
>> But the actual problem remains:
>>
>> How would one know if an array is empty when it's zero based???
>>
>> I don't understand people who use 0-based arrays because they have
>> to use another variable to check if the array is really empty.
>
> Or they use error trapping (errors are information, not failures). Or
> they probe the SAFEARRAY structure -- as does our Stamina library,
> which has a function (DxArrayDims) that returns the number of
> dimensions in an array. It returns 0 if the array is currently
> undimmed.
>
> There's nothing wrong what you're doing, but some (like me) find it a
> bit odd.
>

  Mike Williams:
> "Boris P." <bpnotvalid@nospamhotmail.com> wrote in message
> news:%23GNuk8kULHA.4872@TK2MSFTNGP02.phx.gbl...
>
>> My code is huge and I cannot post it without leaving
>> out things, and to make it clear, I rewrote it on the fly.
>> But my actual problem was that when I declared/
>> dimmed/ redimmed it, I chose Redim (1 to ...) and
>> saved it this way. But before loading it again from the
>> file on the disk, I said "Redim (0 to ...)"
>
> Well that is not what you said in your original post. In fact you said
> something quite different, and it is NOT because you failed to post your
> full project code (which is perfectly understandable) but it is in fact
> because you ADDED some code that was not actually there! If you post the
> wrong code, and especially if (as you did) you tell us you used code
> that you did not actually use, then you should expect the wrong answer!
> In any case, what you have just said still does NOT explain why after
> saving the following data . . .
>
> myArr(1) = 100
> myArr(2) = 500
> myArr(3) = 10000
>
> . . . you got back the following data . . .
>
> MyNewArr(0) containing the value 100
> MyNewArr(1) containing the value 500
> MyNewArr(2) containing the value 3
>
> Where the hell did the "3" come from! What you did was to post code that
> you were not actually using, and also post results that you were not
> actually getting!
>
>> My code is huge and I cannot post it without leaving
>> out things, and to make it clear, I rewrote it on the fly.
>
> Yes. We understand that you cannot post everything, but you really
> should do your best to post all of the code and declarations that are
> appropriate to the specific small part of the project you are having
> problems with, and you very definitely should write the code you are
> about to post into an actual VB code window, and you should check the
> results that the code you have just typed actually returns in a running
> VB project, so that you do not end up posting code that you did not
> actually use, or missing out important parts, and also so that you do
> not end up posting results that did not actually happen!
>
> One other example example in this particular case is that we had no idea
> whether you had properly initially declared your dynamic arrays rather
> than using Redim on the fly to do it, and in view of the line Redim
> myArr(1 to 3) as Long which was contained in your posted code we quite
> reasonably assumed that you had not properly initially declared them
> (since it is not usual to specify the data type again in a Redim
> statement). In your case you specified the data type in the Redim
> statement for one array but you did not specify the data type in your
> Redim statement for the other array, an inconsistency which made it
> appear that you might possibly be using Redim on the fly rather than
> initially properly declaring your dynamic arrays, and an inconsistency
> which led us to make other quite reasonable assumptions about your code
> which were probably not correct, for example the assumption that
> MyNewArr might actually be an array of Variants. Now I know that if it
> was an array of Variants then you would have had other problems in your
> code that you did not appear to be having if your posted results of the
> Get were correct, but the fact that one of the values returned in your
> posted results was the number 3, which was clearly not what you were
> actually getting, caused us to treat those posted results with suspicion
> anyway.
>
> If you want to get the best answers then you should post your question
> in the best way you can, otherwise you will end up having everyone else
> guessing what you have actually done and unnecessarily running around in
> circles on your behalf.
>
> Essentially, if you want people to do some work answering your question
> (as the people here do) then you should be prepared to do at least a
> similar amount of work asking it.
>
> Mike
>
>
>

Sorry, I become only assured of what I'm doing after all the responses here.
Over the years I did it without thinking about it, so I was sure I 
posted all info that was needed. Of course with your questions and tipps 
I found out that it's not as I thought it was.

Mike Williams wrote:
....

> Actually that is not true (unless the array happens to be a member of a 
> UDT, which in the OP's case it does not appear to be). When writing an 
> ordinary array (one that is not a member of a UDT) then Put writes 
> /exactly/ the same data to the file regardless of whether that array is 
> dynamic or fixed size.
....

For Binary mode that's true, indeed.  I should have noted the Open was 
included in OP's posting, sorry.

--

"Boris P." <bpnotvalid@nospamhotmail.com> wrote in message 
news:eqmkeHlULHA.4576@TK2MSFTNGP04.phx.gbl...
> Perhaps everybody will understand my way of coding with this sample.
> I think it's really beautiful code:
>
> Private Sub Form_Load()
>
>     Dim s() As String
>     ReDim s(0)
>
>     Debug.Print "We have " & UBound(s) & " items"
>     Dim l&
>     For l = 1 To UBound(s)
>         'if array is redimmed to 0, it will simply skip here
>         Debug.Print "Item value " & l & " is " & s(l)
>     Next l
>
>     ReDim s(1)
>     Debug.Print "We have " & UBound(s) & " items"
>     For l = 1 To UBound(s)
>         Debug.Print "Item value " & l & " is " & s(l)
>     Next l
>
> End Sub

See IsDimmed() here as an alternative:

http://groups.google.com/group/microsoft.public.vb.enterprise/msg/6925f09068af63a5

It uses error trapping. Here is ArrayDimmed() that doesn't use error 
trapping:

http://groups.google.com/group/microsoft.public.vb.general.discussion/msg/8d0862e83b1a27cc

"Boris P." <bpnotvalid@nospamhotmail.com> wrote

> From a certain project size on and with lots of tweaks like subclassing
> and altering tables, VB6 crashes at simple errors, that's why I try to
> avoid errors like hell.

Altering V-Tables?

That's a bit funny.  You hack into Windows messages, and maybe
muck about with VB's jump tables....

.... but try to handle data in a file and you find VB isn't doing what
you want!

Priceless!
LFS

dpb wrote:
> Mike Williams wrote:
> ...
> 
>> Actually that is not true (unless the array happens to be a member of 
>> a UDT, which in the OP's case it does not appear to be). When writing 
>> an ordinary array (one that is not a member of a UDT) then Put writes 
>> /exactly/ the same data to the file regardless of whether that array 
>> is dynamic or fixed size.
> ...
> 
> For Binary mode that's true, indeed.  I should have noted the Open was 
> included in OP's posting, sorry.

Actually, was really responding more to the GS posting that seemed to 
indicate that somehow the Get operation was dynamically assigning memory 
and somehow affecting what the array indices were going to be and then 
got off into thinking how anything could affect the OPs symptoms and 
that led to the thinking of Random, not Binary access and from there the 
rest followed... :)

--

"Boris P." <bpnotvalid@nospamhotmail.com> skrev i meddelandet 
news:eqmkeHlULHA.4576@TK2MSFTNGP04.phx.gbl...
> Perhaps everybody will understand my way of coding with this sample.
> I think it's really beautiful code:
>
> Private Sub Form_Load()
>
>     Dim s() As String
>     ReDim s(0)
>
>     Debug.Print "We have " & UBound(s) & " items"
>     Dim l&
>     For l = 1 To UBound(s)
>         'if array is redimmed to 0, it will simply skip here
>         Debug.Print "Item value " & l & " is " & s(l)
>     Next l
>
>     ReDim s(1)
>     Debug.Print "We have " & UBound(s) & " items"
>     For l = 1 To UBound(s)
>         Debug.Print "Item value " & l & " is " & s(l)
>     Next l
>
> End Sub

What is wrong about Erase, except you have to deal with an error?

/Henning