keeping reference between class instances and my child forms in MDI environnment

[tutus]

Hi guys,

1/ I have an MDI form where I open from a toolbar button instances of fAccount form: fAccount1, fAccount2 linked to the objects oAccount1, oAccount2.....

also I have a toolbar button in the MDI parent form, that I click and it opens Memos forms: fMemo1,fMemo2..... Each fMemoN is linked to oMemoN and to fAccountN and to oAccountN.

Like this:

fAccount3 is linked to oAccount3 and oMemo3 belongs to oAccount3

the fMemoN form is linked to oMemoN object instance that s linked to one specific instance of fAccount.

My question: from the MDI parent form: how do I keep refernce between all the instances .

The purpose: when I have a specefic instance of fAccount form active, I can open its related oMemo object and not an oMemo object that belongs to another fAccount

P.S sorry if what I wrote doesn t make sense.

Thanks guys.




--------------------------------------------------------------------------------
R.tutus

[jmcilhinney]

This is what OOP is all about.

You create a Memo object.

You create an Account object and assign the Memo object to an appropriate property. The Account object now has a reference to the Memo object and can acll its methods, get and set its properties.

You create a Memo form and pass the appropriate Memo object to its constructor. The Memo form now has a reference to the Memo object, which it can use to affect that object.

You create an Account form and pass the appropriate Account object to its constructor. The Account for now has a reference to the account object, which in turn has a reference to the Memo object.

I suggest that you read the "Forms in VB.NET" tutorial in my signature.

Also, it's very important to realise that the whole point of OOP is to mimic the real world. Let's say that you and I don't know each other but we have a mutual friend. That friend gives me your phone number, so now I can contact you directly. We are all objects and that friend just passed me a reference to you, so I now have a way to access your properties and methods. If I then pass that phone number to another person, I just passed them a reference to you too. That's exactly how OOP works. Objects pass references to other objects around. If there is an object named Object1 then any other object that has a reference to Object1 can access its properties and methods. If your main form creates a Memo object then it must pass a reference to that Memo object to a Memo form so that the memo form can access the members of the Memo object.

[tutus]

beautiful explanantion. 2 questions though or 3 pls: when u say:
1/You create an Account object and assign the Memo object to an appropriate property
How do I implement that?
do u mean: in clsAccount class, i should have a property of type: Memo or did u mean we can do it some other and better way

2/ Objects pass references to other objects around. If there is an object named Object1 then any other object that has a reference to Object1 can access its properties and methods
is the way to implement that basically throgh contructor when we first instatiate the object. (it s almost close to first question. not sure)

3/ where is your tutorial what s the link. and let me know if there is any other Microsoft article (practical with examples pls)

Thanks a lot amigo

[jmcilhinney]

1. When you want to get data from a database you need to use a Connection object and a Command object. You create the Connection object and then assign it to the Connection property of the Command object. When you execute the Command it uses the Connection that you passed it the reference to.

You situation is the same. You declare a property in the Account class of type Memo. Generally that will look much like this:

Private _memo As Memo
 
Public Property Memo() As Memo
    Get
        Return Me._memo
    End Get
    Set(ByVal value As Memo)
        Me._memo = value
    End Set
End Property

Now, within your Account class you use the _memo variable, which refers to the Memo object that the caller passed to the Memo property. You might also add a constructor that has an argument of type Memo, so the reference can be passed when the object is created. If all Acounts MUST have a Memo then it would be appropriate to make it the only constructor, so it's impossible to create an Account without a Memo.

2. It depends. Many classes have multiple constructors and multiple properties and methods that will set the same internal references. For instance, going back to my data example, the Command classes have several constructors. You can pass a Connection a constructor or you can set the Connection property explicitly after the object has been created. What's best for you really depends on your individual circumstances. It's often preferable to be able to set some properties via the constructor, particularly if that property has to be set in order for the object to be useful. You don't want your constructors' argument lists getting too long though.

3. I haven't written any tutorials myself. I've just provided links to stuff that I've found on the Net that I consider useful. Look at the Tutorial section of my signature particularly, but there's other useful stuff there too.

[tutus]

I got that. Now to help me go further in my learning. let s say we re talking about a Phone account. Each account has few subscribers (objects representing phone numbers along with their other properties like serial number, model, activation date....)
So an account object as several Subscriber objects. And an Account object also has several Invoice objects (Invoice for each month)
An idea how I can implement that.
One thing though: I will get the list of Subscribers that belong to the account number fro the database (this section is fine). So from the datasets need to create of subscriber collection or arraylist or hashtable. I heard of these terms but I don t know concretly how to implement my subscriber items to belong to the account object
Thank you.

[tutus]

Also, in the explanantion above:
I create a memo property in my account class.
Question pls: Do I also need to create a Account property in my Memo class as well. especially if I want to use the account object in my Memo instance code; or do I have another means to access the account object from Memo instance without adding Account property in my Memo class.
Thanks amigo.

[jmcilhinney]

When one object has to have references to an indeterminate number of another type of object you should declare one property of a collection type. You use this sort of setup all the time. Many controls, including ComboBoxes and ListBoxes, have an Items property. It is a collection to which you can Add, Insert and Remove. You would the same thing. You would define your own class named SubscriberCollection that inherited CollectionBase. You would then declare a read-only property in your Account class named Subscribers, which would be of type SubscriberCollection. That allows you to do this sort of thing:

Dim myAccount As New Account
Dim mySubscriber As New Subscriber
 
myAccount.Subscribers.Add(mySubscriber)

As for your Memo and Account objects needing to reference each other, that situation is best avoided if possible but if it's necessary then you can do something like this in your Account class:

Private _memo As Memo
 
Public Property Memo() As Memo
    Get
        Return Me._memo
    End Get
    Set(ByVal value As Memo)
        Me._memo = value
 
        If Me._memo.Account IsNot Me Then
            Me._memo.Account = Me
        End If
    End Set
End Property

You would do something similar in the Memo class so that whenever one of them was passed a reference to the other, it would automatically pass a reference to itself over to the other. That way as soon as one knows about the other they both do. That's like if our aforementioned mutual friend gives me your phone number I immediately ring you up and give you mine.

[tutus]

what s the part of code to say that: SubscriberCollection is a collection of Subscriber class. I think it s not enough to write that it inherits from CollectionBase

2/ this part of code is it just for security or precaution:
If Me._memo.Account IsNot Me Then
Me._memo.Account = Me
End If
i don t see why u added it
Thanks a lot

[jmcilhinney]

You should read about the CollectionBase class and see how to use it to create a strongly-typed collection. You're basically reproducing the functionality of the ArrayList, which CollectionBase wraps, but for a specific type rather than for Object, which can be anything. The Add Method of your collection class would look like this:

Public Function Add(ByVal value As Subscriber) As Integer
    Return Me.InnerList.Add(value)
End Function

The InnerList is the wrapped ArrayList. You're basically creating a pass-through method for the ArrayList's Add method but you're ensuring that the object added is a Subscriber.

The idea of that code is that if you create a Memo object and assign it to the Memo property of an Account object, that Account object will assign itself to that Memo object's Account property, but ONLY if it isn't already. If you didn't include the If statement then you'd end up with a never-ending loop of the two objects assigning themselves to each other's properties. You'd assign the Memo to the Account, which would assign itself to the Memo, which would assign itself to the Account, which would assign itself to the Memo, ad infinitum until you got a stack overflow. The If statement makes sure that only one assignment is made in each direction.

[tutus]

Thank you for your helpefulness jmcilhinney