Bug when using formula in events?

HCL Domino Domino Forum
1

I have run into this problem a couple times, and I’m not sure if this is a bug or not.

It appears that when using formula and @commands in events such as QueryClose, QuerySave, etc, only the first @command is executed… all the rest are ignored. For example, I have two @statements in the following code:

FIELD PrevSev := PrevSev;

FIELD Sev := Sev;

@If(PrevSev != Sev;@MailSend;@Success);

@If(PrevSev != Sev;@SetField(“PrevSev”;Sev);@Success);

Whenever PrevSev != Sev, the @mailsend gets executed but PrevSev doesn’t get set to the value of Sev.

I also saw this when a co worker was coding a querysave and she wanted to use a whole bunch of @If’s. The first @If got executed but all the rest of them were completely ignored.

I’m on 6.5… anyone got any suggestions?

2

Subject: Bug when using formula in events?

I don’t know if this is a problem, but …

@Success should only be used in a validation formula. It is not intended for use anywhere else.

You should replace you @Success with an empty string (“”) regardless of whether this fixes your specific problem.

3

Subject: RE: Bug when using formula in events?

Also (and this also doesn’t address the specific problem), you can just use the @do function to avoid the need for multiple @ifs:

FIELD PrevSev := PrevSev;

REM “The next line is not needed in either R5 or R6 since”;

REM “you are not using @setfield to set Sev”;

REM “FIELD Sev := Sev”;

@If(PrevSev != Sev; @Do(@MailSend; @SetField(“PrevSev”;Sev)); “”);

Finally, if only R6 clients will be access the app, then you can use FIELD in place of @SetField:

@If(PrevSev != Sev; @Do(@MailSend; FIELD PrevSev := Sev); “”);

4

Subject: Bug when using formula in events?

Take a look in the R6 Designer help under Index then “Run-time errors”, then formula language. It describes the different types of errors and how to trap them. See the copy below from the help.

HTH,

Run-time errors occur when the formula runs. These errors can be categorized as follows:

Unexpected – These are development errors that your users should never see. For example, if you forget an @function parameter, the following message appears at run-time: “Insufficient arguments for @function.” You should test your formula and attempt to correct all unexpected errors.

Unreported – These are results that are incorrect but are not reported as errors. For example, if you try to display a numeric value with @Prompt, @Prompt works but displays a blank. Again, your user should never see these errors. You should test your formula and ensure that all results are as expected.

Expected – These are errors that the user might cause at run-time. For example, if you prompt for the name of a database, the user might enter the name of a nonexistent database. You cannot prevent these errors, but you can anticipate and test for them in the formula and take appropriate actions.

The following @functions help you deal with run-time errors:

@IsError(value) returns True (1) if a field, temporary variable, or expression contains an error.

@IfError(statement1; statement2) returns the value of the first statement if no error occurs, or the value of the second statement, or a null string (“”), if an error occurs in the first statement.

@Error generates an error.

@Failure(message) displays a message when used in an input validation formula.

@Success always returns the value 1.

@Return(value) stops execution of the formula and returns a value.

Notes generates an error for a field if the built-in validation checking fails. For example, if you specify a field as numeric and the user enters a non-numeric value, Lotus Domino makes the value of the field an error. You can generate an error for a field by setting its value to @Error.

Notes reports errors in fields when the user attempts to save the document. For example, if a numeric field contains a non-numeric value, Lotus Domino generates the message “Cannot convert text to a number” when the user attempts to save a document.

To change the message or perform another action when an error occurs, do one of the following:

Test the field for an error with @IsError in the field validation formula. You can generate your own error message with @Failure, but only in field validation formulas.

Test the return value of a statement with @IfError.

To incorporate your own error conditions for a field, return @Error if you detect an error condition.

Outside field formulas, for example, in an agent, button, or hotspot, you can check the contents of a field and react immediately to an error condition. For example, if you check a field with a button, you can change the field value or report the error before the user attempts to save the document. In checking for errors, be aware that the built-in validation checking generates an error as soon as the user enters a value in a field, but that a translation formula using @Error does not generate an error until the user attempts to save the document.