Best, depends on who you ask. This can be done thru validation. In my DB, for a new customer there's a few critical pieces of info that have to land on the first layout, so I use script triggers to immediately check, pop up a message, send user back to field. Others take an approach like a web page where you cant leave and a message pops up saying something like "the field marked with an * must be filled in"
Look at your auto enter tab and validation tab in field options. You can also use a combination of validation and script triggers. For example here's what's in an auto enter calc for phone number:
@Numbers = TextFormatRemove (Filter( Self ; "0123456789" )) ;
Length(@Numbers) = 10 ;
Left(@Numbers ; 3) & "-" &
Middle (@Numbers; 4 ; 3) & "-" &
Right ( @Numbers; 4 ) ;
TextColor (Self ; RGB (255 ; 0 ; 0 ) )
If the phone number is not 10 digits, turns text red, if it is 10 digits, formats phone number And here's whats in the OnObjectExit script trigger
Set Variable [$Phone; Value: Get(ActiveFieldTableName) & "::" & Get(ActiveFieldName)]
If [not (isEmpty(GetField($Phone)))]
If [Let (@numbers=Filter(GetField($Phone); "0123456789"); Length (@numbers <> 10)]
Show Custom Dialog
Exit Script [False]
You could take out the first test. I leave it in incase I type into a wrong phone number field, it lets me delete it. But if you take it out, in this case, the user has to put the proper value in the field, or it turns red and wont let you leave it. Keep in mind this could really be a problem and get you stuck with no where to go. The one major critique of a script with Exit Script [False] is that you need an Exit Script [True] or you could have a problem.
Hope this helps a little
Field validation field options apply to the field no matter what layouts are set up to access and edit the data. Script triggers are specific to a given layout. Script triggers enable you to handle validation more immediately and in a much more user friendly fashion.
For critical validation requirements, I tend to set up both. The field option then is my "insurance policy" that my system will trap for such a user error even if the user figures out a way to edit this data without tripping the script trigger due to some design omission on my part.