how to display Form2 by click button in Form1
-
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.
-
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()" ?
You're getting a lot of help here, which is great. But, what you should learn from this is that you need to do some basic study, to understand these VERY basic things. I sure hope no-one is actually going to use this code, the only place you should be in, is a class. And, you should talk to your teacher first, as he can help you better if he knows how stuck you are, and doesn't read other people's code and assume you wrote it.
Christian Graus Driven to the arms of OSX by Vista. "! i don't exactly like or do programming and it only gives me a headache." - spotted in VB forums. I can do things with my brain that I can't even google. I can flex the front part of my brain instantly anytime I want. It can be exhausting and it even causes me vision problems for some reason. - CaptainSeeSharp