Field-Level Validation Script Conflict

[LaRetta]

I rarely use field-level validation but need to on my checks data-entry screen. User enters Amount (2-decimal number) which is the check amount. Validation on AmountTotal is:

not Mod ( AmountTotal * 100 ; 1 ) and

Filter ( AmountTotal ; ".1234567890" ) = AmountTotal or

IsEmpty ( CheckNumber )

Validation is set to Validate Only During Data Entry and Validate Only if Field has been Modified is unchecked. As soon as an amount is entered, it creates a relationship to all outstanding invoices with similarities and they appear in a portal. Portal has PAY button which fires script to apply all (or part) of check to an invoice. Problem is - if user has entered more than 2 decimal places (indicating misentry) then immediately clicks the PAY button, the validation fires but the script still runs. I begin the PAY script with Commit Records/Requests but I can't figure out what to do to STOP the script if there is validation failure so the User can correct the entry. The PAY script uses that amount and continues to apply that incorrect amount to the invoice. It seems like I have to AGAIN validate within my script (or another script first) and I shouldn't have to. Any ideas? I'd sure appreciate it.

If anyone wonders why I don't use the Strict Data Type Numeric instead of the Filter() portion, it's because two validations causes the validation message to fire twice and I would rather handle it all within ONE validation so I use 'by Calculation.' And if there are better ways to write the validation calc or handle this at field level I'd welcome that as well. But I need to stop that script. I can't validate within the PAY script (instead of field-level) because the User may NOT apply a check right then but they still need to enter it so it can be processed and checks are NEVER half cents.

LaRetta

[IdealData]

Are you sure the validation is correct?

Shouldn't IsEmpty( CheckNumber ) be not IsEmpty(CheckNumber)

Could I also recommend some more braces to expressly force the precedence of operators. AND, OR and NOT have precedence in that sequence.

Don't forget you can trap for errors in your script with SetErrorCapture [On]

I suppose it's a bit of a 6 and two 3's option for FileMaker whether it should continue the script after field validation - but that's what the error trapping is for.

[LaRetta]

Hi Mark,

Thank you for helping.

This Validation is correct and has worked for over a year except an Amount of 368.44368.44 slid through last week (so User found a way around) which is why I want to fix the break - system says that check was never used up (at zero) after all checks were applied. This screen creates new blank record when check is used up (one check may apply to many invoices) so they can immediately start entering another check (without having to click an Add button in between - management insistence). If User decides not to create another check, it deletes it when the User changes layouts (indicating they are done entering checks) and it is event triggered. I must have that OR test for blank on check number so I can handle the deletion when they leave. Check number validation is separate and a blank check number means the record isn't to be saved.

Debugger pinpoints the problem - when User says OK to validation message, the script continues. The calc may not be optimum but it is firing correctly.

Could I also recommend some more braces to expressly force the precedence of operators. AND, OR and NOT have precedence in that sequence.

I have no idea what this means - can you elaborate? My understanding is that it is proper logic which controls Operators and sequence does not matter if the logic is correct. Sequence matters in efficiency, ie, short-circuiting and branch prediction but I don't know what you mean by braces and expressly forcing precedence. I've never had a problem using Operators before!

I have error trap on at the beginning of my script. But the error capture traps the next upcoming error. I'm unsure how that will help me on something which happens before the script starts; which is why I mentioned a second script (or splitting this script). Correction: I said I have error capture at the beginning but I don't! It is the second line with Commit as the first! Maybe if I reverse them, I can trap the validation failure. Since I rarely use field-level validation, I've never trapped for it failing.

I will try reversing them and using 507 Value in field failed calculation test of validation entry option. Thanks for the idea!

Heck, maybe I'll just change to a global and handle it all within the script. That's what I usually do. But understanding this failure will be important. I even made sure that the Commit was NOT checked 'Skip data entry validation'. I must pinpoint my logic break here when using scripts with field-level validation or this can bite me in the future.

LaRetta

Edited October 1, 2006 by Guest
Added heck

[LaRetta]

Update: Moving Error Capture to first line (above Commit) and testing for 507 (immediately after) worked. I halt script within the If() test if I get failure.

So ... if I use field-level validation, I must always TEST for validation failure in ALL MY SCRIPTS which may be activited on same layout by beginning with:

Set Error Capture [ On ]

Commit Records/Requests [ ]

If [ Get ( LastError ) = 507 ]

Show Custom Dialog [ ""Check amount entered is INVALID. Say OK and correct it." ]

Go To Field [ AmountTotal ]

Halt Script

End If

It makes little sense to me ... if User is getting field-level validation failure, they can't even close FM until it is fixed but they can RUN A SCRIPT!?? Field-level validation shouldn't let ANYTHING else happen until it is fixed - at least that's my thoughts on it.

I think it will be easier to ditch field-level validation entirely rather than modify every script. Am I the only one that struggles with this issue?

LaRetta

Edited October 1, 2006 by Guest
Corrected If[] line ...

[Genx]

Nope, i had a validation system in place, and then ran a script about 4 months later to see the results, 1/4 of the records had somehow slipped through where there was validation attached to the field and an invalid value was entered... I ended up changing to a different method, plus its all so unsightly and annoying

[comment]

I have played with this shortly, and you're right, at least partly. It might be a stretch to call this a bug, but Filemaker certainly does not play nice here. I have managed to get a validation error thrown up, but if user chooses "No" in response to "Allow this value?", the script continues (and the record remains uncommitted).

However:

If the record must be committed implicitly (e.g. the script needs to leave the layout), then the validation fires again. This time, if the user chooses "No", the script responds with "Go to Layout has been cancelled. Do you wish to continue with this script?". Not much of an improvement, since if the user says "Continue", the script continues in the same layout, and ends up doing more harm (such as setting the wrong fields).

It seems that error-detection is the best way to handle this (interestingly, it works even without turning error capture on).

[LaRetta]

but if user chooses "No" in response to "Allow this value?", the script continues (and the record remains uncommitted).

I have unchecked Allow User Override so this option isn't availalbe but, after saying OK to fixing the validation error (and with the script continuing), when User is returned to the layout, I NO LONGER get validation error on the field!! Nada clicking in and out. I suppose that's because FileMaker no longer considers the record as still being under the 'only during data entry' mode. This scares me as well. I could turn on 'Validate Always' but that's a Band Aide and I think I'll ditch all field-level validation until I test it thoroughly and can predict its behavior. Thank you! :wink2:

[IdealData]

By using the extra braces you will improve readability and you can also expressly force the evaluation of lower precedence operators before higher ones. viz

(100 + 2) * 100 = 10200

100 + 2 * 100 = 300

the last line can be written

100 + (2 * 100) = 200

more readable?

Glad you spotted the Error Capture bit. Don't forget you can also turn error capture off as well, thereby making the rest of the script subject to field validation.

[IdealData]

FWIW I tried using field validation years ago but gave up on it, instead preferring to use scripted validation.

[LaRetta]

(100 + 2) * 100 = 10200

100 + 2 * 100 = 300

the last line can be written

100 + (2 * 100) = 200

Your last line is incorrect. 100 + (2 * 100) is EXACTLY the same as 100 + 2 * 100 but it equals 300, no matter how you write it. I write it as 100 + 2 * 100. Why? Because it is a basic math rule, multiplication and division comes before addition and subtraction and I don't need parenth to tell me that. Unnecessary parenth just muddies the water and makes a calc HARDER to read.

expressly force the evaluation of lower precedence operators before higher ones.

Are you suggesting you wrap parenth around AND, OR and NOT as well? Unless you can provide example of 'forcing lower precedence operators before higher ones' using AND, OR or NOT then I respectfully disagree with your premise. My validation was text; your example is straight math ... neither need expressly forced, in my opinion.

AND, OR and NOT have precedence in that sequence.

NOT

LaRetta