It’s the tried and trusted way to get the users attention. At the slighting hint of an issue with their data entry you put up a big dialog box complete with warning icons and meaningful information.
We’ve all done it, and many programs we write today may still do it. Writing code using the Synergy UI Toolkit its common practice to write a change method to perform field level validation. When the user has changed the data and left the field – either by tabbing to the next or clicking the “save my soul” button – the change method executes and validates the entry. It is here were we stop the user in their tracks. How dare they give us invalid data – don’t they know what they should have entered? It’s an ever so regimented approach. The user must acknowledge their mistake by politely pressing the “OK” button before we allow them to continue. Users are usually not OK with this interruption to their daily schedule so there must be a nicer way to say “hey there, this data is not quite as I need it, fancy taking a look before we try to commit it to the database and get firm with you and tell you how bad you are doing at data entry?”
When migrating to a new Windows Presentation Foundation UI we can do things a little different and guide the user through the process of entering the correct data we need to complete a form or window. We will still use the same change method validation logic however as there is no reason to change what we know works.
When using the Symphony Framework you create Symphony Data Objects – these classes represent your repository based data structures. The fields within your structures are exposed as properties that the UI will data-bind to. These data objects are a little bit cleverer that just a collection of properties. Based on the attributes in the repository it knows what fields have change methods associated with them. Because of this the data object can raise an event that we can listen for – an event that says “this field needs validation by means of this named change method”. Here is a snippet of code registering the event handler:
The event handler simply raises the required “change method” event back to the host DBL program;
Back in the DBL program we can now listen for the change method events. Here is the event handler being registered:
Remember, we are now back in the host DBL code so we can now dispatch to the actual change methods registered against the field. This is a code snippet and not the complete event handler code:
We are calling into the original change method and passing through the required structure data and method data. Inside the change method we will have code that validate the entry and then, as this snippet shows, we can perform the error reporting:
If the code is running as a UI Toolkit program the normal message box dialog is used to display the message. However, when running with the new WPF UI the code provides the required error information against the field. No message boxes are displayed. To the user they will see:
The edit control background is coloured to indicate an issue with the data and the tooltip gives full details of the problem. When the user has entered valid data, the field reverts back to the standard renditions:
We shall be exploring the ability to handle field change method processing during the DevPartner 2016 pre-conference workshop as we all migrate an existing UI Toolkit program to a modern WPF user interface.