Printable View
I have two nearly identical forms (only one of which is loaded into a Panel at a time.) I want to read the value of an object that appears on both forms using a single command:
(Sample code)
Is there a way to do this?Code:Dim RandomForm as new Form ' I know this doesn't work.
If X = 1 then RandomForm = Form1
If X = 100 then RandomForm = Form2
RandomForm.Label1.Text = X ' There is a "Label1" on both forms.
TIA
Without using late binding, you need a common type that contains Label1 and to use that rather than Form. There are two options for that.
Firstly, you can create a common base class. You can create a form and add Label1, then you can have these other two forms inherit that. You would then use the base class to refer to either of the derived types and access the common member(s).
Secondly, you can define a common interface and have both forms implement that. The two forms would each have their own member(s) but you specify that they implement the member(s) of the same name from the interface. You would then use the interface to refer to either of the concrete types and access the common member(s).
You should do a bit of research on inheritance and interface implementation.
Thx for the reply.
I'm probably too much of a Newbie to understand "Common Base Class". If I understand correctly, this would be a third "universal" form containing all the elements of Form1 & Form2. That's not really an option. "Label1" was just a simplified example. The actual situation is far more complex. :(
Whenever I reach for a common base class, I end up re-writing to use an interface instead....eventually, though it could be quite a while later. Partially for that reason, and partially because once you have one you always find other uses for it, I would say that an interface is the right way to go. Both will work, as JMC said, but the interface tends to be more advantageous in the long run, in my experience.
However, both could seem pretty daunting if you haven't worked with them, yet. Interfaces in particular, can be a bit intimidating for a person just starting out in them. They're very simple in practice, but the theory behind them tends to get a bit complex. Even the simplest descriptions for them tend to be kind of wordy. Fortunately, they really are simple beasts, so just fiddling around with them is fairly easy. In fact, if you are using a reasonably recent version of VS (I don't know when this feature was added, but certainly 2019, and probably earlier), then you will have the option to create an interface from any class you have already written. Forms are classes, so if you have a form, you can put the cursor on the class (Public Class YourClassNameHere), click on the screwdriver icon (or right click on the class name and select Quick Actions and Refactoring), and select Extract Interface. This will offer to create the interface in the same file or a different file. I prefer to use a different file, but you should do what you feel like, and the choice has no consequence.
Doing that will give you an interface, so you can see what one looks like. This will do a couple things, as it will give you the interface and will alter the class so that it implements the interface. When you see what changes it made, you can see how little there is to it, and you can change that readily enough.
Thx. Looks like a "rewrite" is my only choice".
If your example code is as simple as it gets, there's other options:Quote:
Originally Posted by Mugsy323
Code:If X = 1 Then
Form1.Label1.Text = X
ElseIf X = 100 Then
Form2.Label1.Text = X
End If
I created a forms app with three forms. Form2 and Form3 both have a label named 'Label1'.
Form1 code
Hope it helpsCode:Public Class Form1
Private Shared PRNG As New Random
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
Dim f As Windows.Forms.Form
If PRNG.Next(2) = 0 Then
f = New Form2
Else
f = New Form3
End If
Dim lblVal As String = ""
Dim lbl As Label = DirectCast(f.Controls("Label1"), Label)
lblVal = lbl.Text
f.Dispose()
Stop
End Sub
End Class
The problem is definitely far more complex, but thanks anyway. :)Quote:
Originally Posted by OptionBase1
This looks interesting. The "Windows.Forms.Form" might be the missing piece of the puzzle. I'll give it a try. Thx.Quote:
Originally Posted by dbasnett
I tried your example. It functions, but unfortunately can't be adapted to my situation (I'd need hundreds of references to every common object on each form.)
I've already started work on a single universal form and hiding unwanted/unneeded objects until needed. Time consuming, but will simplify things in the end.
Thx.
OK, I suspect you've got a major design flaw here ... what is it EXACTLY you're trying to do here? And I don't mean the technical or the how... but the WHAT. What is the functionality you're after here?Quote:
Originally Posted by Mugsy323
-tg
I wrote an app that I've been updating for years to manage Saved data for another app that is now in it's third generation.
So I have separate forms laying out the data that varies based on both on the version of the software they are managing and their screen resolution.
Newer versions of the commercial app that my software manages includes fields not found in earlier versions (and substantially more fields.)
The size, content & layout of each form is formatted for best appearance & ease of use for each generation of the app. But this means lots of redundant code (or unnecessarily complex code.) I was hoping to simplify things by referring to items common to all forms with a single line/block of code.