WPF ValidationErrors
-
With WPF, you can set the
NotifyOnValidationErrorproperty of some elements to true and add an error handler, e.g.Validation.AddErrorHandler(textID, ItemError);. Starting from a vaild state, you type some nonsense into the textbox, and you receive the event withe.Action = ValidationErrorEventAction.Added. That's what we should expect. But what happens if you type more nonsense into the textbox? Well, you receive another vaildation error withe.Action = ValidationErrorEventAction.Added. Hm, OK, validation failed again, and the error might be different. But now comes the WTF: immediately afterwards, you receive another such event, but now withe.Action = ValidationErrorEventAction.Removed! Yes, "Removed". Everything OK now? Can't be true, there's garbage in the textbox, not valid value. I changed my validator to include the text of the textbox. And voila: in the "Added" event, the current text is shown;, in the "Removed" event, the previous text. By the way, in .Net 3.5 the behavior was the other way round (first remove the previous error, then add the new error), see e.g. validationerror-giving-strange-behavior[^] -
With WPF, you can set the
NotifyOnValidationErrorproperty of some elements to true and add an error handler, e.g.Validation.AddErrorHandler(textID, ItemError);. Starting from a vaild state, you type some nonsense into the textbox, and you receive the event withe.Action = ValidationErrorEventAction.Added. That's what we should expect. But what happens if you type more nonsense into the textbox? Well, you receive another vaildation error withe.Action = ValidationErrorEventAction.Added. Hm, OK, validation failed again, and the error might be different. But now comes the WTF: immediately afterwards, you receive another such event, but now withe.Action = ValidationErrorEventAction.Removed! Yes, "Removed". Everything OK now? Can't be true, there's garbage in the textbox, not valid value. I changed my validator to include the text of the textbox. And voila: in the "Added" event, the current text is shown;, in the "Removed" event, the previous text. By the way, in .Net 3.5 the behavior was the other way round (first remove the previous error, then add the new error), see e.g. validationerror-giving-strange-behavior[^]And that wasn't listed as a breaking change. Wow, M$, you seriously f***** that one up.
What do you get when you cross a joke with a rhetorical question? The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism. Do questions with multiple question marks annoy you???
-
With WPF, you can set the
NotifyOnValidationErrorproperty of some elements to true and add an error handler, e.g.Validation.AddErrorHandler(textID, ItemError);. Starting from a vaild state, you type some nonsense into the textbox, and you receive the event withe.Action = ValidationErrorEventAction.Added. That's what we should expect. But what happens if you type more nonsense into the textbox? Well, you receive another vaildation error withe.Action = ValidationErrorEventAction.Added. Hm, OK, validation failed again, and the error might be different. But now comes the WTF: immediately afterwards, you receive another such event, but now withe.Action = ValidationErrorEventAction.Removed! Yes, "Removed". Everything OK now? Can't be true, there's garbage in the textbox, not valid value. I changed my validator to include the text of the textbox. And voila: in the "Added" event, the current text is shown;, in the "Removed" event, the previous text. By the way, in .Net 3.5 the behavior was the other way round (first remove the previous error, then add the new error), see e.g. validationerror-giving-strange-behavior[^]That's only one of the million reasons why nobody should validate user input. Ever! A developer's productivity is totally sabotaged when he's sent to the input validation pits. Not to talk about motivation! There should be a role for that: we already have test engineers, so why not? :doh: Well, there is not a specific role that I know of, but apparently there is a profoundly wise rule: GIGO[^]. If a user is stupid or mean enough to feed garbage into the software, then they totally deserve to be handed back some pile of cr@p. :D Just sayin'.
Anything that could possibly go wrong in some moment, will definitely go wrong in the worst possible moment...
In the worst way that could be possible!–Finagle's corollary to Murphy's Law (paraphrased).
-
That's only one of the million reasons why nobody should validate user input. Ever! A developer's productivity is totally sabotaged when he's sent to the input validation pits. Not to talk about motivation! There should be a role for that: we already have test engineers, so why not? :doh: Well, there is not a specific role that I know of, but apparently there is a profoundly wise rule: GIGO[^]. If a user is stupid or mean enough to feed garbage into the software, then they totally deserve to be handed back some pile of cr@p. :D Just sayin'.
Anything that could possibly go wrong in some moment, will definitely go wrong in the worst possible moment...
In the worst way that could be possible!–Finagle's corollary to Murphy's Law (paraphrased).
You are right. But I want to make the programs fool-proof when they are intended for my own use: I know my tyipng bheavior.
-
That's only one of the million reasons why nobody should validate user input. Ever! A developer's productivity is totally sabotaged when he's sent to the input validation pits. Not to talk about motivation! There should be a role for that: we already have test engineers, so why not? :doh: Well, there is not a specific role that I know of, but apparently there is a profoundly wise rule: GIGO[^]. If a user is stupid or mean enough to feed garbage into the software, then they totally deserve to be handed back some pile of cr@p. :D Just sayin'.
Anything that could possibly go wrong in some moment, will definitely go wrong in the worst possible moment...
In the worst way that could be possible!–Finagle's corollary to Murphy's Law (paraphrased).
I agree and don't. Input-validation is a nice thing, if it is generated; especially cool for banknumbers and social security-numbers, things where I tend to make mistakes. Most of the validations CAN be generated, so why aren't they? It is not something that one should blindly spend money on; in that case it will simply cost money, often without knowing the return-on-investment of the effort - how many errors did it actually prevent, and at what cost? No, it is more valuable to invest time and think about what errors you want to prevent. One of the things often omitted is the check for duplicate records - many places use identity-fields simply to not have to worry about a primary key-field.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
You are right. But I want to make the programs fool-proof when they are intended for my own use: I know my tyipng bheavior.
Tip; turn of your spellchecker. I've seen more errors in recent "spell checked" documents than in old unchecked versions. I think that the spellcheckers are causing them, instead of preventing.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
Tip; turn of your spellchecker. I've seen more errors in recent "spell checked" documents than in old unchecked versions. I think that the spellcheckers are causing them, instead of preventing.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Or the Autocowreck (AKA Autoincorrect)
What do you get when you cross a joke with a rhetorical question? The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism. Do questions with multiple question marks annoy you???
-
With WPF, you can set the
NotifyOnValidationErrorproperty of some elements to true and add an error handler, e.g.Validation.AddErrorHandler(textID, ItemError);. Starting from a vaild state, you type some nonsense into the textbox, and you receive the event withe.Action = ValidationErrorEventAction.Added. That's what we should expect. But what happens if you type more nonsense into the textbox? Well, you receive another vaildation error withe.Action = ValidationErrorEventAction.Added. Hm, OK, validation failed again, and the error might be different. But now comes the WTF: immediately afterwards, you receive another such event, but now withe.Action = ValidationErrorEventAction.Removed! Yes, "Removed". Everything OK now? Can't be true, there's garbage in the textbox, not valid value. I changed my validator to include the text of the textbox. And voila: in the "Added" event, the current text is shown;, in the "Removed" event, the previous text. By the way, in .Net 3.5 the behavior was the other way round (first remove the previous error, then add the new error), see e.g. validationerror-giving-strange-behavior[^]Looking at the comments[^], the change was made to avoid "a transient 'no error' state". :~
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Looking at the comments[^], the change was made to avoid "a transient 'no error' state". :~
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
That's a good point. Their reason is totally valid. But their solution is NOT. When an error has to be replaced by a different error, the system is in an invalid state when only one of the two steps of adding the new error and removing the old error has been completed. Two errors on the field are as wrong as no error on it. It's similar to transferring money from one bank account to another bank account: do not create or loose money by omitting one step. A solution could be a
transaction. But I think the simplest solution here is similar to aPropertyChangedevent. Get rid of the Added/Removed enum, and take two error properties:OldErrorandNewError. When you leave the valid state,NewErrorcontains the error which is now communicated withAdded, andOldErrorisnull. When an error gets replaced by a different error,NewErrorcontains the freshly incurred error (now withAdded), andOldErrorthe previously encountered error (now withRemoved). When you return to a valid state,NewErrorisnull, andOldErrorthe previously encountered error (now withRemoved). That's a better solution, isn't it? -
That's a good point. Their reason is totally valid. But their solution is NOT. When an error has to be replaced by a different error, the system is in an invalid state when only one of the two steps of adding the new error and removing the old error has been completed. Two errors on the field are as wrong as no error on it. It's similar to transferring money from one bank account to another bank account: do not create or loose money by omitting one step. A solution could be a
transaction. But I think the simplest solution here is similar to aPropertyChangedevent. Get rid of the Added/Removed enum, and take two error properties:OldErrorandNewError. When you leave the valid state,NewErrorcontains the error which is now communicated withAdded, andOldErrorisnull. When an error gets replaced by a different error,NewErrorcontains the freshly incurred error (now withAdded), andOldErrorthe previously encountered error (now withRemoved). When you return to a valid state,NewErrorisnull, andOldErrorthe previously encountered error (now withRemoved). That's a better solution, isn't it?That would be a better solution. Now you just need to convince Microsoft to adopt it! :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
