I am using build 2.6.9.511 Adapter.

I just ran into a strange problem where databinding in a WPF control was clearing out my Field Errors for the field where the databinding was happening. I looked into the EntityBase2.SetValue source code and I see that the field errors are being cleared if DetermineIfFieldShouldBeSet returns false.

First, why is it doing this? I don't understand the comment above the line of code where the error is being cleared:

// clear an error message if applicable, because the value wasn't necessary to be set, which means it's the same as the current so we have to
// get rid of any error messages.

Second, well, if this really is a desired behavior of SetValue, can this be turned off somehow? It doesn't seem to me that calling SetValue and passing in a value that will not change the original value should be clearing the field error. I wanted that error! It was there because the value of the field is invalid, and this fact doesn't change when I set the value to what is was before

Incidentally, the SetValue is being called as a result of the databinding value push when I open my WPF window (and the databinding kicks in).

Hi Mike,

Could you please elaborate more on this? I have a couple of questions:

1. How your field validation logic looks like?

2. How the invalid data got stored in the field? I mean, when you have field validation logic, if the field is not valid (due to your rules) the value isn't set. So at this point an error exists but the value isn't set. If you try to set it again to the (to the "same earlier value" or to the "same invalid value") it wont be set as well and no error cleaning happens. So I guess I don't understand how you get into this problem.

3. What makes your field not settable again? Look at the logic of the DetermineIfFieldShouldBeSet method:

// field value has to be updated in the following situations:
// - when the entity is new and:
//      - the field hasn't been changed
//      - the field has been changed but the value is different, only if the current value is not null
// - when the entity is not new and:
//      - the field is already changed and the value isn't the same value.
//      - the field's DbValue is null and value is not null
//      - the field's DbValue is not null and the field's CurrentValue is different than the new value and not null
//      - the field's CurrentValue is null and value isn't null

daelmo wrote:

Hi Mike,

Could you please elaborate more on this? I have a couple of questions:

1. How your field validation logic looks like?

2. How the invalid data got stored in the field? I mean, when you have field validation logic, if the field is not valid (due to your rules) the value isn't set. So at this point an error exists but the value isn't set. If you try to set it again to the (to the "same earlier value" or to the "same invalid value") it wont be set as well and no error cleaning happens. So I guess I don't understand how you get into this problem.

3. What makes your field not settable again? Look at the logic of the DetermineIfFieldShouldBeSet method:

// field value has to be updated in the following situations:
// - when the entity is new and:
//      - the field hasn't been changed
//      - the field has been changed but the value is different, only if the current value is not null
// - when the entity is not new and:
//      - the field is already changed and the value isn't the same value.
//      - the field's DbValue is null and value is not null
//      - the field's DbValue is not null and the field's CurrentValue is different than the new value and not null
//      - the field's CurrentValue is null and value isn't null

1. It is very complicated, I'll go there if I have to, but trust me...very complicated

2. In my system you can set a field in a way where that field value is invalid due to a value in another field. Like StartDate, EndDate. If I have a validation that says StartDate>EndDate, then I want the user to be able to set a StartDate greater than EndDate (causing an invalid value...which I note to the user) and then they can set the EndDate to something greater than the StartDate. It isn't that I want to completely prevent an invalid value, I want to give the user the opportunity to make it valid, which may require setting another value which by my business logic, un-invalidates the invalid value.

3. It isn't that it isn't settable again. The problem is setting the value to the same value as it was before. When I do this, DetermineIfFieldShouldBeSet returns false and the field error is cleared.

According to your scenario, why setting the field to the same value, doesn't trigger your validation to set the error again. Still it's not valid according to your validation, right?

Walaa wrote:

According to your scenario, why setting the field to the same value, doesn't trigger your validation to set the error again. Still it's not valid according to your validation, right?

This is where it gets complicated a bit

I use PostFieldValueSetAction in my CommonEntityBase to know whether or not a field value was really set using the fieldValueSet value. If fieldValueSet=true then eventually my validation logic is triggered. This fieldValueSet is false the second time a field value is set to the same value, so my validation logic doesn't run again. I have to do this because WPF databinding is constantly pushing field values into the bound entities and I don't want my (sometimes expensive) validation logic running all the time just because WPF is inefficient.

I'm basing this complaint pretty much solely on the logical argument that if a field value is re-pushed to an identical value, that this should not imply that the field error is cleared. This just doesn't make sense unless there is some strange customer requirement that I've never heard of

mikeg22 wrote:

1. It is very complicated, I'll go there if I have to, but trust me...very complicated

Ok. But one simple repro snippet containing all aspects (field validation, postvalue routing and the value set would be helpful to understand completely your scenario.

mikeg22 wrote:

1. In my system you can set a field in a way where that field value is invalid due to a value in another field. Like StartDate, EndDate. If I have a validation that says StartDate>EndDate, then I want the user to be able to set a StartDate greater than EndDate (causing an invalid value...which I note to the user) and then they can set the EndDate to something greater than the StartDate. It isn't that I want to completely prevent an invalid value, I want to give the user the opportunity to make it valid, which may require setting another value which by my business logic, un-invalidates the invalid value.

If a validation rule depends upon another field value the best practice is to set that at entity validation level (instead of ValidateFieldValue) and set the error on the entity instead of the field.

daelmo wrote:

mikeg22 wrote:

1. It is very complicated, I'll go there if I have to, but trust me...very complicated

Ok. But one simple repro snippet containing all aspects (field validation, postvalue routing and the value set would be helpful to understand completely your scenario.

mikeg22 wrote:

1. In my system you can set a field in a way where that field value is invalid due to a value in another field. Like StartDate, EndDate. If I have a validation that says StartDate>EndDate, then I want the user to be able to set a StartDate greater than EndDate (causing an invalid value...which I note to the user) and then they can set the EndDate to something greater than the StartDate. It isn't that I want to completely prevent an invalid value, I want to give the user the opportunity to make it valid, which may require setting another value which by my business logic, un-invalidates the invalid value.

If a validation rule depends upon another field value the best practice is to set that at entity validation level (instead of ValidateFieldValue) and set the error on the entity instead of the field.

1. Ok, I'll give it a shot:

-Field property is set -PostFieldValueSetAction override checks whether fieldValueSet is true, if so, it is recorded that this happened. -OnSetValueComplete overwrite checks for field values which were set (see the first step) raises an event for each of these fields to a listener, call it ValidationListener. -ValidationListener validates the new field value. This is the complicated part. First, field value rules are asserted on the entity owning the field. If the field value is invalid, SetEntityError(message) and SetEntityFieldError(message) are called, setting the error messages on the entity and for the field itself. If the value is valid, errors are cleared. Because of an override I did of SetEntityFieldError in CommonEntityBase, OnPropertyChanged(fieldName) is called in order to get WPF controls to re-check the FieldError for error messages.

This last process is repeated for any field values that are marked as dependent on this field. For example, if StartDate is validated, EndDate also ends up getting validated.

1. I am not using ValidateFieldValue or any of the built-in overrides to do validation as these do not work properly with WPF validation. I had to home-roll this all myself in order to get WPF's ValidatesOnDataErrors Binding property to work correctly with LLBLGen entities and IDataErrorInfo implementation. One of the main problems was that EntityBase2 does field setting steps in an order that by the time an IDataErrorInfo error gets set on an entity or entity's field, WPF has already checked for errors, so new errors are not shown.

So, my problem here is that LLBLGen is getting a little too involved with the setting and clearing of IDataErrorInfo errors in it's base classes by explicitly clearing the errors when it thinks it is appropriate to do so without giving some ability to override this behavior. I would like to know first why it is doing this in the first place, and if the answer makes sense in some methods of validation, I would like to have the ability to override this so I can do my own method of validation.

The error is cleared when a value can be set. This means that validation passed the value and the value is accepted. An error is then no longer necessary to stick around, as whatever error it was, it was resolved: the value was accepted.

if you don't want that, and the only reason for that I can think of is if the error has to stay around, refuse the value. Why else would you want to allow a value but keep the error as well? (which is solely there for notifying the user that the value entered is not accepted/wrong ? )

Otis wrote:

The error is cleared when a value can be set. This means that validation passed the value and the value is accepted. An error is then no longer necessary to stick around, as whatever error it was, it was resolved: the value was accepted.

if you don't want that, and the only reason for that I can think of is if the error has to stay around, refuse the value. Why else would you want to allow a value but keep the error as well? (which is solely there for notifying the user that the value entered is not accepted/wrong ? )

[EDIT] I just reread your post and it sounds like I can reject a field being set and thereby keeping the error from being cleared? So I can just check if there is an error to begin with in one of your validation overrides and if there is, reject the change, and all is well?

[rest of post] The reason is that a field error can be corrected not only by changing that field's value. For example, StartDate/EndDate. If EndDate is 1/1/2005, I should be able to set StartDate to 1/1/2006, but after this, both StartDate and EndDate are in error. One has to be fixed, but it isn't clear which one. I want the user to know that both field values are invalid. I suppose this could be done with a normal Entity's IDataInfoError.Error but this takes away my ability to really use IDataErrorInfo to be able to have field specific errors, which is a big problem as I use these field specific errors for red outlined, hover-over, really user friendly error messages in my GUIs.

If the idea is that a field cannot be set to a value that is "invalid", then the same problem as I describe can happen also in this scenario: 1. A field Field1 is set to a value 2. Something happens in the business logic which invalidates this value, setting Field1's error message. 3. The databinding system (WPF or whatever it is) re-pushes the value. 4. Given how the code works now, the field error is cleared.

Maybe I am not hooking in at the right places here. I am also a bit confused as to how the system is intended to work. Is it completely impossible to set a field's value to something that ends up setting the field's error? If the answer to this is "no, it is not impossible" then why does reasserting the same value lead to a different result as the initial set (clearing the error)?

Honestly, I thought that I had complete control over field errors and entity errors, although I could use the LLBLGen validation hooks if I wanted to.

You know, I'm going to read through the help file and figure out if I can make this work by doing validation the way EntityBase2 wants me to do it...

I just thought I could completely control the IDataErrorInfo setting and clearing myself. I wasn't aware that the LLBLGen framework itself was doing this.

Ok, I read the validation section of the help file and its pretty much what I thought. If validation fails, the field error is set manually and the field is not set to the invalid value.

My validation doesn't work this way. I want the user to be able to set a field to an invalid value, because the invalidity of that field may depend on the value of some other field. Like I said before, StartDate/EndDate. If StartDate>EndDate then both field values are considered invalid. This doesn't mean that the StartDate or EndDate values are inherently invalid. StartDate can be made valid again by changing the EndDate value and vice-versa.

So, what I am saying is that the user needs to be able to set a property value to an invalid value. Because of this, I cannot implement OnValidateFieldValue the way you intended. I cannot override this method and return false when a field is invalid, because I still want the field value to be set. I make a field invalid by setting its IDataErrorInfo.Item[field] error message, and that's it.

EntityBase2 clears out this field error message when a field is set but doesn't need to be set (because it didn't change). This makes some sense if OnValidateFieldValue is used to mark a field as invalid (by returning false) because like you have said, if this returns false, that "error clearing" call never happens. I am dealing with validation differently though. I need the user to be able to set a value to an invalid value, because it could later become valid by changing another field's value (or add/removing another entity from the graph, or whatever determines the validity of that field value).

It seems like the root of the problem I am having is that you allow pluggable validation, but you have IDataErrorInfo logic in the EntityBase2 assuming that the only way the validation could work is by using the hooks you provide (OnValidateFieldValue). It would be nice if I could set a flag somewhere to totally bypass your validation implementation. You have this with buildInValidationBypassMode, so maybe you could extend this idea to the IDataErrorInfo code in your base classes, so that if I set buildInValidationBypassMode=AlwaysBypass, this would also bypass that one line of code which is causing me such a headache

I double what David (daelmo) said.

daelmo wrote:

If a validation rule depends upon another field value the best practice is to set that at entity validation level (instead of ValidateFieldValue) and set the error on the entity instead of the field.

If your validation is cross fields validation (startDate/endDate) then don't validate the field, rather validate the entity. (ValidateEntity)

Walaa wrote:

I double what David (daelmo) said.

daelmo wrote:

If a validation rule depends upon another field value the best practice is to set that at entity validation level (instead of ValidateFieldValue) and set the error on the entity instead of the field.

If your validation is cross fields validation (startDate/endDate) then don't validate the field, rather validate the entity. (ValidateEntity)

I know that's how LLBLGen's validation works, but I want to implement my own validation where cross-field validation can lead to both fields being invalid. This makes more sense to me, and it much nicer to be able to show the user which fields are involved with error messages on those fields.

Nothing stops you from calling entity.SetEntityFieldError. The validation bypass is for validation bypass If a valid value is set in a field, the FIELD error is considered obsolete (as that's the ONLY way to clear it automatically, and this won't be changed as there's no other way to do this automatically and it does make sense).

I understand that if two fields are related, and one is not set or invalid, the other one might also be invalid (e.g. you have a 'HasAddress' field which is true and you then want all address fields (street, housenr...) to get an error till they're set). However when a value is set to the field which is VALID, that field's error can only be switched off, which is done right away.

If you don't want that, or better: you want to post-validate the ENTITY (as error clearing is for field only, you're talking about entity validation) after a field is set, override OnSetValueComplete and call your validation again there. That method is called after the error is cleared.

Otis wrote:

Nothing stops you from calling entity.SetEntityFieldError. The validation bypass is for validation bypass If a valid value is set in a field, the FIELD error is considered obsolete (as that's the ONLY way to clear it automatically, and this won't be changed as there's no other way to do this automatically and it does make sense).

I understand that if two fields are related, and one is not set or invalid, the other one might also be invalid (e.g. you have a 'HasAddress' field which is true and you then want all address fields (street, housenr...) to get an error till they're set). However when a value is set to the field which is VALID, that field's error can only be switched off, which is done right away.

If you don't want that, or better: you want to post-validate the ENTITY (as error clearing is for field only, you're talking about entity validation) after a field is set, override OnSetValueComplete and call your validation again there. That method is called after the error is cleared.

Ok, I think I know how to trick the system to get around this. I just need to have the field register as invalid whenever there is a field error present (which I have previously set using my own validation mechanism), and then the field error will not end up being cleared in the situation where the same value is "re pushed" by databinding.

I never really understood what it meant to have an entity be invalid. I can see a field value being invalid meaning that the value of that field is contributing to the breaking of a business rule. But how can an entity itself be invalid? I mean what situation could there be that an entity being invalid isn't just ultimately because it's fields are invalid? I know that the LLBLGen system treats cross-field invalidations as the "entity being invalid", but to me this is just a cop out...it is the fields involved in the cross-field invalidation that are invalid, not the entity!

Well, anyway I have a solution to this. Thanks for your help.

Just to answer the philosiphy behind the invalid entity.

Validating a field, means when you examin a field, as a stand-alone value and without comparing it or associating it with another field or state, you can determine if its value is valid or not.

Examples: - Person's BirthDate which still to come (in the future). - Person's Age in negative. - Person's Gender represented by a Char(1) which accepts either 'M' or 'F', but the value passed is 'X'.

Validating an entity, means when you inspect the entity as a unit, you can determine if there are some contradicting data or not.

Example: - Start Date is greater than End Date (unless you are travelling back in time), in this case the entity is invalid, but you can't realy tell which of these fields has the wrong/invalid value. Would you ask the user to modify the Start Date or to modify the End Date to have a valid entity?

That's why in your case, I'd say the Start date is valid, and the End Date is valid, but looking at them together or looking at the entity, that's when you realize something is wrong.

Now it's time for me to put down the Philosopher's stone

Walaa wrote:

Just to answer the philosiphy behind the invalid entity.

Validating a field, means when you examin a field, as a stand-alone value and without comparing it or associating it with another field or state, you can determine if its value is valid or not.

Examples: - Person's BirthDate which still to come (in the future). - Person's Age in negative. - Person's Gender represented by a Char(1) which accepts either 'M' or 'F', but the value passed is 'X'.

Validating an entity, means when you inspect the entity as a unit, you can determine if there are some contradicting data or not.

Example: - Start Date is greater than End Date (unless you are travelling back in time), in this case the entity is invalid, but you can't realy tell which of these fields has the wrong/invalid value. Would you ask the user to modify the Start Date or to modify the End Date to have a valid entity?

That's why in your case, I'd say the Start date is valid, and the End Date is valid, but looking at them together or looking at the entity, that's when you realize something is wrong.

Now it's time for me to put down the Philosopher's stone

Thanks for the laying out of the philosophy.

I still don't get why there is the distinction, though. For example, lets say there is a "Birthday" field. Say you have a rule where Birthday cannot be after the current date. In this example, the validity of Birthday doesn't only rely on the value of Birthday. It also relies on the value of "current date." By the philosophy you have layed out above, in the situation where Birthday is after "current date", the Birthday wouldn't be invalid, but the containing entity would. Because the validity is determined by: 1. The value of Birthday 2. The value of "current date"

The fact that "current date" is not in the entity itself is irrelevant as to how I view the situation. The fact of the matter is that the value of Birthday has broken a rule, so it is invalid. I see this as an identical situation to the rule: Age=CurrentDate-Birthday. If there is an "Age" property that is set explicitly and not calculated, then entering an Age that breaks this rule is entering an invalid value. It doesn't matter that the rule happens to rely on other fields in the entity...this could change to relying on anything in the world...maybe the phase of the moon? The fact of the matter is that certain values of Age are valid and certain values are invalid.

That's how I see it.

All your examples are FieldValidation, since you can spot (logically) which field is invalid.

But in the former case of StartDate and EndDate, you can't really tell which of these is invalid. But rather both of them can't be met together (hence the entity is invalid).

Walaa wrote:

All your examples are FieldValidation, since you can spot (logically) which field is invalid.

But in the former case of StartDate and EndDate, you can't really tell which of these is invalid. But rather both of them can't be met together (hence the entity is invalid).

I think you need to say both fields are invalid. The LLBlGen alternative is to say that "the entity is invalid". This breaks down completely when the involved fields are in two different entities, which LLBLGen has no solution to. Are both involved entities now invalid?

If this is the case, you can't say that both entities are invalid or else you run into the same dilemma as not knowing which field is invalid, which is that you need to specify which entity is invalid, and following your logic, you can't know this and you can't just say "both are invalid"...you need to pass the problem even further up the chain (to stay philosophically consistent) and say "the entire entity graph is invalid". Well, this is becoming more and more useless as the validity is really about two fields, it isn't about the entire entity graph.

By saying an entity is invalid because two of it's fields contribute to the breaking of a business rule is losing a lot of granularity as to what the broken rule really is about. Using normal LLBLGen, if I have the classic StartDate<EndDate rule, and I break this rule, I cannot tie IDataErrorInfo error messages to those two fields. I am forced to tie the error message to the entity, which will make the error harder to find for the user (as IDataErrorInfo error messages can be tied directly to the control where the error is).

And god forbid the user sets a field value which breaks a rule tied to another field in another entity, which isn't even on the screen. Because of this idea that a field cannot be invalid if the business rule involved another field somewhere else, I cannot show an error message on this field control that the user just set...This is just making life so much harder

Let's say that comparing a field with any value from outside the entity is just FieldValidation, whther this value is the system date, or a value from another related entity. And comparing 2 or more fields from the same entity is the EntityValidation.

This should wrap it it for this debate

But the problem here is not with the concept, I think your issue as you have described below:

1. In my system you can set a field in a way where that field value is invalid due to a value in another field. Like StartDate, EndDate. If I have a validation that says StartDate>EndDate, then I want the user to be able to set a StartDate greater than EndDate (causing an invalid value...which I note to the user) and then they can set the EndDate to something greater than the StartDate. It isn't that I want to completely prevent an invalid value, I want to give the user the opportunity to make it valid, which may require setting another value which by my business logic, un-invalidates the invalid value.

Is that you want to retian the invalid value inside the field to be able to show the error message to the user and let him correct or modify another field. (If I were the user, I'd think that the other field is the invalid one ).

Since we can't let an invalid value (according to FieldValidation) to be stored in a field. IMHO, you should solve this by avoiding the FieldValidation altogether as that's a low level validation, and handle this in the UI.

i.e. Disable any submitting button if the StartDate > EndDate, and notify the user about it. This way databinding will keep the invalid values inside the fields, as no FieldValidation is there to prevent this. And yet the action can't be completed till this is corrected.

Walaa wrote:

Let's say that comparing a field with any value from outside the entity is just FieldValidation, whther this value is the system date, or a value from another related entity. And comparing 2 or more fields from the same entity is the EntityValidation.

This should wrap it it for this debate

But the problem here is not with the concept, I think your issue as you have described below:

1. In my system you can set a field in a way where that field value is invalid due to a value in another field. Like StartDate, EndDate. If I have a validation that says StartDate>EndDate, then I want the user to be able to set a StartDate greater than EndDate (causing an invalid value...which I note to the user) and then they can set the EndDate to something greater than the StartDate. It isn't that I want to completely prevent an invalid value, I want to give the user the opportunity to make it valid, which may require setting another value which by my business logic, un-invalidates the invalid value.

Is that you want to retian the invalid value inside the field to be able to show the error message to the user and let him correct or modify another field. (If I were the user, I'd think that the other field is the invalid one ).

Since we can't let an invalid value (according to FieldValidation) to be stored in a field. IMHO, you should solve this by avoiding the FieldValidation altogether as that's a low level validation, and handle this in the UI.

i.e. Disable any submitting button if the StartDate > EndDate, and notify the user about it. This way databinding will keep the invalid values inside the fields, as no FieldValidation is there to prevent this. And yet the action can't be completed till this is corrected.

Ok, end of debate

I want to be able to use IDataErrorInfo for this because WPF deals with this so well using ValidatesOnDataErrors. All I wanted was the ability to override the clearing of the field error on a successful field set. It sounds like I'm not going to get that, so I'll move on with plan B, which is to just never re-set the property to the same value it was before if there is already a field error on that field. Not that big a deal, but I just wanted you guys to know that the clearing of the field error interferes with custom validation...even though that custom validation may seem crazy to you all

mikeg22 wrote:

Ok, end of debate

Good

mikeg22 wrote:

I want to be able to use IDataErrorInfo for this because WPF deals with this so well using ValidatesOnDataErrors. All I wanted was the ability to override the clearing of the field error on a successful field set. It sounds like I'm not going to get that, so I'll move on with plan B, which is to just never re-set the property to the same value it was before if there is already a field error on that field.

Here you go with a workaround if you want to try: http://llblgen.com/tinyforum/Messages.aspx?ThreadID=14244&StartAtMessage=0&#79435

daelmo wrote:

mikeg22 wrote:

Ok, end of debate

Good

mikeg22 wrote:

I want to be able to use IDataErrorInfo for this because WPF deals with this so well using ValidatesOnDataErrors. All I wanted was the ability to override the clearing of the field error on a successful field set. It sounds like I'm not going to get that, so I'll move on with plan B, which is to just never re-set the property to the same value it was before if there is already a field error on that field.

Here you go with a workaround if you want to try: http://llblgen.com/tinyforum/Messages.aspx?ThreadID=14244&StartAtMessage=0&#79435

Thanks for the link to that thread. I'm going to try that out

Good. I'm going to close this thread temporally. Reopen it when you have news about the workaround. Cheers.