how to display Form2 by click button in Form1
-
Please explain more clearly what you are trying to do
Life goes very fast. Tomorrow, today is already yesterday.
i have 2 form. Form1 and Form2. i want to open Form2 by Clicking a Button in Form1. my code is follow. but my Form2 can appear alot as i click on Button. so i just to open Form2 only one even i click that Button many times . private void button1_Click(object sender, EventArgs e) { form f = new form2(); f.Show(); } :(
-
i have 2 form. Form1 and Form2. i want to open Form2 by Clicking a Button in Form1. my code is follow. but my Form2 can appear alot as i click on Button. so i just to open Form2 only one even i click that Button many times . private void button1_Click(object sender, EventArgs e) { form f = new form2(); f.Show(); } :(
I see, maybe something like this then...
Form2 form2;
private void button1_Click(object sender, EventArgs e)
{
if(form2 == null || form2.IsDisposed)
form2 = new Form2();
form2.Show();
}Life goes very fast. Tomorrow, today is already yesterday.
modified on Wednesday, June 17, 2009 12:00 PM
-
I see, maybe something like this then...
Form2 form2;
private void button1_Click(object sender, EventArgs e)
{
if(form2 == null || form2.IsDisposed)
form2 = new Form2();
form2.Show();
}Life goes very fast. Tomorrow, today is already yesterday.
modified on Wednesday, June 17, 2009 12:00 PM
musefan wrote:
if(form2.IsDisposed || form2 == null)
I would prefer
if(form2 == null || form2.IsDisposed ):)Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
-
musefan wrote:
if(form2.IsDisposed || form2 == null)
I would prefer
if(form2 == null || form2.IsDisposed ):)Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
-
I see, maybe something like this then...
Form2 form2;
private void button1_Click(object sender, EventArgs e)
{
if(form2 == null || form2.IsDisposed)
form2 = new Form2();
form2.Show();
}Life goes very fast. Tomorrow, today is already yesterday.
modified on Wednesday, June 17, 2009 12:00 PM
-
why it high like on line if(form2 == null || form2.IsDisposed) and message that "Use of unassigned local variable form2" . what wrong with this ?
-
musefan wrote:
if(form2.IsDisposed || form2 == null)
I would prefer
if(form2 == null || form2.IsDisposed ):)Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
-
set the initial value of form2 to null to avoid this compiler error.
Form2 form2 = null;
Life goes very fast. Tomorrow, today is already yesterday.
-
Close()[^] will basically just hide the form and the form can still be accessed along with its properties and functions etc. Dispose()[^] will effectively destroy the form and will not allow access to any of its properties or functions See the documentation links provided for a more detailed explanation
Life goes very fast. Tomorrow, today is already yesterday.
-
I don't, I never did those reverse compares, not in all my years programming in C and other languages that might benefit from it. It looks ugly, and it is unnecessary for Form variables: strongly typed languages with a boolean type don't need this at all, except maybe when the variable is of that boolean type. But even in C, where bools are just ints, I've always chosen not to do so. :)
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
-
Close()[^] will basically just hide the form and the form can still be accessed along with its properties and functions etc. Dispose()[^] will effectively destroy the form and will not allow access to any of its properties or functions See the documentation links provided for a more detailed explanation
Life goes very fast. Tomorrow, today is already yesterday.
i some code as bellow. it is mothed is called when click on MenuItem.problem is when i click item and command = "LOGOFF", it work correctly, but why i click a MenuItem and its command = "EXIT" , the visual studio doesn't stop debuging even my form was disappear?:confused: void MenuItemCommand(ExtenderMenu btn ) { switch (btn.Command ) { case "LOGOFF": Form2 f = null; if ( f == null || f.IsDisposed) { f = new Form2(); f.Show(); } this.Hide(); break; case "EXIT": this.Dispose(); break; } }
-
i some code as bellow. it is mothed is called when click on MenuItem.problem is when i click item and command = "LOGOFF", it work correctly, but why i click a MenuItem and its command = "EXIT" , the visual studio doesn't stop debuging even my form was disappear?:confused: void MenuItemCommand(ExtenderMenu btn ) { switch (btn.Command ) { case "LOGOFF": Form2 f = null; if ( f == null || f.IsDisposed) { f = new Form2(); f.Show(); } this.Hide(); break; case "EXIT": this.Dispose(); break; } }
hmmm... so Form2 is a 'login' form and Form1 is what the user gets when logged in? Are you using any other forms? like a main form that is calling Form1 or Form2? A quick fix if you want to exit the application would be...
case "Exit":
Application.Exit();
break;//well you would not actually need thisLife goes very fast. Tomorrow, today is already yesterday.
-
hmmm... so Form2 is a 'login' form and Form1 is what the user gets when logged in? Are you using any other forms? like a main form that is calling Form1 or Form2? A quick fix if you want to exit the application would be...
case "Exit":
Application.Exit();
break;//well you would not actually need thisLife goes very fast. Tomorrow, today is already yesterday.
-
I don't, I never did those reverse compares, not in all my years programming in C and other languages that might benefit from it. It looks ugly, and it is unnecessary for Form variables: strongly typed languages with a boolean type don't need this at all, except maybe when the variable is of that boolean type. But even in C, where bools are just ints, I've always chosen not to do so. :)
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
Luc Pattyn wrote:
I never did those reverse compares, not in all my years programming in C and other languages that might benefit from it.
I suspect you never spent hours or days looking for bug that was caused by a typo dropping an '=' character that could have been avoided by a compiler error. As far as I'm concerned, it's a no-brainer to choose to take advantage of the compiler in every case you can.
-
yes Form2 is Login or Logoff form. and Form1 is main form, but Form1 not a type of mdiparent form. mmh do u have other way of this "Application.Exit()" ?
well let me give you a quick idea of how you might want to handle an application with a login ability. So assuming you only have two forms (Form1 for you application stuff, Form2 for you login) go to your Main function, which you will probably find is your Program Class... you should have a line of code like
Application.Run(new Form1());
which is always called on start-up. Basically you want to only use that line of code if the login is successful (as decided by your Form2) First add a class level public static bool to test for login page to be shown or not...
public static bool ShowLogin = true;
so have something like this in your Main class...
while(ShowLogin)
{
Form2 loginForm = new Form2();
if(loginForm.ShowDialog() == DialogResult.OK)//login has passed
Application.Run(new Form1());
else
ShowLogin = false;//or break; or return;
}Then, in Form2, if the user clicks login and it is succesful use the following code..
this.DialogResult = DialogResult.OK;
this.Close();else, if the user clicks cancel (which should quit the application) then use this code...
this.DialogResult = DialogResult.Cancel;
this.Close();now in your Form1 you have your case for 'logoff' or 'exit'. use this code...
case "LOGOFF":
this.Close();
break;
case "EXIT":
Program.ShowLogin = false;
this.Close();
break;That should now be all you need for a basic login facility for your application
Life goes very fast. Tomorrow, today is already yesterday.
-
Luc Pattyn wrote:
I never did those reverse compares, not in all my years programming in C and other languages that might benefit from it.
I suspect you never spent hours or days looking for bug that was caused by a typo dropping an '=' character that could have been avoided by a compiler error. As far as I'm concerned, it's a no-brainer to choose to take advantage of the compiler in every case you can.
Never has been a problem. We tend to use tools at their most critical setting; and most of the C compilers we used regularly accurately emitted warnings on anything that could be unintentional, such as missing equal signs and empty loop blocks. And as I said before, strongly typed languages (we used to use Java a lot) offer a pretty good defense. See the mandatory breaks in a switch for instance. :)
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
-
Never has been a problem. We tend to use tools at their most critical setting; and most of the C compilers we used regularly accurately emitted warnings on anything that could be unintentional, such as missing equal signs and empty loop blocks. And as I said before, strongly typed languages (we used to use Java a lot) offer a pretty good defense. See the mandatory breaks in a switch for instance. :)
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
Luc Pattyn wrote:
Never has been a problem. We tend to use tools at their most critical setting; and most of the C compilers we used regularly accurately emitted warnings on anything that could be unintentional, such as missing equal signs and empty loop blocks.
I'm not sure what you mean by "missing equal signs". In vs2008 with warnings and errors set to the strictest settings this compiles just fine:
int n = 1; if( n = 2) cout << "now it's two" << endl;As far as I can remember I have never used a compiler that produce a warning or error on that because in C/C++ it's perfectly valid to evaluate an assignment result as an expression to be non-zero. So if you typo n == 2 into n = 2 you get no warnings or errors but you don't get the intended behavior. However if you do: 2 == n and typo it to 2 = n you get a compiler error. It's your choice and since I don't have to maintain your code I don't really care what you choose.
-
Luc Pattyn wrote:
Never has been a problem. We tend to use tools at their most critical setting; and most of the C compilers we used regularly accurately emitted warnings on anything that could be unintentional, such as missing equal signs and empty loop blocks.
I'm not sure what you mean by "missing equal signs". In vs2008 with warnings and errors set to the strictest settings this compiles just fine:
int n = 1; if( n = 2) cout << "now it's two" << endl;As far as I can remember I have never used a compiler that produce a warning or error on that because in C/C++ it's perfectly valid to evaluate an assignment result as an expression to be non-zero. So if you typo n == 2 into n = 2 you get no warnings or errors but you don't get the intended behavior. However if you do: 2 == n and typo it to 2 = n you get a compiler error. It's your choice and since I don't have to maintain your code I don't really care what you choose.
Hi Mike, Most of my work is done outside the PC and Microsoft arena; I am not very familiar with Visual Studio C++ compilers, if they don't warn you on
if( n = 2)then that is too bad; a decent compiler knows such statement is valid, hence no error, but probably wrong, hence a warning, which can be disabled as all messages normally have a numeric code, or avoided by writing unambiguous code as inif((n = 2)!=0)...That is what warnings are all about: pointing your attention at things that might be intentional and correct, and maybe are not. BTW: most compilers also would warn you the condition is always true, making theif, and when present theelsepart, redundant. :)Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
-
Hi Mike, Most of my work is done outside the PC and Microsoft arena; I am not very familiar with Visual Studio C++ compilers, if they don't warn you on
if( n = 2)then that is too bad; a decent compiler knows such statement is valid, hence no error, but probably wrong, hence a warning, which can be disabled as all messages normally have a numeric code, or avoided by writing unambiguous code as inif((n = 2)!=0)...That is what warnings are all about: pointing your attention at things that might be intentional and correct, and maybe are not. BTW: most compilers also would warn you the condition is always true, making theif, and when present theelsepart, redundant. :)Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.