errorProvider

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I've got an error provider that I want ignored if somebody tries to close the
application. Right now, when bad input is given, I'm simply setting
e.Cancel=true in the texbox_validating handler, and then setting e.Cancel =
false in the FormClosing handler. Is there a more correct way to do this?
 
I've got an error provider that I want ignored if somebody tries to close the
application. Right now, when bad input is given, I'm simply setting
e.Cancel=true in the texbox_validating handler, and then setting e.Cancel =
false in the FormClosing handler. Is there a more correct way to do this?
Click to expand...

If the user clicks a button to close the form without saving data ( a Cancel
Button maybe?) Set it's CausesValidation property to false. You may be using a
different type of control to exit the app, but the principle would be the same
if it has a CausesValidation property.

Otis Mukinfus
http://www.arltex.com
http://www.tomchilders.com
 
If the user clicks a button to close the form without saving data ( a Cancel
Button maybe?) Set it's CausesValidation property to false. You may be using a
different type of control to exit the app, but the principle would be the same
if it has a CausesValidation property.
Click to expand...

On your prompting, I have been experimenting with "CausesValidation" and
"AutoValidate," noticing that those two cover most of what I'm looking for.
However, the particular means of closing the app that I was referring to - is
by using the standard application close 'X' button in the top right corner of
every framed window. I tried setting the "CausesValidation" of the form to
false, but it seems to be ignored when I hit the frame's close button. Is
there a way of setting the frame's "CausesValidation" to false?

Also, all this experimenting has led me to ask - how is it that the
"e.cancel" that I set in the TextBox_Validating handler, is still "set" when
immediately afterward the "form_FormClosing" handler is executed? What I'm
trying to say is, I would expect that the FormClosingEventArgs parameter of
"form_FormClosing" would have no relationship with the CancelEventArgs
parameter of the "textbox_Validating" handler. Perhaps there is a particular
article I should read that explains the underlying mechanics?
 
On your prompting, I have been experimenting with "CausesValidation" and
"AutoValidate," noticing that those two cover most of what I'm looking for.
However, the particular means of closing the app that I was referring to - is
by using the standard application close 'X' button in the top right corner of
every framed window. I tried setting the "CausesValidation" of the form to
false, but it seems to be ignored when I hit the frame's close button. Is
there a way of setting the frame's "CausesValidation" to false?
Click to expand...

When you refer to the 'frame' are you referring to the form? I'm not sure I
know the answer to the question above.
Also, all this experimenting has led me to ask - how is it that the
"e.cancel" that I set in the TextBox_Validating handler, is still "set" when
immediately afterward the "form_FormClosing" handler is executed? What I'm
trying to say is, I would expect that the FormClosingEventArgs parameter of
"form_FormClosing" would have no relationship with the CancelEventArgs
parameter of the "textbox_Validating" handler. Perhaps there is a particular
article I should read that explains the underlying mechanics?
Click to expand...

I think you would want the validation to occur at every point except when a
Cancel button or some other obvious (to the user) method of bail-out from the
form is used. In my opinion, there should only be one way to exit a form
without saving data that was changed. That would typically be a Cancel button.
If a user attempts to leave a form without saving Validated data they should be
warned that they are doing so. As would be the case with the close button which
you trap in the Form_Closing event. If you turn off validation at the form level
that would allow invalid data to be saved.

I don't understand the behavior of the close button's validation process you
experienced, either.


Otis Mukinfus
http://www.arltex.com
http://www.tomchilders.com
 
When you refer to the 'frame' are you referring to the form? I'm not sure I
know the answer to the question above.
Click to expand...

I'm using win32 jargon, because I don't know what else to call it. Every
window/form has a bright red 'X' in the top right corner, right next to the
minimize and maximize buttons. If you click that 'X', and if it is the main
application window/form, then it will cause the application to close. This
is the button I'm trying to work with. In win32 jargon, the location of the
minimize, maximize, and application close button...was called the window
"frame."
I think you would want the validation to occur at every point except when a
Cancel button or some other obvious (to the user) method of bail-out from the
form is used. In my opinion, there should only be one way to exit a form
without saving data that was changed. That would typically be a Cancel button.
Click to expand...

Yes, I agree. But the one exception is the "application close" button - the
bright red 'X' in the top right corner. That button should also be obeyed -
particularly when the user is hitting that button in an attempt to completely
close the entire application.

I wish I could set properties on the minimize, maximize, and application
close buttons (which are on every form)...just like I do with regular
controls that I drag and drop onto a form. But I can't (as far as I can
tell). It seems the closest I can get, is setting properties on the form
which has those typical buttons.
 
I'm using win32 jargon, because I don't know what else to call it. Every
window/form has a bright red 'X' in the top right corner, right next to the
minimize and maximize buttons. If you click that 'X', and if it is the main
application window/form, then it will cause the application to close. This
is the button I'm trying to work with. In win32 jargon, the location of the
minimize, maximize, and application close button...was called the window
"frame."


Yes, I agree. But the one exception is the "application close" button - the
bright red 'X' in the top right corner. That button should also be obeyed -
particularly when the user is hitting that button in an attempt to completely
close the entire application.

I wish I could set properties on the minimize, maximize, and application
close buttons (which are on every form)...just like I do with regular
controls that I drag and drop onto a form. But I can't (as far as I can
tell). It seems the closest I can get, is setting properties on the form
which has those typical buttons.
Click to expand...
You **can** set the max min and close buttons to hidden in .NET.

Set ControlBox, MaximizeBox and MinimizeBox properties of your form to false and
you will have "Dialog Box" top on the form.

Sorry about the question regarding the "frame". It's been a long time since
C++/win32 for me.

Otis Mukinfus
http://www.arltex.com
http://www.tomchilders.com
 
You **can** set the max min and close buttons to hidden in .NET.

Ok, I see those options. But what if I don't want to hide them? What if I
want to *allow* somebody to close the application while illegal values still
sit in one or more textboxes? Although I've gotten this to work
(e.cancel=false or AutoValidate=disabled), I'm still not sure I'm doing it
the "canonical" way.

In other words, I think our discussion has gone full circle. :]
Sorry about the question regarding the "frame". It's been a long time since
C++/win32 for me.
Click to expand...

So, what *do* they call the "frame," on a WinForm? Um, or at least, what
are they calling that fat blue bar at the top of every window? :)
 
Hi,
There is one more method which I know for accomplishingthis without
hiding the titlebar buttons. Although this may sound a bit cumbersome,
but it works.

On the event FormClosing (each win form has an event associated called
FormClosing which gets fired on any action which results in closing of
form), disable the CausesValidation property of all the 'validated
controls' to false. You can also perform this by putting all such
controls on the form in a loop, something like:

foreach (Control ctrl in FormName.Controls)
{
if
(ctrl.GetType().ToString().Equals("System.Windows.Forms.TextBox") ||
ctrl.GetType().ToString().Equals("System.Windows.Forms.ComboBox"))
ctrl.CausesValidation = false;
}

You can also check for the reason of form closing by comparing
"e.CloseReason" with the values of "CloseReason" enumeration, and so
accordingly prompt some message on user action.

I hope this solves your problem.

Abhishek
 
You **can** set the max min and close buttons to hidden in .NET.
Click to expand...

Ok, I see those options. But what if I don't want to hide them? What if I
want to *allow* somebody to close the application while illegal values still
sit in one or more textboxes? Although I've gotten this to work
(e.cancel=false or AutoValidate=disabled), I'm still not sure I'm doing it
the "canonical" way.

In other words, I think our discussion has gone full circle. :]
Sorry about the question regarding the "frame". It's been a long time since
C++/win32 for me.
Click to expand...

So, what *do* they call the "frame," on a WinForm? Um, or at least, what
are they calling that fat blue bar at the top of every window? :)
Click to expand...
Hmmmm.... TitleBar works for me, but that's probably not the correct term.

Well, Mystagogue, it's been an interesting discussion. I learned some things
and I hope you did too.

Otis Mukinfus
http://www.arltex.com
http://www.tomchilders.com
 
Back
Top