| Groups | Blog | Home |
dotnet windows forms : Close a form from it's constructor ?
its caller) from it's constructor ? I've tried both the following but they just seem to carry on and open the form. Application.Exit(); this.Close();
[quoted text, click to view]
> Executing a form's constructor doesn't necessarily show the form. You or else you could call this.Close() in the form_load event. > could throw an exception to indicate that constructing the instance didn't > successfully complete. >
"JezB" <jezbroadsword@blueyonder.co.uk> schrieb:
[quoted text, click to view] > How can I close a form (or stop it from opening, thus returning control to > its caller) from it's constructor ? > > I've tried both the following but they just seem to carry on and open the > form. Executing a form's constructor doesn't necessarily show the form. You could throw an exception to indicate that constructing the instance didn't successfully complete. -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/>
Throwing exception form the form constructor will prevent the from from
showing. Hoewever I personally believe that throwing exceptions from constructors is a bad idea. Further more exceptions should be used for exceptional situations - something that is not expected. If you check a condition and this is a part of the normal process flow I wouldn't call this an exceptional situation, so I give my vote to using the Load event and closing the form from there. -- HTH Stoitcho Goutsev (100) [quoted text, click to view] "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message news:%23dyw%23TBTGHA.3976@TK2MSFTNGP10.phx.gbl... > "FUnky" <viveks@nagarro.com> schrieb: >>> Executing a form's constructor doesn't necessarily show the form. You >>> could throw an exception to indicate that constructing the instance >>> didn't successfully complete. >>> >> or else you could call this.Close() in the form_load event. > > Yep, but why show the form at all if you do not want it to be shown? I > believe that the constructor is a more suitable place for performing these > checks. > > -- > M S Herfried K. Wagner > M V P <URL:http://dotnet.mvps.org/> > V B <URL:http://classicvb.org/petition/>
"FUnky" <viveks@nagarro.com> schrieb:
[quoted text, click to view] >> Executing a form's constructor doesn't necessarily show the form. You >> could throw an exception to indicate that constructing the instance >> didn't successfully complete. >> > or else you could call this.Close() in the form_load event. Yep, but why show the form at all if you do not want it to be shown? I believe that the constructor is a more suitable place for performing these checks. -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/>
[quoted text, click to view] "Stoitcho Goutsev (100)" <100@100.com> wrote in message news:OX5AUkCTGHA.1576@tk2msftngp13.phx.gbl... > Throwing exception form the form constructor will prevent the from from > showing. Hoewever I personally believe that throwing exceptions from > constructors is a bad idea. Why? [quoted text, click to view] > Further more exceptions should be used for exceptional situations - > something that is not expected. So you think that it is normal to create an object and then decide that you didn't want it after all and throw it away without using it? Doesn't strike me as a good way to program! [quoted text, click to view] > If you check a condition and this is a part of the normal process flow I > wouldn't call this an exceptional situation> , so I give my vote to using > the Load event and closing the form from there. I couldn't disagree more strongly.
Nick,
You have right to disagree. That's why I said that this is my personal opinion. I'd say it is not common for code to catch *new* statement in a try/catch and that almost no one check the docs if the constructor throws an exception. -- Stoitcho Goutsev (100) [quoted text, click to view] "Nick Hounsome" <nh002@nickhounsome.me.uk> wrote in message news:pazTf.198527$Q22.19023@fe1.news.blueyonder.co.uk... > > "Stoitcho Goutsev (100)" <100@100.com> wrote in message > news:OX5AUkCTGHA.1576@tk2msftngp13.phx.gbl... >> Throwing exception form the form constructor will prevent the from from >> showing. Hoewever I personally believe that throwing exceptions from >> constructors is a bad idea. > > Why? > >> Further more exceptions should be used for exceptional situations - >> something that is not expected. > > So you think that it is normal to create an object and then decide that > you didn't want it after all and throw it away without using it? Doesn't > strike me as a good way to program! > >> If you check a condition and this is a part of the normal process flow I >> wouldn't call this an exceptional situation> , so I give my vote to using >> the Load event and closing the form from there. > > I couldn't disagree more strongly. >
As you can see from the controversial answers you raised, you may want to
explain what you are trying to do exactly. My first move would to avoid opening the form at all, rather than to open the form just so that it can then see there is no need to open... -- Patrice "JezB" <jezbroadsword@blueyonder.co.uk> a écrit dans le message de news: eCZdtx6SGHA.5104@TK2MSFTNGP10.phx.gbl... [quoted text, click to view] > How can I close a form (or stop it from opening, thus returning control to > its caller) from it's constructor ? > > I've tried both the following but they just seem to carry on and open the > form. > > Application.Exit(); > this.Close(); >
[quoted text, click to view]
"Stoitcho Goutsev (100)" <100@100.com> wrote in message news:OFzf2xFTGHA.5168@TK2MSFTNGP10.phx.gbl... > Nick, > > You have right to disagree. That's why I said that this is my personal > opinion. Very reasonable of you. I'm not that reasonable - I think that I'm right and you're wrong :-) [quoted text, click to view] > I'd say it is not common for code to catch *new* statement in a try/catch > and that almost no one check the docs if the constructor throws an > exception. It is not common because most ctors don't normally throw but the it is not common to call most methods in a try/catch block either for the same reason so what's your point? People will check the throw spec of any method or constructor that they think will perform checks that might fail or that allocates resources. One thing that nobody EVER checks is whether or not the form that they just told to show itself actualy did so. One of the reasons that exceptions are the foundation of error reporting in modern langauges rather than return codes or statuses is that experience has shown that nobody ever checks those. You are also arguing against yourself in some ways - If it is normal to throw in the ctor then it will certainly show up in testing and no harm is done - it is only if it is not normal i.e. exceptional that it might cause a problem in a deployed app but, as you said, exceptional is exactly what exceptions are for.
"Stoitcho Goutsev (100)" <100@100.com> schrieb:
[quoted text, click to view] > You have right to disagree. That's why I said that this is my personal > opinion. > > I'd say it is not common for code to catch *new* statement in a try/catch > and that almost no one check the docs if the constructor throws an > exception. 'FileStream' and other stream classes can throw exceptions from the constructor, as do many other classes. I believe it is less intuitive if the form's 'Show' method is called and the form doesn't get shown for an unknown reason. -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/>
Herfried,
Streams and others may throw exception because there is an exceptional situation - the parameters provided is not correct; that is an error that prevents the object for being created, thus the exceptions is thrown in the constructor. This is not always the case though. Most likely the form can be created, but cannot be shown because some data is missing. In this case the place where the excepction should be thrown is the moment of showing the form. For example at the moment of constructing the form some property might not be set, but it is going to be set later on before showing the form. I don't think this argument leads anywhere. This are design decisions and I believe there is no right and wrong. One should use discretion. [quoted text, click to view] "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message news:uucY$jMTGHA.5156@TK2MSFTNGP10.phx.gbl... > "Stoitcho Goutsev (100)" <100@100.com> schrieb: >> You have right to disagree. That's why I said that this is my personal >> opinion. >> >> I'd say it is not common for code to catch *new* statement in a try/catch >> and that almost no one check the docs if the constructor throws an >> exception. > > 'FileStream' and other stream classes can throw exceptions from the > constructor, as do many other classes. I believe it is less intuitive if > the form's 'Show' method is called and the form doesn't get shown for an > unknown reason. > > -- > M S Herfried K. Wagner > M V P <URL:http://dotnet.mvps.org/> > V B <URL:http://classicvb.org/petition/>
Simply this: it's doing some validation concerning data that belongs to that
form, that I only want to read when the form is invoked. If validation fails I want to issue a message and then close the form. [quoted text, click to view] "Patrice" <a@bc.c> wrote in message news:eNlDuaDTGHA.5736@TK2MSFTNGP10.phx.gbl... > As you can see from the controversial answers you raised, you may want to > explain what you are trying to do exactly. > > My first move would to avoid opening the form at all, rather than to open > the form just so that it can then see there is no need to open... > > -- > Patrice > > "JezB" <jezbroadsword@blueyonder.co.uk> a écrit dans le message de news: > eCZdtx6SGHA.5104@TK2MSFTNGP10.phx.gbl... >> How can I close a form (or stop it from opening, thus returning control >> to its caller) from it's constructor ? >> >> I've tried both the following but they just seem to carry on and open the >> form. >> >> Application.Exit(); >> this.Close(); >> > >
[quoted text, click to view] "JezB" <jezbroadsword@blueyonder.co.uk> wrote in message news:O06KwdyTGHA.4976@TK2MSFTNGP11.phx.gbl... > Simply this: it's doing some validation concerning data that belongs to > that form, that I only want to read when the form is invoked. If > validation fails I want to issue a message and then close the form. You could do something like this: YourForm yf = new YourForm(); if (yf.SomeMethodThatDoesValidation()) { yf.Show(); } else { this.DoSomethingElseInsteadShowingYourForm(); } HTH
Well, in the ctor, it hasn't yet been opened or shown, so there isn't much
to close; you could through an exception? Marc [quoted text, click to view] "JezB" <jezbroadsword@blueyonder.co.uk> wrote in message news:O06KwdyTGHA.4976@TK2MSFTNGP11.phx.gbl... > Simply this: it's doing some validation concerning data that belongs to > that form, that I only want to read when the form is invoked. If > validation fails I want to issue a message and then close the form. > > "Patrice" <a@bc.c> wrote in message > news:eNlDuaDTGHA.5736@TK2MSFTNGP10.phx.gbl... >> As you can see from the controversial answers you raised, you may want to >> explain what you are trying to do exactly. >> >> My first move would to avoid opening the form at all, rather than to open >> the form just so that it can then see there is no need to open... >> >> -- >> Patrice >> >> "JezB" <jezbroadsword@blueyonder.co.uk> a écrit dans le message de news: >> eCZdtx6SGHA.5104@TK2MSFTNGP10.phx.gbl... >>> How can I close a form (or stop it from opening, thus returning control >>> to its caller) from it's constructor ? >>> >>> I've tried both the following but they just seem to carry on and open >>> the form. >>> >>> Application.Exit(); >>> this.Close(); >>> >> >> > >
As you create the form, you take those data from somewhere else ? Can't you
take them from the same location without invoking the form so that you can test if you need to show or not this form. It would seem cleaner to me than to create a form that would retrieve some data in its constructor and would then kill itself based on some test... Other options : - You should be able to create the form without showing it. Some code may help to understand what goes wrong... - You could perhaps use DialogResult in the constructor and close the form in the load event if the DialogResult has the "cancelled" value -- Patrice "JezB" <jezbroadsword@blueyonder.co.uk> a écrit dans le message de news: O06KwdyTGHA.4976@TK2MSFTNGP11.phx.gbl... [quoted text, click to view] > Simply this: it's doing some validation concerning data that belongs to > that form, that I only want to read when the form is invoked. If > validation fails I want to issue a message and then close the form. > > "Patrice" <a@bc.c> wrote in message > news:eNlDuaDTGHA.5736@TK2MSFTNGP10.phx.gbl... >> As you can see from the controversial answers you raised, you may want to >> explain what you are trying to do exactly. >> >> My first move would to avoid opening the form at all, rather than to open >> the form just so that it can then see there is no need to open... >> >> -- >> Patrice >> >> "JezB" <jezbroadsword@blueyonder.co.uk> a écrit dans le message de news: >> eCZdtx6SGHA.5104@TK2MSFTNGP10.phx.gbl... >>> How can I close a form (or stop it from opening, thus returning control >>> to its caller) from it's constructor ? >>> >>> I've tried both the following but they just seem to carry on and open >>> the form. >>> >>> Application.Exit(); >>> this.Close(); >>> >> >> > >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |