We'd done some development work which required us to move a small part of an existing form onto a subform, which, with some new subforms, would then be selectively included back into the original form depending on some field values. Nothing difficult, it got done, and it all worked and tested just fine.

"Illegal Parenthesised Reference"

But as part of the deployment, we did a Tools-Recompile all LotusScript, and we got script errors against the subform. But we'd been able to save the subform as we went along, and we didn't think we'd changed anything anywhere else that would cause the problem. The error given was "Illegal Parenthesised Reference", but on the subform was no LotusScript of any relevance -- no function or sub calls which is usually where this one comes from, and no Use statement to load Script libraries for compile, nothing.

We quickly found that if we selected the subform in error and opened it from the Tools-Recompile error list, the subform opened and took us to a Computed field. Now there's no LotusScript in a computed field, just a value clause, which is Formula only (and which actually specified the field's own name, so no errors there). The field had was a computed field on the original form, too. We tried adding and removing a space from the field value, and saved the subform. It saved just fine with no errors. But Tools-Recompile still failed, with the same syntax error.

You can probably start to imagine our frustration and bewilderment at this problem. We went over the design of the subform, and looked at everything in it: fields, hide-whens, every event. Nothing.

Every time we made a change to the subform it saved just fine, but the Tools-Recompile came up with the same error, "Illegal Parenthesised Reference". The application worked exactly as expected and exactly as all our development test cases showed that it should, but part of QA acceptance into the test team environment is a Tools-Recompile, and with a failure there, we could not get it into test.

We went back to a previous version with Ciao and Delta, and checked that the field had not changed. It had not. We copied it again. Same result. We recreated the subform again by copying all the pieces again. Same result.

Hmmm.

You know what it was? We finally found it by exploring a Teamstudio Analyser run of the design, which showed up the culprit. The field in question had some Field Exiting event code, which called a sub that is located in a Script Library. Now this is for a computed field, mind, so what the &*?!%?. The original form did have a Use statement for the relevant library, but the new Subform didn't, because it wasn't supposed to need it; after all, all the fields on it were computed, and so have no LotusScript code. The original fields we'd copied to the subform from the original form were also computed, and they also had the "hidden" field exiting code.