Problems with Status(CurrentError)

[Cousin Jack]

Happy New Year everyone. Thanks for having a look at this one for me.

I am having problems getting Status(CurrentError)to work properly (at all)in a wizard I have written for record creation. Having looked at various examples on the forums I still can't see what I may be doing wrong.

1. I have the Troi ClipSave plug-in enabled (in case this is relevant)- it probably isn't.

2. Policy Number is required to be Not Empty, Unique, Numeric Only.

This is my script:

Set error capture (on)

Go to Layout ...........

Show Custom Dialogue (buttons: 1 "Create" 2 "No Thanks")

If [status(CurrentMessageChoice)=2]

Show all Records

Exit Script

Else

New Record/Request

End If

Loop

Go to field ("PolicyNumber")

Enter Browse Mode (Pause)

If("IsEmpty(PolicyNumber)")

Show custom Dialogue............button 1 "Try Again" button 2 "No Thanks"

........The above "If" works well, and returns the loop as required..........

End If

The following step is my problem - (it does not work when the validation criteria for being unique is not met)Indeed, I have put a field on the layout to show the current eror number, and this never alters from "0"

(I have checked the validation criteria numerous times (and have also checked that the field I am entering into is the right one!))

If(Status(CurrentError) = 504

Show custom dialogue "Error Policy Number is not unique etc etc... button 1 "Try Again" button 2 "No Thanks"

End If

If(Status(CurrentMessageChoice)=2)

Delete record/Request (No Dialogue)

Show all Records

Exit Script

Else

Exit Loop If("not IsEmpty(PolicyNumber)and Status(CurrentError)<>0")

End If

End Loop

If("not IsEmpty(PolicyNumber) and Status(CurrentError)=0")

Set Error Capture (Off)

Perform Script ......... next one in the wizard

Exit Script

End If

If I have a non unique number in the policy number field I am sent on an unending Loop.

Manyb thanks for looking at this for me

CJ.

[Cousin Jack]

Very Sorry, I mistyped my question. The end of my script should have been typed with a "not" in front of the Status(CurrentError)<>0" on the 8th from last line:(Status(CurrentError)=0) would have been better, but neither work.

The correct version is as follows.............

Exit Loop If("not IsEmpty(PolicyNumber)and notStatus(CurrentError)<>0")

End If

End Loop

If("not IsEmpty(PolicyNumber) and Status(CurrentError)=0")

Set Error Capture (Off)

Perform Script ......... next one in the wizard

Exit Script

End If

[Vaughan]

Jack

The CurrentError value is reset after each script step is processed, so if you had a script...

stuff

<step to check the error on>

End Loop

If (Status(CurrentError) > 0)

more stuff

... then the If statement will be holding the CurrentError generated by the End Loop step.

The solution is to put the CurrentError value into a global field immediately it is generated, then check the global field at your leisure. You also need the Set Error Capture [on]

step to prevent FMP from handling the error itself.

stuff

Set Error Capture [on]

<step to check the error on>

Set Field [gError = Status(CurrentError)]

Set Error Capture [off]

End Loop

If (gError) > 0)

more stuff

[CobaltSky]

Hi Jack,

Vaughan has identified one of the issues here, but there are several others.

As Vaughan says, the sequence:

End Loop

If("not IsEmpty(PolicyNumber) and Status(CurrentError)=0")

- will always evaluate the If[ ] step with an error of zero because the error always relates to the preceding script step which in this instance is 'End Loop' - and End loop never fails and thus always returns an error of zero. By the time the If[ ] step is evaluated, the current error will therefore always be zero. Vaughan has suggested a way of dealing with this - and what he's said is correct as far as it goes.

However the plot thickens. I note that you have not actually told us what action it is that you are trying to capture the error from. By implication, though, (since you are trapping for error 504) you are trying to confirm that the value in a field is valid - but the success or otherwise of this test (as with all other field validation error traps) depends very much on how the value has been placed into the field, as well as where the error trap is placed.

For instance, the following will fail:

[color:"red"]...Set Error Capture [On]

Set Field ["YourField", "{any invalid value here}"]

Set Field ["gCurrentError", "Status(CurrentError"]

Exit Record/Request

End Loop

If ["gCurrentError = 504"]

etc...

- and will always place a zero in the gCurrentError field, because the Set Field script step is designed to always ignore field validation options. Since the Set Field step will not fail, no error is generated and the gCurrentError field is set to zero (quite correctly), causing to subsequent If[ ] evaluation to return negative even though the value may not have met the 504 test criteria.

Similarly, I'm afraid the following will also fail:

[color:"red"]...Set Error Capture [On]

Insert Calculated Result ["YourField", "{any invalid value here}"]

Set Field ["gCurrentError", "Status(CurrentError"]

Exit Record/Request

End Loop

If ["gCurrentError = 504"]

etc...

- This one will always place a zero in the gCurrentError field, because although the Insert Calculated Result step step does not bypass field validation options, the validation tests are not evaluated until the field is exited, and the Insert Calculated Result[ ] step leaves the cursor in the field, so any validation check will not take place (and the related error will not be returned) until such time as the field (or record) is exited.

On the other hand, the following *will* work, as far as it goes, but is still problematic:

[color:"purple"]...Set Error Capture [On]

Insert Calculated Result ["YourField", "{any invalid value here}"]

Exit Record/Request

Set Field ["gCurrentError", "Status(CurrentError"]

End Loop

If ["gCurrentError = 504"]

etc...

Since the field validation error occurs at the commit point (when the record is being exited in this case), the Exit Record/Request step fails, leaving the cursor and the invalid value in the field and returning a validation error (eg 504 if the value was not unique and the field's validation configuration was checking for 'uniqueness'). This time, the value placed into gCurrentError will be 504 and the subsequent If[ ] step will evaluate as true. So far so good...

The problem here is that the invalid value has been left in the field, so any and all subsequent actions (scripted or otherwise) which may involve exiting the record or the field will fail because the validation check will again intercede.

To work around this, it is necessary to explicitly check for all possible validation-related errors (errors 500-509 and 511, depending on the validation configuration of the field in question) and if any applicable validation errors are returned, immediately clear the field before proceeding. Thus if the 'unique' validation is the only requirement placed on the field, the following error trapping sequence would be more workable:

[color:"green"]...Set Error Capture [On]

Insert Calculated Result ["YourField", "{any invalid value here}"]

Exit Record/Request

Set Field ["gCurrentError", "Status(CurrentError"]

End Loop

If ["gCurrentError = 504"]

Set Field ["YourField", " "" "]

etc...

Even so, an issue remains - which is that the error trap is outside the loop - so if the loop cycles several times, only the last value will be evaluated by the error trap. Whether or not this is an issue depends on what else is in the script, but if it is, then the error trapping should be moved inside the End Loop so that it occurs on every pass of the loop.

Because of the various additional pitfalls I've referred to above, field validation errors traps are among the more exacting to work with - especially in loops. Hopefully I've given you enough of a 'roadmap' for you to be able to plot a suitable path from here.

[Cousin Jack]

Thank you to both of my Australian friends.

Your combined advice appears to be working well. I have increased the number of sub-scripts in order to reduce the number and degree of complexity of the Loops. This is now working extremely well where I am isolating one error at a time.

I Haven't got to the part of the script that will require the isolation of more than one error at the same time. I presume that the global g_CurrentError field will accept more than one input from the script step Set Field[g_CurrentError, "Status(CurrentError)"] in the same way as a global field can retain info from numerous fields when holding a found set.

I am using Set Field ("g-currentError", " " ) each time I leave a part of the script that has made use of it so that the field is empty ready for the next time.

Thanks again, and I wish you "good morning" as I turn in for the night here in not-so-sunny Cornwall.

Regards

CJ