Passing information to called form

I thought this would be easy. According to this article, it is:
http://www.informit.com/articles/art...&seqNum=7&rl=1
Of course I'd rather access public properties than a public variable but it doesn't really matter what I'd rather do because it isn't working! Of course I'm trying to pass an integer but when I enter MyForm.MyInteger=2 I get the error "MyInteger is not a member of System.Windows.Forms.Form".

Does this work only for forms?

Thanks.

The Form class has no MyInteger member, as the error message says. You need to create your own form class that inherits Form, which is what you do every time you create a form in the designer. You then give THAT class a member named MyInteger. Now you can declare a variable of THAT type, not the Form type, create an instance of THAT type and set its MyInteger member.

I suggest that you read the first link in my signature. It is also a good tutorial on using forms.

A form is like any other object in .Net. If you want form2 to have it as a property, use the following code in Form2:

VB Code:

Public Property MyInteger Property as Int32

Intellisense will populate the rest of the property (I would, but I don't have an IDE infront of me). All you need to do is place a "Return MyInteger" in the get and a "MyInteger = Value" in the set. After that, you can return and change the value regardless of scope.

If you just want to retreive and not let other objects change it, declare MyInteger as private and then add a ReadOnly before the "Property" in the example I gave.

Edit: And also, check out his link. It's great information.

gooo Multi Forms Tutorial! :)

OK, then the problem is creating a variable of type MyForm because the code in Form1 doesn't recognize the type MyForm-it says 'MyForm is undefined'.

Here's the code in MyForm:

Public Class MyForm Inherits System.Windows.Forms.Form
Private MyPrivateInteger as Integer
Public Property MyInteger as Integer
Get
Return MyPrivateInteger
End Get
Set (ByVal Value as Integer)
MyPrivateInteger = Value
End Set
End Property
End Class

Here's the code creating & calling it:

Dim MyAssembly as Reflection.Assembly
Dim MyType as Type
Dim MF as Form
Dim MyResult as Windows.Forms.DialogResult
MyAssembly=Reflection.Assembly.LoadFrom(Application.StartupPath & "\myDLL.DLL")
For Each MyType in MyAssembly.GetTypes
If MyType.Name = "MyForm" Then
MF = DirectCast(Activator.CreateInstance(MyType),Form)
MF.MyInteger=2
MyResult=MF.ShowDialog()
End If
Next

If I declare MF as MyForm then I get "MyForm is not defined" & the form doesn't get created. I get the same error if I declare MF as Form & then cast the created object as MyForm.

If I declare MF as Form & cast the created object as Form then the form gets created but MyInteger doesn't get set because it's not a member of class Form-only of class MyForm.

Now it seems to me that this is the same problem that should result from the demos in the tutorials-both of them. Either you should get an error when declaring the second form or you should get the error when setting the property of the second form. If you don't get the error in the demos then why do I get it here?

OK, first off, if you are trying to create an instance of a type that exists in an assembly that your project doesn't have a reference to then of course it will tell you that the type is not defined. Your project knows nothing about that assembly or what it contains at compile time so it cannot use types defined in that assembly. You can't cast anything as that type for the same reason.

If you are accessing an object through a variable of type Form then the only members accessible to you are those of the Form type. If you want to access members of the specific type then you're going to have to use reflection to do so. This is for the same reason as before: your project knows nothing about the types or their members in the assembly at compile time. You could turn Off Option Strict and use late binding but that's a bad idea.

The crux of this is why are you using reflection in the first place? Are these libraries you're accessing supposed to be plug-ins or something like that? If so, you should be defining one or more interfaces that these types can implement. That way you can always cast the objects created to instances of that interface and then you have design time access to the members of that interface.

And the short answer is that I don't know why the original programmers used reflection. I know why I use it-because I got it working by copying some of what the original programmers did-but I don't know why they did it that way.

So, it appears that I can either use reflection to access the properties of MyForm, or I can add a reference to the project that contains MyForm-right? It sounds easier to add a reference, so why didn't the original programmers do it? It's not a new project-I'm adding MyForm to one of their projects.

I'm not clear on why the project doesn't know about the assembly-it uses it when it creates the instance of MyForm so why doesn't it know about it? Actually that's sort of rhetorical-obviously it's looking in different places to see what it knows about, depending on what it's trying to do.

The libraries aren't plug-ins, in fact the only reason I can see for the items being split up into libraries is to make it easier for multiple people to work on the application. Maybe to manage (there are around 1700 items) but splitting them up like this seems to create enough obstacles to communication that it seems like it's got to be for a better reason than that.

Regardless of the original reason though, I'm stuck with the results. Given the way the app is already written then I think I'll need to develop a thorough understanding of reflection to maintain it. Any suggestions, please?

Thanks.

And, although I still think that I'll need to understand reflection to maintain this app, your answer still gave me the clue I needed, JM. Thanks. Since I see no reason why the items are split into projects I decided to add my new project to the same project as it was being called from. Duh-would have made everything a lot easier if I'd just done that in the first place.

Thanks.