Validation in Wisej.NET

Build the ValidationClinic intake form around two opportunities to catch mistakes: when the user leaves a field, and when the user saves. In Wisej.NET, these checks work together so an untouched field cannot escape validation.

Run quick checks in the Validating event, before the user moves on. The browser reports the focus change, but your C sharp handler executes on the server. Keeping that handler short avoids making ordinary navigation feel slow.

Use Validating to decide whether the value is acceptable. Cancel the event and explain the problem when it is not. Validated follows only a successful check, making it the appropriate place for cleanup such as trimming an accepted name.

Set the form’s AutoValidate behavior in its constructor. In each handler, SetError explains a rejected value and e.Cancel rejects it. Clear the message after correction so the interface reflects the current value rather than an earlier mistake.

Keep focus on an invalid field when the user needs to correct it. Give Cancel a separate escape route by setting CausesValidation to false. Otherwise, validation could prevent someone from abandoning an incomplete form.

Before writing the customer, call ValidateChildren from Save. This also checks fields the user never visited. If any handler cancels validation, stop the save; only accepted values should reach the write operation and its exception handling.

Watch the empty name keep focus while the error icon explains why. After correction, the accepted name is trimmed. The malformed email is rejected independently, while Cancel still closes the form without requiring either field to be fixed.

Test Save before touching the email field. ValidateChildren finds that missing input and prevents the write even though no focus change occurred there. Correct the address and save again to confirm that valid input follows the successful path.

For this lab, connect field validation, successful-value cleanup, and the final Save check in one intake form. Test Cancel with invalid input as well. Your lab note should explain how these paths prevent bad data without trapping the user.

Give the contact form feedback that remains useful after the first mistake. One ErrorProvider handles the icons, reusable helpers decide which values are invalid, and a visible summary lets users review every problem together.

Separate checking a value from displaying its error. Independent field handlers can leave stale icons or clear unrelated messages. A shared approach makes each correction affect the relevant field while preserving problems that still need attention.

Choose how each message reaches the user. SetError adds an icon beside an input, while InvalidMessage supplies the control’s own tooltip. The summary provides readable text for the whole form, so errors are not discoverable only by hovering.

Configure a single ErrorProvider for the form, with steady icons placed to the right. Let ValidateEmail return a FieldValidation result instead of changing controls. That separation keeps the rule reusable and leaves presentation to the form.

Apply processes every result, including successful ones. An empty message removes that field’s old icon; invalid results also populate the summary. Returning whether all results passed gives Save a clear decision before any data is written.

Match the feedback to the problem. Put a field correction beside its input, explain a business rule in the save summary, and give a system failure its own friendly message. Users should understand which action is available to them.

Save the form with the three invalid contact fields. Compare the local icons with the summary: both should describe the same remaining problems. The customer-code tooltip demonstrates the alternative display path without replacing the form-wide explanation.

Correct only the email and leave that field. Its icon and summary entry disappear, but the name and phone messages remain. This demonstrates why individual results must clear individual errors rather than clearing the entire provider.

Build the helpers, shared ErrorProvider, and Apply method as one feedback path. Verify that correcting one field preserves other errors. Compare the customer-code InvalidMessage with the icons and summary to explain when each presentation is useful.

Move the repeated field rules into the Validation extender. In Wisej.NET, describing each field’s requirements lets the extender run consistent checks for ValidationClinic, while the form remains responsible for presenting useful feedback to the user.

The extender connects to Validating and Validated on the controls. Instead of repeating the same empty-value check in several handlers, attach rule metadata to each field. The event flow stays familiar while the definitions become easier to share.

Choose a built-in rule for the kind of value you accept, such as email, integer, currency, or telephone. Use a regular expression when the required pattern needs it. Give each rule an InvalidMessage that explains the correction in the user’s language.

Add Validation in the designer, then open a control’s ValidationRules collection. Put Required before Email. The collection order is also execution order, so arranging these entries determines which explanation the user receives first.

A rule failure stops the remaining rules and cancels validation. That is why an empty email should fail Required first: asking for a missing address is more useful than reporting a format problem before any address exists.

Runtime configuration follows the same rule model. Build the arrays once in ClinicRules, select the display target, then assign each field through SetValidationRules. Keeping the definitions together avoids slightly different copies of the same rule across forms.

Compare an empty address, a malformed address, and a valid one. Each attempt should produce only the first applicable error. When the value becomes valid, both the icon and summary entry clear, confirming that presentation follows the latest validation result.

The rules can send feedback to the control, an ErrorProvider, or a label. Choose the target deliberately, then update the summary from the extender’s own events. This keeps the summary synchronized with the checks that actually ran.

Replace the repeated handlers with shared ClinicRules definitions. Keep Required first and connect the summary to the extender’s events. Your test should show that empty, malformed, and corrected values produce the appropriate message without retaining obsolete feedback.

Module four. Custom validation in Wisej.NET. A form can accept correctly formatted values that still break business rules. Let's fix that.

Built-in rules check the shape of one value. But a valid date can still come after an end date, and a valid birth date can belong to someone too young. These are business rules. When you compare fields, calculate an age, or check values together, write a custom validation rule.

Custom validation has three homes. First, a method that returns an error message. Second, a service that returns ValidationMessage records. Third, a class derived from ValidationRule that the validation extender runs. Choose the home that fits the responsibility of your rule.

ValidateStartEndDates returns an empty string when the dates are valid, or an error message when they are not. Apply that same message to both date pickers. The ContactValidator service has no dependency on controls. It validates the model, so you can test the business logic without the user interface.

MinimumAgeValidationRule derives from ValidationRule. Its OnValidating method returns true or false. Attach the rule to the birth date picker with SetValidationRules. ApplyModelValidation connects service results to the screen. It maps field names to controls, so each message appears where the user can fix the problem.

The Save handler runs validation in order. First, check field rules. Then run the validator service and the date rule. Return early if any layer fails. Call the repository only after every check passes. The database should never receive data that your validation has already rejected.

Now try saving with the start date after the end date. Both pickers show the same error, and the summary displays a single message.

Correct the end date. Both errors clear together. Because this rule compares two values, both controls share the feedback.

Enter a birth date from twenty eleven. The minimum age rule rejects it as soon as the user leaves the picker.

Correct the birth date, and the error clears. Save now runs every validation layer successfully, then stores the contact exactly once.

For lab four, implement the date check, the validator service, the message mapping, and the minimum age rule.

Connect them in a Save handler that never saves invalid data.

Module five. Data-bound validation in Wisej.NET. The intake form now edits a Contact Edit Model. Its basic validation rules belong to the data, so the same rules can protect the form, the grid, and other ways of changing a contact.

A form handler only protects changes made through that form. A grid, an import, or a service can update the same contact without running those handlers. Put the basic rules on the model, then make every save path run them before accepting the data.

First, finish the current edit. The value still being typed may not have reached the model yet. Call End Edit on the contact binding source before validating. Otherwise, the validator could check an older value even though the user has already corrected the field.

Data Annotations describe the rules, but they do not run themselves. Try Validate Object applies them and collects the results. Set validate all properties to true. Without that option, only Required is checked, so a malformed email or an out-of-range age could pass.

The validator returns property names, not controls. Use a field map to connect each result to the correct input. Put the message beside that input and in the summary. If a property has no matching control, keep its message in the summary so the error is still visible.

There is another approach. A model implementing I Data Error Info answers validation questions for each property. A data-bound Error Provider reads those answers. When switching sources at runtime, Bind To Data And Errors sets the source and member together, avoiding a temporary mismatch.

Try saving the invalid contact. End Edit first commits the current input to the model. The annotation checks reject the name, email, and age. The field map puts each message beside its input and in the summary. The save path stops before writing anything.

Correct the values and save again. The checks now pass and the contact is saved. On the I Data Error Info model, clearing the name brings the error icon back through data binding. The form does not need to call Set Error for that change.

For lab five, bind the editor to the model, finish edits before validating, and map annotation results to the fields and summary. Then connect the I Data Error Info model through Bind To Data And Errors. Verify that invalid data never reaches the repository.

The contacts grid introduces a different editing path from the intake form. A cell has its own editor and validation events, so reuse the same business intent through grid handlers rather than expecting the form’s text-field handlers to run.

Separate the three problems before choosing a handler. Email format belongs to the cell, nonnumeric age can fail conversion, and a closed contact without a closing date violates a rule across fields. One check cannot explain all three reliably.

During editing, validate e.FormattedValue because it contains what the user is typing now. The cell’s stored Value still represents the previous committed input. Checking that old value could accept the very mistake the user just introduced.

Use the column name to select the rule in CellValidating. Clear that cell’s previous message, inspect the edited value, and cancel with a clear explanation when it fails. This keeps the user beside the input that needs correction.

Place a single-value error on the cell and a relationship error on the row. Reserve DataError for conversion or saving failures that the grid reports. Skip the new-row placeholder, since it is not yet a contact requiring validation.

ValidateRow updates the row message and the closing-date cell together, making the relationship visible at both levels. In DataError, explain conversion failures in ordinary language and log the exception separately so diagnosis does not become the user’s responsibility.

Try the malformed email first: validation keeps the edit in place and displays the cell error. Then enter letters for age. The friendly conversion message demonstrates a different failure path, even though both mistakes occurred while editing a cell.

The closed contact still cannot save until its required closing date is present. The row error keeps that relationship visible, while the placeholder is ignored. Enter the date and save again to verify that correcting the rule permits persistence.

Build the grid checks around the current edited value, row relationships, and friendly conversion errors. Clear successful cell errors and guard Save against remaining failures. Test each layer separately so a valid cell cannot hide an invalid contact row.

Bring the ValidationClinic checks into a single save path. Field, model, business, and grid validation now have to cooperate in Wisej.NET, so a successful check at one layer never bypasses an unresolved problem at another.

Individually correct validators do not guarantee a correct save. A pending edit may leave the model stale, or a grid error may never reach the form’s checks. Put the stages in a fixed order and require every stage to succeed.

Reset feedback and finish the current edit before checking fields, the model, business rules, and grid rows. Stop at the first failed stage. This sequence prevents later work from running with invalid input and keeps the eventual write behind all checks.

Use the IErrorProvider contract to send messages without tying validation to one display. SummaryErrorProvider retains one message for each control and hides its label when none remain. The summary can therefore reflect the same errors as the field feedback.

Return early when field or model validation fails. If the final save throws, distinguish a duplicate name the user can correct from a system failure they cannot. Route the duplicate to its field and explain other failures calmly.

Review feedback as part of the workflow, not just as error text. Explain the correction near the field and in the summary, preserve Cancel, and keep technical traces out of user messages. Test missing, invalid, valid, and boundary inputs.

First, the missing name and malformed email stop the save during field validation. Correct those fields and try again. The model then rejects age one hundred thirty, showing why passing the field checks does not make later checks optional.

The grid stage catches the remaining email and closed-row problems, and the summary explains both. After those corrections, every stage succeeds and the save completes. The final confirmation now means that the whole validation path passed.

Deliver the complete save path with the summary provider and shared message helper. Include exception handling that distinguishes correctable input from system failures. Document the test cases so another developer can reproduce both blocked saves and successful corrections.