I've a problem with my C# Code. At the moment I try to program a Windows Forms Application with more than one Window.
Now my problem:
At the first window I've a combobox with some values. When I click on a button, the second window opens and there it should be possible to add a value to this combobox on the first form.
The problem is that in the first window I´ve a LinkedList where my values are in.
Like this:
public LinkedList<String> sample = new LinkedList<String>();
hase.AddFirst("test");
combobox.Items.AddRange(sample.ToArray());
Now, in the second window the LinkedList isn't available, even if I make it public.
What is the best way to solve this problem?
Hope you understand my problem...
Harald
Without knowing exactly how to are trying to access the LinkedList, it's hard to say why it isn't working for you.
Let's go over what you have. You have a LinkedList, which is an instance variable on a form. Since this LinkedList is an instance variable, it is associated with the instance of the form.
This example below, will not work because it tries to access it statically:
public class MyForm : Form
{
public LinkedList<string> _list = new LinkedList<string>();
}
public class MySecondForm : Form
{
public void Window_Loaded(object sender, EventArgs e)
{
MyForm._list.AddFirst("This doesn't work");
//WRONG! list is an instance variable we are trying to access statically.
}
}
So, we can see this does not work. We have a few options to get this working. First off, one very bad solution would be to actually make list static. Don't use this option. It's opens the door for concurrency problems, possibly leaking strong references, etc. Generally, using statics (like a singleton) I would discourage for passing data around for these reasons. The Singleton Pattern has a time and a place, but I don't think this is it since it can so easily be avoided.
OK, since we got the bad solution out of the way, let's look at a few possible good ones.
Set the list on MySecondForm. You have a few options for this. The constructor, a property, or a method. For example:
public class MyForm : Form
{
private LinkedList<string> _list = new LinkedList<string>();
public void Button1_Click(object sender, EventArgs e)
{
var secondForm = new MySecondForm();
secondForm.SetList(_list);
secondForm.ShowDialog();
MessageBox.Show(_list.First.Value);
}
}
public class MySecondForm : Form
{
private LinkedList<string> _list;
public void Window_Loaded(object sender, EventArgs e)
{
this._list.AddFirst("This will work");
}
public void SetList(LinkedList<string> list)
{
_list = list;
}
}
This is one possible solution. The constructor is another possible solution as Billy suggested.
Because LinkedList is a reference type, any changes you make to it on the instance of MySecondForm will be reflected on the linked list of MyForm.
You can always pass it to the second window. As vcsjones points out below, you should only need to add the ref keyword if you are re-assigning the list. You will need a constructor that takes a linked list as a variable.
SecondWindow secondWindow = new SecondWindow(sample);
Another way would be create a class using the singleton pattern and you can place the linked list in there. You would then have access to it from both windows if it was in a common location.
Related
New C# and Entity Framework user. I want to put the results of a table into a C# list. I want to reference this list in multiple form events. I will cycle through the list from beginning to end throughout the life of the form.
Currently, I have this code (snippet):
public partial class FrmMain : Form
{
private readonly admEntities _admEntities = new admEntities();
public FrmMain()
{
InitializeComponent();
}
private void frmMain_Load(object sender, EventArgs e)
{
var exhibitor = _admEntities.Exhibitors.ToList();
// Put the first value in a text box - this works
txtCurrentSaleOrder.Text = exhibitor.First().SaleOrder.ToString();
}
}
I was hoping to use the exhibitor variable elsewhere on other events. However, I am unable to reference it.
I have not been successful in my searching and coding attempts to resolve this problem so far. Any pointer in the right direction would be appreciated.
One thing I tried was to put this code in a class above FrmMain(). That also failed. Probably due to not fully understanding classes yet.
You should make exhibitor a field, which is a fancy way of saying declare it outside of a method, inside of your class. Here is an example where exhibitor can be accessed from anywhere else in the class.
public partial class FrmMain : Form
{
private readonly admEntities _admEntities = new admEntities();
//It's unclear what exhibitor is in your question, so I'm using generic code that will allow it to work regardless.
private Type exhibitorType = typeof(admEntities.Exhibitors);
private List<exhibitorType> exhibitor = new List<exhibitorType>();
public FrmMain()
{
InitializeComponent();
}
private void frmMain_Load(object sender, EventArgs e)
{
//Can reference here
exhibitor = _admEntities.Exhibitors.ToList();
txtCurrentSaleOrder.Text = exhibitor.First().SaleOrder.ToString();
}
private void AnotherMethod()
{
//Can reference exhibitor here too.
}
}
I have a windows form app with 2 forms, and I need to press a button in form one to go to form 2(this is done already) then form 2 will be able to create an object using the add customer method to add to the system. My question is:
1)if I create an Object in Form 2, how could other forms(form3,form4 etc.) have access to this object? As far as I have learned, I can only call the method through an object.
2)if I created an object in Form1, and other forms inherited from form 1, will this object still work in other forms?
3)Objects can be inhereited or not? is this a good practice in real world?
4) How to allow different forms using one object different method?
A static field or property as suggested in zdimension's answer is possible, of course, but it shouldn't be your first option. There are lots of ways to pass data between forms, and it depends on your application which one is best. For example, one way of doing it is:
class Form2 : Form
{
public Form2()
{
InitializeComponent();
}
public AirlineCoordinator Coordinator {get; set;}
...
}
class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
public AirlineCoordinator Coordinator {get; set;}
private void Form1_Load(object sender, EventArgs e)
{
this.Coordinator = new AirlineCoordinator(...);
...
}
...
private void ShowForm2Button_Click(object sender, EventArgs e)
{
using(var form2 = new Form2())
{
form2.Coordinator = this.Coordinator;
form2.ShowDialog(this);
}
}
}
In this hypothetical example, Form1 has a button ShowForm2Button; clicking on this button shows Form2 using the same AirlineCoordinator as is used by Form1.
The usual way to make something available to "everyone" is to use a static field, like this:
public class GlobalStuff
{
public static MyType SomeVariable;
}
Here, the GlobalStuff obviously only ever contains global things, so you could consider making it static too to indicate it will never be instanciated.
Here's what MSDN say about it:
Use a static class as a unit of organization for methods not associated with particular objects. Also, a static class can make your implementation simpler and faster because you do not have to create an object in order to call its methods. It is useful to organize the methods inside the class in a meaningful way, such as the methods of the Math class in the System namespace.
I'm trying to call a function in a main form from another form... Already got to call a simple function, by declaring it public static in main form, yet I can't call the needed one.
The function to call:
public static void spotcall()
{
string dial = Registry.CurrentUser.OpenSubKey("SOFTWARE").OpenSubKey("INTERCOMCS").GetValue("DIAL").ToString();
MainForm.txtSendKeys.Text = dial;// Here it asks me for a reference to an object.
foreach (char c in txtSendKeys.Text)
{
sideapp.Keyboard.SendKey(c.ToString(), checkBoxPrivate.Checked);
}
txtSendKeys.Clear();
}
The procedure I use to call it from a child form:
private void button1_Click(object sender, EventArgs e)
{
button1.Text = "Hoho";
MainForm.spotcall();
}
I completely admit that I lack some theory about C#, but as it often happens, I just have to do it for my work, so I expect to get help if by chance I don't get to the solution by myself. Thank you :)
You cannot reference instances of controls on your MainForm in a static method. Like the compiler is telling you, you need an instance of the form in order to update things like TextBoxes. Without an instance, where would the values you are trying to update go?
I'm not sure exactly how the child form is being created, but one way you could call methods on your MainForm would be to provide a reference to your MainForm instance directly to the child form. This could be through the constructor or some public property.
For example
public class ChildForm : Form {
public MainForm MyParent { get; set; }
private void button1_Click(object sender, EventArgs e)
{
button1.Text = "Hoho";
// Now your child can access the instance of MainForm directly
this.MyParent.spotcall();
}
}
Assuming you are creating ChildForm inside of MainForm the code to give the child a reference is pretty simple:
var childForm = new ChildForm();
childForm.MyParent = this; // this is a `MainForm` in this case
childForm.Show();
You would also need to make spotcall an instance method and not a static method, and remove the static reference to MainForm in your code:
public void spotcall()
{
string dial = Registry.CurrentUser.OpenSubKey("SOFTWARE").OpenSubKey("INTERCOMCS").GetValue("DIAL").ToString();
// Now it no longer asks you for a reference, you have one!
txtSendKeys.Text = dial;
foreach (char c in txtSendKeys.Text)
{
sideapp.Keyboard.SendKey(c.ToString(), checkBoxPrivate.Checked);
}
txtSendKeys.Clear();
}
I think the correct way to do this is to use delegates. This way your form (window) does not have to know anything about the parent form (the form can be opened from different parent forms).
Let's say we want to call a function in the parent form when the child form is closed (not showing the form as modal).
At the top of your child form create a delegate:
public delegate void CloseEvent();
public CloseEvent WindowClosed;
Create the form closing event and have it call your delegate:
private void child_FormClosing(object sender, FormClosingEventArgs e)
{
WindowClosed();
}
A button in the parent form can show the child form and set the callback:
private ChildForm childform = null;
private void buttonShowChildForm_Click(object sender, EventArgs e)
{
if (childform == null)
{
childform = new ChildForm();
childform.WindowClosed += childClosed;
childform.Show();
} else
{
childform.BringToFront();
}
}
private void childClosed()
{
childform = null;
}
In this example we use a button to open a new form that does not block the parent form. If the user tries to open the form a second time, we just bring the existing form to the front to show it to the user. When the form is closed we set the object to null so that next time we click the button a new form is opened because the old was disposed when closed.
Best regards
Hans Milling...
You can not access non-static members in static context, which means you have to made txtSendKeys static, or make your function non-static.
If you create a static function, you may not reference global variables inside the function that aren't static as well.
So in order for spotcall to be static, you have to remove the reference to the txtSendKeys (I'm assuming this is a text box that you have created elsewhere in the form) or txtSendKeys must be declared within the static function.
Additional:
You obtained the value for txtSendKeys.Text in the previous line, via variable dial. Instead of referencing txtSendKeys.Text at all, I imagine you could simply use the variable dial to complete the function and leave the function static (you clear it at the end anyway).
public static void spotcall()
{
string dial = Registry.CurrentUser.OpenSubKey("SOFTWARE").OpenSubKey("INTERCOMCS").GetValue("DIAL").ToString();
foreach (char c in dial)
{
sideapp.Keyboard.SendKey(c.ToString(), checkBoxPrivate.Checked);
}
}
Although, that wouldn't overcome the same issue you would likely run into with checkBoxPrivate.Checked.
You could change it to take a boolean argument.
public static void spotcall(Boolean PrivateChecked)
{
string dial = Registry.CurrentUser.OpenSubKey("SOFTWARE").OpenSubKey("INTERCOMCS").GetValue("DIAL").ToString();
foreach (char c in dial)
{
sideapp.Keyboard.SendKey(c.ToString(), PrivateChecked);
}
}
You can put the shared code in a third class that's visible to both forms. So, for example:
public class static HelperFunctions
{
public static void spotcall()
{
. . .
}
}
Then replace
MainForm.spotcall()
with
HelperFunctions.spotcall()
The MainForm is just a class. It has the structure of the class. But the only data you can get from it is static data.
But an instance of that class appears when you do: MainForm MyFormInstance = new MainForm();
The MainForm can be used only to access static members (methods, properties...).
When you want to get the txtSendKeys, you must get it from an instance (object reference). That's because the textbox is not static, so it only exists in instances of the form.
So, you should do the following:
Make spotcall NOT static.
Put in child form a variable MainForm MyParentMainForm;
When you call the child, set that MyParentMainForm with the instance of the mainform. If it's being called from the main form, you can get the instance with the this keyword.
Inside child form, call MyParentMainForm.spotcall
PS: I'm not sure if there's something like a real child form or if you just call new forms from another. If there's really a child form, you can get the Parent property to access the instance of the main form.
This is sort of a "design pattern" issue, which I'll elaborate on, but I can try to explain the most direct way to solve this if you don't expect this program to change very much. "Static" things only exist once - once in the entire application. When a variable or function is static, it's much easier to access from anywhere in the program; but you can't access an object's associated data, because you're not pointing to a particular instance of that object (ie, you have seven MainForms. Which one are you calling this function on?) Since standard WinForm design expects you could have seven copies of MainForm displaying, all variables associated are going to be instance variables, or non-static. However, if you expect never to have a second MainForm, then you can take the "singleton" approach, and have an easy way of accessing your one instance.
partial class MainForm {
// only including the code that I'm adding; I'm sure there's a lot of stuff in your form.
public static MainForm Instance { public get; private set; }
protected void onInitialize() { // You need to hook this part up yourself.
Instance = this;
}
}
partial class SubForm {
protected void onImportantButton() {
MainForm.Instance.doImportantThing()
}
}
Putting too much active data-changing logic in form classes is a pretty common issue with many beginners' code. That's not a horrible thing - you wouldn't want to be making 5 controlling classes just for a simple thing you're trying. As code gets more complex, you start to find some things would make more sense to move to a "sublevel" of classes that don't interact with the user (so, some day, if this is being re-coded as a server program, you could throw away the form classes, and just use the logic classes - theoretically speaking). It also takes some time for many programmers to understand the whole concept of object "instances", and the "context" that a function is called in.
I am wondering which is a better way to store information? A central static class or in a parent class?
The code for the way I am storing it now. I instanciate a new class everytime.
Parent Class:
public partial class frmEmployeeManager: Form
{
List<Employee> lstEmployees = List<Employee>();
public frmEmployeeManager()
{
InitializeComponent();
}
public void updatePay(float Pay, int ID)
{
//Where ID = ID change the Pay
//(Omitted the foreach loop here for brevity)
}
private void btnDisplayData_Click(object sender, EventArgs e)
{
frmUpdatePay dlgUpdatePay = new frmUpdatePay(this);
dlgUpdatePay.ShowDialog();
}
}
Child Class:
public partial class frmUpdatePay : Form
{
private frmEmployeeManager ParentEmployeeManager;
public frmUpdatePay(frmEmployeeManager EmployeeManager)
{
InitializeComponent();
ParentEmployeeManager = EmployeeManager;
}
AddPersonParent.updatePay(fltPayInput, intID);
}
Taking a stab in the dark (since I don't know exactly what you are trying to accomplish), I would make an instantiated class and use a singleton pattern.
Personally I would (and do) use a central static class. Both choices break the OO principles, but at least the central static class approach doens't expose the inner workings of my forms to the outside.
I have gotten myself into trouble before when I used a static list that held the "state" of thing, and I found myself adding static functions to "clear" or "update" the list, etc. So I learned to only use static classes or lists or variables for things that are, well, static-- non-changing.
If you are keeping objects in the list that can change, I would go the instantiated route.
Updated
Now that I see your list is an employee list, converting it to a static basically makes it's a global variable. Global variables are not good. I found this answer which summarizes it pretty well.
I almost never used (advanced, or at all) graphical interfaces, or one simple form with simple controls... but this time I've got something a little more complex, and I don't have much experience with GUI.
I have one main form (and possibly more in the future) from which other sub-forms open (and they might have sub-forms of themselves) and I wonder what is, in your opinion, the best way to communicate between them?
I thought of passing the main form as a parameter to the constructors of the sub-forms, but it doesn't seem like a good way, especially if I'm going to need to communicate between other, distinct, sub-forms, not to mention I have to double check the input, or make a few methods, but it seems more like functional programming than object oriented programming...
Perhaps I can:
Create a static class (or Properties.Settings) for global settings. Cons: every change of data is needed to be copied to the class, I'm looking for something a bit more comfortable and elegant.
Use the ugly way of accessing the controls from Application.OpenForms - fixes the problem of passing the main form as parameter. Cons: not very stable.
Do something else I haven't thought of. Suggestions? Cons: don't know what it is yet.
Your constructor idea is probably the most sound method of communication back to the main form. Your sub form would do something like the following:
public class SubForm : Form
{
public SubForm(MainForm parentForm)
{
_parentForm = parentForm;
}
private MainForm _parentForm;
private void btn_UpdateClientName_Click(object sender, EventArgs e)
{
_parentForm.UpdateClientName(txt_ClientName.Text);
}
}
And then you expose public methods on your MainForm:
public class MainForm : Form
{
public void UpdateClientName(string clientName)
{
txt_MainClientName.Text = clientName;
}
}
Alternatively, you can go the other way around and subscribe to events from your SubForms:
public class MainForm : Form
{
private SubForm1 _subForm1;
private SubForm2 _subForm2;
public MainForm()
{
_subForm1 = new SubForm1();
_subForm2 = new SubForm2();
_subForm1.ClientUpdated += new EventHandler(_subForm1_ClientUpdated);
_subForm2.ClientUpdated += new EventHandler(_subForm2_ProductUpdated);
}
private void _subForm1_ClientUpdated(object sender, EventArgs e)
{
txt_ClientName.Text = _subForm1.ClientName; // Expose a public property
}
private void _subForm2_ProductUpdated(object sender, EventArgs e)
{
txt_ProductName.Text = _subForm2.ProductName; // Expose a public property
}
}
A good way is to declare delegates in the form that want to start the communication. You need a delegate and a callback function:
public delegate void SetValueDelegate(string value);
public SetValueDelegate SetValueCallback;
Another form can then attach to this delegate. At that moment both forms have to know each other, but not after that moment:
firstForm.SetValueCallback += new SetValueDelegate(secondForm.SetValueFunction);
The second form has to declare a function that matches the delegate definition:
public void SetValueFunction(string value)
{
// do something
}
Now the first form can use the delegate to use the function of the second form (and all other forms or classes that were attached to the delegate:
SetValueCallback(txtParam.Text);
Edit: made an complete example
using System;
namespace DelegateTest
{
public delegate void SetValueDelegate(string value);
public class Class1
{
public SetValueDelegate SetValueCallBack;
public void Test()
{
if(SetValueCallBack != null)
{
SetValueCallBack("Hello World!");
}
}
}
public class Class2
{
public void SetValueFunction(string value)
{
Console.WriteLine(value);
}
}
public class Launcher
{
public static void Main(string[] args)
{
Class1 c1 = new Class1();
Class2 c2 = new Class2();
c1.SetValueCallBack += new SetValueDelegate(c2.SetValueFunction);
c1.Test();
}
}
}
The most flexible, scalable (and IMHO the most professional) way to do it is to use CAB (Composite Application Block). In simple terms CAB is a set of 2-3 assemblies that implement a lot of plumbing required to make complex UI applications the right way and it exposes this plumbing to the user of the library in a nice way. Among others it has a very nice event and command (as in command pattern) system.
The downside: requires some time to learn and not very trivial to grasp.
Here is a comprehensive (but easy to understand) tutorial that will help you make the learning easier.
You can use the built in Tag property of the form which is an "object" class.
public Form1()
{
(ComplicatedDataStructure)Tag = new ComplicatedDataStracture();
}
.
.
form1 = new Form1();
.
.
form2 = new Form2();
.
.
form2.Tag = form1.Tag;
so form2.Tag is equals to "ComplicatedDataStracture" object;