Here is some specific code related to ThrowFocus, NotifyForm and FormExit issues I am fighting.
This is the code in a subform FormExit:

//Checks that mandatory fields are filled in
IF @ISBLANK(Start)
 	  OR @ISBLANK(End)
 	  OR @ISBLANK(OriginalDate)
	OR @ISBLANK(ParentRecord)
	THEN	{
//		NOTIFYFORM(1)
		@PLAY("BEEP")
		@MSG("All Records need the Start and End dates and Original Date fields filled in before you can save the record.")
		If @ISBLANK(Start) THEN { THROWFOCUS(Start) }
		If @ISBLANK(End) THEN { THROWFOCUS(Start) }
		If @ISBLANK(OriginalDate) THEN { THROWFOCUS(Start) }
		If @ISBLANK(ParentRecord) THEN { THROWFOCUS(Start) }
	}  ELSE {
		@Msg("")
//		NOTIFYFORM(0)
	   }
 

I commented out the NotifyForm() lines based on recent info that only Notifyform(4) would work in a subform.

How do I stop new records from being added?
If I keep hitting the down arrow on a "blank" record I just keep getting new records added. 
The new records are not blank because FormOnEnter does the following functions (left out the code):

	Sets Visibility and ReadOnly states on multiple LEs
	Prevents moving onto a blank record if @New (not working either, aparently)
	Fills in User/Date/Time stamps in LEs.
	Fills in ParentRecord ID if blank. 

So how can I stop subform tableview records from being added if mandatory elements are not filled in?
ThrowFocus is not working on blank records, it is like none of this code exists.

Since subrecords are not committed until the parent is committed, I would be tempted to use the main form as much as possible to populate (with unbound LEs and programming) and check the subforms. If a value is populated via programming (like ParentRecord), it should not be used to interfere with control flow (ie: advancing). If its value is not good, use programming to make it good. In addition, if possible, make the LE read only - so user input cannot interfere with the intent of the program.

Quote:


Probably not the case, if you use the main form with unbound elements for the data entry. You can use the table for data entry (though I wouldn't) and validate as you go. But that probably won't please the data entry pros.

Quote:


Use variables and "state programming" and you should not ever have that condition. Don't trigger until you know you have a valid data state.

Quote:


You can. You can, if you wish, validate every letter as it is entered, You can run programming on enter and exit for each LE and line in the table. If you find a problem you can warn the user. And, because the subrecords are not "saved" until the parent is saved, you can prevent "bad" data from being entered into your application.

Control the data, not the user. Inform and guide the user. But, assume in all of your programming that the data will be wrong. Assume that it will be entered incompletely. Assume that it will be entered in an unexpected order.

Quote:


I would still recommend that you consider using the parent and normal (as opposed to "tabled") LEs for data entry. If this is a data entry intensive application, I would recommend using a form based subform - they are much easier on data entry. Possibly build a duplicate main form with a table view subform for management summary.

You can check your data as the user enters it in the table view subform, and warn the user appropriately. It will be substantially more difficult to trap the user where they are until they get it right. But since the subrecords are not saved until the parent is saved, and you can prevent the parent from being saved, you shouldn't need to trap the user to get the data right.

Quote:


What you should do depends heavily on the requirements put on you, the experience level of the data entry people (and their temperament), the length of time any one user will use the application, and the amount of time you wish to spend on the project.

If, for example, you are building an app that will be used by a user once and they are unlikely to build up experience using the app (like a kiosk), you will probably want to use a "wizard-like" approach, were the user is asked to answer only a single question at a time, in order, with static on screen instructions. But, if you are building something that will be used multiply by the same user, they will build up experience, and a linear interface will only hinder them in the long run, and the instructions will be eating space they could profitably use.

If you have fields that must be filled in by the user (as opposed to programming), and they must be correct, check them at every opportunity and set flags indicating their status. Use the "form" routines (like @formfieldvalue) rigorously and set static globals as needed. Remember that "nothing counts", nor needs to be correct, until the user advances the main record, at which point the brakes should be (and can be) rightfully applied. If fields can have only limited values, offer those values as obvious choices. Use variables and unbound LEs as much as possible to prevent access to critical and bound LEs, and to create a data filter between the user and the critical LE.

If there are sets and combinations that are critical in relation to one another, include in that set a "Completed" LE to indicate that that set of data is incomplete and must be completed, or possibly ignored (with sufficient warning). Incomplete and revalidate anytime the user approaches that set of LEs.

Quote: