Hello,

I'm using the latest demo version (2.5 Final Demo) with .NET 3.5, template: SelfServicing.TwoClasses 2008.

I'm (still) evaluating LLBLGen pro: I like it a lot. I am using LLBLGen's build in validation mechanism, which turns out to be quite easy and productive. There's just one thing that bothers me:

I have a mandatory (NOT NULL) field called Name, on an Entity (customer). I have a textbox's Text property bound to an entity's Name property. I set the binding to "OnPropertyChanged", for instant feedback. When the form is displayed with a new entity, the controls start out empty. You can then type a name.

IF the entity Name property contains a value, and you clear the name, the validation class rejects the value (returns false) and the error provider blinks with it's icon. This is exactly the behavior we want. Now there's just one flaw in this system: When the validation rejects the value, the property of the entity remains unchanged (the last value of the entity remains). Somehow, the control is notified of a propertychange (we think), since this last value is also restored to the textbox.

For example: if I type a T (into an empty field) and then press backspace again to remove it, the T is restored and the icon blinks. This means the icon indicates an error, but the text has been restored so there IS no error.

If we change the field validation to return true (so it accepts the empty value) but still set the field error, no error message is shown.

I looked at the LLBLGen pro example (LLBLGenPro - Validation Example - Selfservicing: The Customer's section). You use databinding too, and you achieve the effect we desire (plus, your validation function DOES return false, so the property on the entity is set!).

I was wondering what I'm doing wrong here? Changing the updatemode to OnValidation doesn't matter: if you empty the Name field and then tab to another, the value is also restored (and the error icon shows up again).

Just to point out some of the differences between my setup and the example: - I'm not using a EntityCollection or a binding source: I bind the controls directly to the entity

Kind regards,

Jeroen.

Here is how I see it.

Field & Entity Validations should be used to prevent improper values inside an entity. This should be used as a base or one of the last lines of defense.

The problem comes when people try to use it to solve GUI issues, speaking about this any form (web or windows), should have its own input validations.

Which in most cases might be a redundant work, but it's inevitable IMHO. So when I build a web form, I put a validator control to check that Fright is greated than Zero, and another one to check that the OrderDate is before the ShipDate, otherwise the page is not validated and a post back will be stopped. This is most helpful in databinding situations. I don't like to start the back path of a 2-way databinding if the inputs are invalid.

So why using Field Validations & Entity Validations in the first place if it would be taken care of in the GUI ? Ans: Since an entity can be updated in code.

IMHO Validations should exist in all layers (DAL, BL, and PL).

Anyway, please check the following similar discussion: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=12654

Well, I found the problem. I spend a couple of days on this so I thought I'd share my findings with you.

Sometimes the solution is as simple as typing a few characters extra:

I bind the form controls directly to an Entity object via code. The Customers example binds controls via the designer. While browsing through the designer generated code, I noticed that the designer created DataBindings with formattingEnabled set to true (constructor with 4 parameters). I used the 3 parameters constructor (which appearantly sets FormattingEnabled to false). With FormattingEnabled set to true, a control can contain invalid values. When it's set to false, the control rejects invalid values and returns to the last valid value (which is quite frustrating for the user).

Validation now works exactly the way we want it. You can empty a field, which will display the error. You can choose to resolve the error whenever you want. (Don't forget to check for errors if the user clicks save!)

Btw we are developing a Windows application, not a web application.

Kind regards,

Jeroen

Thank you very much for sharing your findings, I'm sure this will help many others going into the same path.