I asked a question a couple of days ago about populating a listbox on a form from a class. It works and was great! However I now want to do the same with a textbox or a label. The answer from that question is below:
What you are doing is creating a new instance of the form - I presume you are trying to add items in a listbox on an existing form?
If so do this.
Create a function on the form with the listbox like:
public void addItemToListBox(string item) { listBox1.Items.Add(item); }
Then, in the class (remember to add the using System.Windows.Forms reference)
public void doStuff() { //Change Form1 to whatever your form is called foreach (Form frm in Application.OpenForms) { if (frm.GetType() == typeof(Form1)) { Form1 frmTemp = (Form1)frm; frmTemp.addItemToListBox("blah"); } } }
This works well. Now I want to do the same with a textbox. I was wondering if someone could explain or if someone has a link on this?
I have a form and a class. The form makes a new instance of the class and initiates a method in the class, say a maths equation 4+4; I want the answer, "8" to then be shown in a textbox or label on form1, from the method in the class.
Put this in Form1.cs:
And in the class file:
What you are describing, with your edit, is a model in which your
Form
uses another class. The class that is being used should have no knowledge of theForm
, it's controls, or how the result of its calculation could possibly be used.Your other class shouldn't find the form, it shouldn't call any methods or fields of the form, or anything. What it should do is just return a value:
Then the form can do something like this:
The other class should be responsible for doing the calculations, creating a result, but not updating the user interface based on those results. All of the user interface logic should be contained in the
Form
class.Looping through all open forms seems like a ... novel ... way to get the form in question.
Instead, you should keep a reference to the form until you finally close it, and access variables on the form (like list boxes and text boxes) directly through that.
So, where you create the form, do something like
// Open the dialog or whatever you are going to do with form1
// When you need to access a text control:
If doStuff is happening from a model (a class that models some aspect of real-world behavior), you are following a poor design pattern.
Models should have no idea of how they are presented. Instead, in a typical WinForms application, a parent form would likely hold the variable form1. In newer types of UI projects, you would see a MVC or MVVM pattern to separate the Model, the View (presentation/forms) and Controller (flow control). One can also follow an MVC pattern with WinForms, though many/most WinForms applications I have seen don't do that.
If you are using Visual Studio, you can specify the visiblity of each member, e.g.private
orpublic
.private
is the default (if i remember correctly).If you change this to
public
, then you could do the following:Edit 1
A better approach, would be to tell Form1 that it needs to update something, how it presents the data is of no concern to the class which is invoking the method.
Form1 is now responsible for changing the controls it holds, rather than other - possibly - unrelated class manipulating them. This keeps all of the UI logic
encapsulated
into Form1, and all the business logic can be held elsewhere.