Each row already has a Show event, which can be used to establish initial conditions.
For timely sanity-checking a row’s data constraints, however, you need to know when a user is done with the row as a whole, i.e., when they’ve attempted to tab or click to a location not in that row.
It’s important to let a user know when they’ve goofed as early as possible, and as close to their error as possible, so that they have the best chance to learn from it, and avoid it in the future.
So if the constraint says that Column_A must be less than Column_G, it must be after they’ve had a chance to enter values in both columns (in any order), but before they move on to another row.
This is most effectively and simply done if there is an on-end-row event for us to use. The event-handler’s return value would be used to determine if the expressed navigation succeeds.
If the return value is None, then all is well, and the tabbed-to (or clicked-on) widget activates.
If the return value is True, then all is not well, and the target widget does not activate.
Otherwise, the return value should indicate which in-row widget should be activated instead. That is, we take the user straight to the widget where they can correct the problem. (Use this option when there is clearly just one widget that will do the job.)
Even in the absence of sanity-checking, such an event could also be used simply to save the entered values, perhaps in their final format, which might be very different from the visually-oriented format required for data entry, or do other end-of-row processing.