How to set text of textbox with value user entered in another form at form close
-
i have two forms form1 contain textbox1 and buttonsearch //click form2 is opend form2 contains textbox2 i want when user close form2 the value of textbox1 equals value of textbox2 in form2
So what is the problem you are facing.Can have some property in form1 which set the value in textbox1 and set this property from form2. Are you asking somthing else?
Cheers!! Brij Check my latest Article :Exploring ASP.NET Validators
-
i have two forms form1 contain textbox1 and buttonsearch //click form2 is opend form2 contains textbox2 i want when user close form2 the value of textbox1 equals value of textbox2 in form2
If you specifically want an operation to happen when a form closes, then add an event handler to the close event of that form. Form1 - assuming form 1 creates form2 and displayed it with form2.Show():
form2.Closed += new EventHandler(form2_Closed);
...
void form2.Closed(object sender, EventArgs e)
{
textbox1.Text = form2.MyTextProperty;
}Declare
public string MyTextProperty
{
get { return textboxInForm2.Text; }
set { textboxInForm2.Text = value; }
}In form2. If you show form2 via ShowDialog(), then just access the property - you don't need the event.
You should never use standby on an elephant. It always crashes when you lift the ears. - Mark Wallace C/C++ (I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste) - fat_boy
-
So what is the problem you are facing.Can have some property in form1 which set the value in textbox1 and set this property from form2. Are you asking somthing else?
Cheers!! Brij Check my latest Article :Exploring ASP.NET Validators
Not really good practice - it means form2 has to know about form1 and cannot be used without it. Better to use an event handler in form1 and a property in form2, as many forms can then use form2. Better still is to use a custom event in form2 which returns the value via a customized EventArgs.
You should never use standby on an elephant. It always crashes when you lift the ears. - Mark Wallace C/C++ (I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste) - fat_boy
-
So what is the problem you are facing.Can have some property in form1 which set the value in textbox1 and set this property from form2. Are you asking somthing else?
Cheers!! Brij Check my latest Article :Exploring ASP.NET Validators
-
If you specifically want an operation to happen when a form closes, then add an event handler to the close event of that form. Form1 - assuming form 1 creates form2 and displayed it with form2.Show():
form2.Closed += new EventHandler(form2_Closed);
...
void form2.Closed(object sender, EventArgs e)
{
textbox1.Text = form2.MyTextProperty;
}Declare
public string MyTextProperty
{
get { return textboxInForm2.Text; }
set { textboxInForm2.Text = value; }
}In form2. If you show form2 via ShowDialog(), then just access the property - you don't need the event.
You should never use standby on an elephant. It always crashes when you lift the ears. - Mark Wallace C/C++ (I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste) - fat_boy
-
i solved it by another way form1 form2 f2 = new form2(); f2.showdialog(); f2.dispose(); if(f2.IsDispose) { textbox1.text = valuetext; } // value text is static variable in form2 thank u for ur replay
:omg: DO NOT DO THAT! See here[^] When you dispose a control, you have no control over when it's memory is available - the garbage collector is a liberty to remove it at any time. The code may work now, in testing, and then fail intermittently for no apparent reason later. To add to that: What do you think static variables are? Again, this will cause you problems. Read up on the difference between a STATIC and a PUBLIC variable. Also, it is considered bad practice to expose fields directly, and it makes it difficult to implement changes later. Use a property instead. To add to the list: Don't use f2.ShowDialog() alone - always surround it with an "if" as in:
if (f2.ShowDialog() == DialogResult.OK)
{
...
}Otherwise, what happens if the user decides he doesn't want to enter a value?
You should never use standby on an elephant. It always crashes when you lift the ears. - Mark Wallace C/C++ (I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste) - fat_boy
-
:omg: DO NOT DO THAT! See here[^] When you dispose a control, you have no control over when it's memory is available - the garbage collector is a liberty to remove it at any time. The code may work now, in testing, and then fail intermittently for no apparent reason later. To add to that: What do you think static variables are? Again, this will cause you problems. Read up on the difference between a STATIC and a PUBLIC variable. Also, it is considered bad practice to expose fields directly, and it makes it difficult to implement changes later. Use a property instead. To add to the list: Don't use f2.ShowDialog() alone - always surround it with an "if" as in:
if (f2.ShowDialog() == DialogResult.OK)
{
...
}Otherwise, what happens if the user decides he doesn't want to enter a value?
You should never use standby on an elephant. It always crashes when you lift the ears. - Mark Wallace C/C++ (I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste) - fat_boy
-
Not really good practice - it means form2 has to know about form1 and cannot be used without it. Better to use an event handler in form1 and a property in form2, as many forms can then use form2. Better still is to use a custom event in form2 which returns the value via a customized EventArgs.
You should never use standby on an elephant. It always crashes when you lift the ears. - Mark Wallace C/C++ (I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste) - fat_boy
Obiuosly this is thebetter way and having least coupling.
Cheers!! Brij Check my latest Article :Exploring ASP.NET Validators
-
:omg: DO NOT DO THAT! See here[^] When you dispose a control, you have no control over when it's memory is available - the garbage collector is a liberty to remove it at any time. The code may work now, in testing, and then fail intermittently for no apparent reason later. To add to that: What do you think static variables are? Again, this will cause you problems. Read up on the difference between a STATIC and a PUBLIC variable. Also, it is considered bad practice to expose fields directly, and it makes it difficult to implement changes later. Use a property instead. To add to the list: Don't use f2.ShowDialog() alone - always surround it with an "if" as in:
if (f2.ShowDialog() == DialogResult.OK)
{
...
}Otherwise, what happens if the user decides he doesn't want to enter a value?
You should never use standby on an elephant. It always crashes when you lift the ears. - Mark Wallace C/C++ (I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste) - fat_boy
OriginalGriff wrote:
When you dispose a control, you have no control over when it's memory is available - the garbage collector is a liberty to remove it at any time. The code may work now, in testing, and then fail intermittently for no apparent reason later.
The garbage collector cannot remove a disposed control if any references to it exist. If there are any user fields or properties, within a control, those fields will continue to be valid, even after the control is disposed, with the exception of properties that explicitly check for isDisposed and will throw exception exception if it is set. As for the best way to return the content of a form that is invoked modally, I would suggest that rather than using events, one (1) define a class which contains the form's contents and an enumerated type listing methods of exit; (2) define a method in the form which will ShowDialog itself and then return an object of the class in '1' filled with the values from the form; (3) define a static method in the form which will create a new instance, call the method in '2', and dispose of the instance. That would avoid any excess dependencies between the child form and the main form, and avoid having to add any extra code into the calling form.
