Some apps are inherently data-entry-intensive. When this happens, giving the user good feedback on errors is essential.
It’s relatively straightforward for code to wait until all the data is entered, then check it systematically. There are several dict -based checking libraries available. This is very effective for reporting inconsistencies between two (or more) inputs. In this case, no individual entry is wrong; it’s the combination that is wrong.
But single-entry errors are also common. Depending on the circumstances:
• A widget’s value may be None , when it should have a definitive value.
◇ Or vice versa!
• An age is never a negative number, and if it’s a human’s age, it’s almost certainly less than 130 years.
• Additional constraints may appear, depending on the situation.
In these cases, it’s much better for everyone if the entry error can be reported on the spot , i.e., just as the user has finalized the entry (pressed Enter or Tab, clicked on another widget, etc.).
It may also be necessary to prevent the user from leaving the widget, until the error is corrected – or at least, until acknowledging that the value is, indeed, incorrect. (Which means intervening, before their click on “OK” or “Close” actually takes effect. And maybe even preventing those effects.)
And in the combinatorial case, it may still be useful to display a warning , when an inconsistent value is entered.
All of these things become possible IF Anvil entry widgets expose an OnValidate event. Unlike the refreshing_data_bindings event, which fires on a per- Form basis, OnValidate would fire per-widget, before leaving the widget, and would not require Data Bindings to work. If both Data Bindings and OnValidate are present, then OnValidate should occur before writeback.
Conceivably, OnValidate might apply to any container widget, as well, including an entire Form . This might be needed, for example, to validate a connected series of Radio Buttons as if they were a single widget.
The event-handler’s return value can be used to determine whether writeback should occur, and whether any pending navigation (e.g., activation of another widget) should proceed.