I'd like to make a field required on a subform.  I've tried two methods:

1) Set the Restriction on the field to !.  This works sometimes, but it can be bypassed.  For example, it works when you try to navigate to different sub-record, but it fails to be enforced when you save the main form.

2) Programatically check the field in the subform's Form Exit event (code example below).  This leads to an infinite loop within Sesame that can I can only kill via the Windows Task Manager.

NotifyForm(1)

If @IsBlank( txtField ) Then
	@Msgbox( "The field must be populated.", "", "" )
Else
	NotifyForm(-1) 

So where should subform validation occur?

EDIT: Maybe this question belongs on another thread, but related to the above, I'd like to use the FormDependentValue to recalculate my subrecord totals automatically.  However, that function appears to force a commit of the current subrecord, which I don't want to have happen if validation fails.  I'd like to add automatic re-totaling, but when I tried to add it by looping through the subrecord result set on the parent form's Change event, I couldn't add new sub-records programatically (as the loop would eliminate the uncommitted subrecord which I programatically created using @FormNewRecord).

Hammer wrote on Oct 24^th, 2007 at 1:19am:

I'll keep an eye out for it.  In the meantime, my workaround was to check to see if the subset was currently in an Add state (which I could only do by seeing if the current position was greater than the record count).

Will 2.0.4 also address the validation issue?

Hammer wrote on Oct 24^th, 2007 at 11:56am:


1) Where would I put the single level validation to avoid the infinite loop problem that happens when I put it in the subform's Exit event?  (To be clear, this loop can happen for example when I try to navigate away from the invalid subform using the "Previous" (i.e. <) navigation button.)

2) What I'd like to avoid is duplicating my validation logic, which appears to be what you're suggesting via the implementation of CheckSub()

Hammer wrote on Oct 24^th, 2007 at 12:47pm:

Moving to the previous sub.
No.
Form view.

To re-create the issue in 2.0.3, I took the subform application from the Tutorial (which doesn't have any code) and added the following code to the Form Exit event of the LineItems form:

NotifyForm(1)

If @IsBlank( Qty ) Then
	@Msgbox( "The Quantity field must be populated.", "", "" )
Else
	NotifyForm(-1) 

Now, when I go to Add data to the Invoice form, start doing data entry in the Subform, then press Previous, the infinite loop occurs.  I can also trigger the loop by simply clicking "Exit Add Data" from the tree menu.  (Oddly enough, if I leave the app for a period of minutes and then come back and click OK on the Msgbox, the loop stops.  But otherwise, I've found no way to exit the loop without killing the process.)

Subform validation continues to give me fits.  Beyond what I've previously reported, here are some of the new gotchas I found today:

1) When I'm trying to validate the fields in a subform from a procedure in the parent form, I can't easily figure out if I should perform the validation in the first place.  The issue is that Sesame creates an uncommitted subform record that is accessible via FormFieldValue.  One should only bother to validate this form if there has been at least one edit to it.  With no edits, Sesame dumps the uncommitted record (as it should) when one changes the parent record.  So how do you determine from the subform if the parent form has been edited?  Well, you can determine if you are dealing with a new, uncommitted record by seeing if FormResultSetCurrentPosition is greater than FormResultSetTotal.  Then, the only thing I could think to do is to check the @LEN of all of the subforms fields.  I couldn't figure out how to do this using the metadata related Element commands, as those don't seem to be able to access the subform elements.  This is an ugly way to check if validation is necessary, but at least it works.

2) Restriction checks do not occur when using methods such as FormResultSetCurrentPosition.  This presents problems for the navigation buttons I created for the subform.  So while the restrictions are enforced by the Sesame provided navigation buttons, they are bypassed by my navigation buttons (thus causing me to manually implement validation on each navigation button).  However, since restriction checks are the only form of subform validation available when navigating with the Sesame provided navigation, one is then forced to have two separate (and thus confusing) methods of reporting validation errors to the user.

3) If a Restriction check fails for the current record while checking the value of a field in another record in the result set using FormFieldValue, the edit to the invalid field in the current record is simply discarded and the current record reverts to the original value.  Where this causes me a headache is in my automatic re-totaling of the subrecords.  I put this re-totaling in the On Form Change event of the parent form.  However, as this is called even when there are edits to the subform, invalid edits simply automatically unwind when the focus changes.  This is not an evil problem, but it is another confusing UI issue for end users.  Now in my app, bad edits may either trigger the generic Sesame Restriction dialog, a custom dialog, or simply automatically be undone.

Hammer wrote on Nov 14^th, 2007 at 3:34am:

Although I implied it, I should have been more specific and said @FormFieldValue instead of FormFieldValue.  With a Get operation, it's clear that restriction checks should not come into play.  However, they do.  If you mark a field as required (!), delete the value in the field, and then have code that runs @FormFieldValue on a record that's not the current record in the subform, the delete will be undone and the original value will re-appear in the field.  I can live with the issue, but it's not proper.

Once 2.0.4 is released, I'll review the validate logic and report back my findings on this thread.

I think it was raised a few weeks ago that OnFormExit code does not work with buttons that advance records and you must put that code into Global Options as a SubRoutine?

MP wrote on Nov 14^th, 2007 at 5:56pm:

I think you will be able to do so. Several of the changes in 2.0.4 were shaken out as a result of my needing to implement unusually rigid subrecord validation for a client in combination with needing to handle both automated and manual navigation and my app is working fine under 2.0.4 without restrictions.