Question Arrays in Classes?

[samboy29]

Hello, bit of a newb question sorry. I am having trouble figuring out what I am doing wrong when trying use arrays with classes.

For my class declaration I have

Public Class ClassWord

    Public NativeWord As String
    Public ForiegnWord As String
    Public ... (cropped the rest)

End Class

This is all under a class filetype

I have declared the following at the start of frmMain

Public Word() As ClassWord

Then I (try) to add values. This is the part that gives me an error message "Object reference not set to an instance of an object."

        Word(0).NativeWord = "Boy"
        Word(0).ForiegnWord = "Pojke"

        Word(1).NativeWord = "Girl"
        Word(1).ForiegnWord = "Flicka"

I figure it is some simple error on my part but I'm drawing a blank. Any help would be greatly appreciated.

Cheers.

 

[jmcilhinney]

One problem is that you are declaring your array variable but you are not creating your array object. That's why, when you try to use the variable, it doesn't refer to an object. In order to create an array you MUST, either implicitly or explicitly, specify its size. Arrays are fixed length, i.e. once you create one you cannot change its length, so you obviously have to know what that length is to create it. This code declares a variable, creates a object and assigns the object to the variable:

Dim arr As SomeType() = New SomeType(UPPER_BOUND) {}

The left-hand side is the declaration, the right-hand side is the object creation and the = is the assignment. That code would normally be abbreviated to this:

Dim arr(UPPER_BOUND) As SomeType

The analogous code for a discrete object rather than an array would be this code:

Dim obj As SomeType = New SomeType

being abbreviated to this:

Dim obj As New SomeType

Now, that takes care of one of your problems, i.e. the creation of the array, but you still have another issue. Once you create the array, all its elements are Nothing. Consider an egg carton. Just because you make an egg carton doesn't mean that you can make scrambled eggs. You have to put eggs into it in the first place in order to get eggs out of it. The same goes for an array. Each element of the array works just like a regular variable. Just as a variable is Nothing until you assign an object to it, so too an array element is Nothing until you assign an object to it. So, if you create an array with N elements, you then have to create N objects and assign each one to an element.

I think you really need to think about whether you want an array at all. Arrays have there place but, in many situations, a collection is more natural. Do you know exactly how many ClassWord objects you will have? If so then an array is appropriate. If not then you should be using a collection instead, probably a List(Of ClassWord). Collections provide array-like behaviour but they also have ability to grow and shrink dynamically. You start by creating a List object and then, to populate it, you create a ClassWord object and call the Add method. The List will grow by one item each time you call Add or Insert. Likewise, you can call Remove and the collection will shrink by one item.

 

[Herman]

Arrays being fixed size forever isn't strictly true; you can still use ReDim Preserve to resize it, although at a performance loss.

 

[JohnH]

Arrays being fixed size forever isn't strictly true; you can still use ReDim Preserve to resize it, although at a performance loss.

Arrays are always fixed. Redim statement creates a new array, Preserve statement copies the values from the old array to the new. The same operations goes on in collections internally, though with some smartness.

 

[Herman]

Yes it does copy the content to a new array, but to the programmer this is transparent. The method of resizing is irrelevant to the final result. The resulting array still has the same name and data, and has changed size.

I do agree that using collections is much better though even if the performance impact of using ReDim is irrelevant to a particular case, just for ease of reading the code.

 

[JohnH]

The resulting array still has the same name and data, and has changed size.

An array doesn't have a name, a variable has a name. Variables are placeholders that can be assigned memory data or references to objects in memory, such as an array object.
By the way, same can also be achieved with the shared Array.Resize method, that has same behaviour as Redim Preserve.

 

[jmcilhinney]

Yes it does copy the content to a new array, but to the programmer this is transparent. The method of resizing is irrelevant to the final result. The resulting array still has the same name and data, and has changed size.

I do agree that using collections is much better though even if the performance impact of using ReDim is irrelevant to a particular case, just for ease of reading the code.

That is not true. Try this code for example:

Dim arr1(9) As String
Dim arr2 As String() = arr1

MessageBox.Show(arr1.Length.ToString(), "arr1.Length")
MessageBox.Show(arr2.Length.ToString(), "arr2.Length")

ReDim arr1(19)

MessageBox.Show(arr1.Length.ToString(), "arr1.Length")
MessageBox.Show(arr2.Length.ToString(), "arr2.Length")

Because arrays are reference type objects, creating a new array and assigning it to a variable to replace another array doesn't have any effect any other variable that that same array was assigned to. So, contrary to what you posted, arrays being fixed-size is strictly true. In most cases, it effectively makes no difference, but it is absolutely true that an array object cannot be resized.

As i said, arrays do have their place and should be used any time that your list of items will not change size. For myself, I might consider using an array if I would or might only need to resize maybe once, but I'd basically use a collection any other time.