[RESOLVED] Object not set error

Hello,

This should be an easy thing to do, but I can't figure out what I am doing wrong.

I have a codejock report control on the main form that list users in a database. After a new user is added thru a different form, I want the list to update. This should be easy, but I get an "object reference not set to an object" error. The code that does the update is in a class. When the user selects the option to view the users, then report control is passed byref to the sub as a parameter. On the second form I dim frm as frmMain(my main form that holds the report control) and do frm.PEPReportControl when I call the sub. The code is below of two of the things I have tried.

My form class is public, my class is public. I have done searching on the web, but haven't found any help. Also, I don't get any lines under the code. I have tried creating a reference to the form, and the control type, and pass that in the parameter, but that didn't work either.

Any help would very good. Thank you.

VB Code:

Try
     Dim frm As frmMain
     Dim RC As AxXtremeReportControl.AxReportControl = frm.PEPReportControl
     MyServerControl.AddUser(Me.UserName.Text.ToString, Me.Password.Text.ToString, Me.FName.Text.ToString, Me.LName.Text.ToString)
     MyFormControl.PopulateReportControlUserInfo(RC)
     frm = Nothing
     Me.Hide()
Catch ex As Exception
     MessageBox.Show(ex.ToString)
End Try

VB Code:

Try
    Dim frm As frmMain
    MyServerControl.AddUser(Me.UserName.Text.ToString, Me.Password.Text.ToString, Me.FName.Text.ToString, Me.LName.Text.ToString)
    MyFormControl.PopulateReportControlUserInfo(frm.PEPReportControl)
    frm = Nothing
    Me.Hide()
Catch ex As Exception
    MessageBox.Show(ex.ToString)
End Try

Sorry, forgot to add that this is VS2003.

frm as new frmmain

Mmmmm 'kaaaay.... Despite the rumors to the contrary, most of us are not mind readers.... so, could you point out what line causes the error?

-tg

Sorry, I thought that I did a good enough job of verbally expressing that the error was caused on the line that I pass the reference to the report control on, and that populates the report control. Since that line has the word "ReportControl" and populate in it, I thought that would be enough. I am not trying to be crappy, just trying to point out that I was not expecting you to read my mind, but did make an effort to give enough information.

I will try new in the reference to the form, but I have a question about that. Does the new create a new instance of the form, or just a new pointer to that form? That should probably be obvious, but I am new to .NET, sorry.

You cannot simply pluck a reference to an existing object out of thin air. If you want to create a new instance of your form class then you use the "New" key word to do so. If you want to refer to an existing instance of that class then you need to get a reference to that existing instance. Remember, you could have thousands of existing instances of that same class, so how would the app know which one you want if you don't specify?

Dim frm As New frmMain will create a new instance of frmMain, and I believe it's not what you want. If you want a reference back to the main form in the current form, you should set its Owner property to the main form. Do something like this:

VB Code:

'In main form
Dim frm2 As New Form2
frm2.Owner = Me
frm2.Show

Then in the 2nd form you do this

VB Code:

Dim frm As frmMain = DirectCast(Me.Owner, frmMain)
Dim RC As AxXtremeReportControl.AxReportControl = frm.PEPReportControl
'... blablabla...

jmcilhinney, that makes sense. I understand that, that is why I didn't try the new word. I thought that would create a new instance of the form. I want to refer to the form that is already instanced. In visual basic 6 I would just go frmMain.PEPReportControl, but that doesn't work in .NET (which I am sure you already know), and I did a search on the site and found that I have to dimension the form Dim frm as frmMain. That allows me to access controls on the form, so if I wanted to pass text from form two to form one, from what I read, that would work, so I thought that it would work in passing a reference to the control thru a parameter to the sub, but it didn't. So, I am not sure where to go from here. I tried the new word, and no errors were given, and I stepped thru the code, and it all functioned well, but it did not populate the list. This make me think that the new work created a new instance of the form, not reference the one I already have. So, I guess my question is now, how do I reference the form and control that I already have in .NET?

Thank you for your help.

Quote:

---

Originally Posted by stanav

Dim frm As New frmMain will create a new instance of frmMain, and I believe it's not what you want. If you want a reference back to the main form in the current form, you should set its Owner property to the main form. Do something like this:

VB Code:

'In main form
Dim frm2 As New Form2
frm2.Owner = Me
frm2.Show

Then in the 2nd form you do this

VB Code:

Dim frm As frmMain = DirectCast(Me.Owner, frmMain)
Dim RC As AxXtremeReportControl.AxReportControl = frm.PEPReportControl
'... blablabla...

---

You should be aware of exactly what setting the Owner of a form does. The owned form becomes a modeless dialogue of the owner. That means that the owned from will always be displayed over the owner, it will be minimised and restored with the owner and it will be closed with the owner. If that's what you want then fine but it's a problem if that's not what you want.

If you're displaying the owned form as a modal dialogue, i.e. calling ShowDialog, then it's no issue because the modal behaviour overrides the modeless anyway. If you're calling Show though, it may well be an issue.

Basically, if the second form needs to refer to the first form then the first form needs to pass the second from a reference to itself. That's exactly what setting the Owner does, but if you don't want to create an owned form then it's a simple case of providing your own property or method to do it. If the seconf form is ALWAYS going to created by the first form then the logical solution is to pass the reference to the constructor. That way you don't need to cast the Owner property either, because your variable or property will already be the correct type.

Note that, as always, this OOP behaviour mimics the real world. Let's say that you send someone off to do a job for you and you want them to contact at some point while they're doing it, how can they do so if they don't have your contact details? You might give them your phone number, which is the equivalent of passing them a reference to you. A reference is just a way to get access to an object.

I strongly suggest that you read the "Forms in VB.NET" tutorial in my signature, which addresses some of these points. I'd also suggest that you read the OOP section from the Start VB.NET tutorial.

Most importantly though, you need to remember that forms are objects and behave in exactly the same way as any other objects. Every form you design in the IDE is not an object. It is a class, i.e. a type. At run time, each form you create is an object, i.e. an instance of that type. You only create one form in the IDE but you can create an unlimited number of instances of that type.

Thank you Stanav for that information.

jmcilhinney, I will read the information in your signature. I taught myself vb 6, and I am learning VB .NET on my own as well, so thank you for that detailed explanation. OOP makes sense, but sometimes it is hard for me to think OO. I am reading Microsoft's Programming Visual Basic .NET version 2003, and they discuss OOP, sometimes I have to stop and say, "What?" because it seems complex, but I enjoy it very much. Anyway, enough blabbing. While I was reading your post, during the part about modeless and showdialog, I remembered that I was showing this modal, or showdialog, and I remembered that code execution stops at the showdialog line until the form is hidden, so instead of populating the report control from frmUser (the second form) I hide the form, then execute the populate report control sub right after the show dialog line, since it is in frmMain, I just put Me.PEPReportControl. Then I dispose of frmUser.

Again, thank you for suggesting the information about forms, and for the information that you posted.

Ben

If you're displaying a modal dialogue then it is generally not appropriate for the dialogue to access the caller. The more correct way to do it is for the dialogue to expose whatever data is required via properties or methods and for the caller to retrieve it once ShowDialog returns. Here's an example of what that might look like.

In Form1:

VB Code:

Dim f2 As New Form2
 
If f2.ShowDialog() = Windows.Forms.DialogResult.OK Then
    'Get the data from the dialogue and display it.
    Me.TextBox1.Text = f2.Value1
    Me.TextBox2.Text = f2.Value2
End If
 
f2.Dispose()

It's up to you to declare the appropriate properties in Form2 to expose the required data, e.g.

VB Code:

Public ReadOnly Property Value1() As String
    Get
        Return Me.TextBox1.Text
    End Get
End Property
 
Public ReadOnly Property Value2() As String
    Get
        Return Me.TextBox2.Text
    End Get
End Property

Now the dialogue is completely independent of the caller. The dialogue just appears, does its thing and disappears and this can be done from anywhere at any time. The Form2 doesn't care who calls it when or where. It just exposes the appropriate data and whoever wants it can get it. That's much better than the dialogue depending on being called by a specific type of form.

So then I should move the code that calls the sub to add the user to the database from the modal form to the main form, correct?

Also, this form is for adding and editing users in the database. With the editing, should I make the properties both get and set? Then when I create and instance of the form I can load the values into the properties, then in the set put me.username.text = value?

That all sounds reasonable. There's also another option. Your caller could pass a DataRow to the dialogue. The dialogue could then edit that DataRow directly and neither form needs to access the other at all. When the user presses the OK button the dialogue simply updates the DataRow object it was passed and that's it. Those changes will be reflected in the caller because it references the same DataRow object.

Form1:

VB Code:

Private Sub AddNewRow()
    Dim dr As DataRow = myDataTable.NewRow()
    Dim f2 As New Form2(dr)
 
    If f2.ShowDialog() = Windows.Forms.DialogResult.OK Then
        myDataTable.Rows.Add(dr)
    End If
End Sub
 
Private Sub EditExistingRow(ByVal index As Integer)
    Dim f2 As New Form2(myDataTable.Rows(index))
 
    f2.ShowDialog()
End Sub

Form2:

VB Code:

Private data As DataRow
 
Public Sub New(ByVal data As DataRow)
    ' This call is required by the Windows Form Designer.
    InitializeComponent()
 
    ' Add any initialization after the InitializeComponent() call.
 
    Me.data = data
 
    Me.TextBox1.Text = CStr(data("Column1"))
    Me.TextBox2.Text = CStr(data("Column2"))
End Sub
 
Private Sub okButton_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles okButton.Click
    Me.data("Column1") = Me.TextBox1.Text
    Me.data("Column2") = Me.TextBox2.Text
End Sub

That's true, I already did the first option, but I am going to be thinking about this project before I go to bed, so I will definently give it some more thought.

Thank you for your help.