The second point is easy... if you have FileMaker 11 or higher, conditional formatting is a breeze. Just right-click on the field in layout mode, and select 'conditional formatting' (see http://www.filemaker.com/11help/html/edit_layout.10.14.html for more details).
The first point is more complex...
Field validation mostly occurs on record commit (one exception is date format in date fields). If you want to notify users immediately that their entry is liable to fail validation, you may need to use script-triggers to keep a track of what's being typed (this is filemaker 10 and up, see http://help.filemaker.com/app/answers/detail/a_id/7465 ).
The advantage of this is that it's immediate, the disadvantage is that it is tied to a given layout object... if you fail to format all your layouts (or create a new layout and forget to set up the script triggers) then invalid data can be entered.
Therefore, I'd persist with the field-level validation, as the final backstop, but use the script triggers to give users quick feedback before they commit/save the whole record.
In terms of a validation that meets your needs, it would be something like:
if( // always valid (returns '1') if older than this date createDate < date( 12; 25 ; 10) ; 1 ; // now list the other criteria... case( // 1. not negative -- fail (return '0') self < 0 ; 0 ; // 2. can be zero self = 0 ; 1 ; // 3. can be greater then or equal to another field self >= otherField ; 1 ; // default backstop-- fail 0 ) )
Be aware that really complex validations can take a lot of tweaking to make sure that they *always* gets it right, and doesn't block an unusual, but valid, entry or allow an unusual, incorrect, entry. They can also slow down large-scale operations like imports and replace-field-contents, as there's extra work for FM to do.
With FIleMaker 11 and newer, you also have the OnObjectValidation script trigger that you can use. This option can be very nice as it is tripped before any build in validation (even on date fields) and you can use Exit Script [False] to cancel out the user event that tripped the trigger.
Thus, you can start up a script that checks for invalid data, corrects the same, uses show custom dialog to inform the user of their error in a much more flexible fashion than a custom validation message and with options specific to your layout design or some combination of the two.
And you can still have the field option validation in place as JonJ suggests (and I agree with) as an "insurance policy"
And to make clear about your concerns about 1), when you add a new field validation option and/or a script trigger controlled validation, this will not affect existing data unless/until such a record is edited so you may not have to do anything special for your existing records unless you want to disable the validation for the older records.