So we set the field back to Editable, and lo! the code appeared in the Field Exiting event. We cleared it out, set the field back to Computed, saved the subform, and the Tools-Recompile then worked without error.

I had to do a little more exploration after that. When you change a field or some other object on a form, and that means that there maybe something that will get lost -- code or attributes that now don't mean anything -- Designer gives the dialog box shown in Figure A.

FIGURE A

Domino Designer explains that code is about to be lost.

And when you hit Yes, Designer saves the object.

But it actually doesn't remove the now useless and unavailable code -- or at least, when you change a field from Editable to Computed it doesn't remove Field Exiting code -- it leaves it there waiting to catch you out later.

Now, the Notes client runtime will never execute such orphan code, but Tools-Recompile isn't quite so clever. It tries to compile it, and because there was no Use statement to close the reference made in the Exiting code, could not do so, with the results that started all of this off. And thankfully for us, Teamstudio's Analyser also isn't clever enough to ignore such orphan code -- or maybe it's cleverer than we think, and it intentionally shows it.

This all happened using Domino Designer 6.5.4, because sadly that's what we are still using for this particular project. But I also checked the situation with Designer 8.0. That, too, leaves Field Exiting code in place when changing a field to Computed -- indeed the screenshot of the dialog box shown above is taken from Designer 8.0.

I guess this behaviour of Designer is a bit double-edged. On the face of it, deleting code elements that aren't relevant any more is something that you get the impression it is going to do when you get the "Existing action data will be lost" message. But all that seems to happen is that it just becomes unreachable in execution.

Does mean that if you change your mind, it all comes back again, though even that could be a surprise and an embarrassment if you don't know to go and look for it, just in case? I rather think that Designer should actually remove such items, and also that Tools-Recompile should be clever enough not to compile code that is unreachable in execution -- and in this case it must be easy for it to tell, after all, it's a computed field.

I'm not trying to plug Teamstudio's products here, either, but I can't help mentioning that without them we'd have found solving this a lot harder. We looked at Analyser because it often makes scanning design elements easier than Designer does, and if we'd not done so we'd have probably have struggled on quite a lot longer with this one.

The fact that we also use Ciao means that we could easily and quickly go back and look at previous versions and understand how we'd got to here without having previously seen the error. And, really, if you change your mind on something, Ciao is a better way of doing that than relying on Designer to hang on to code that isn't of any use any more.

David Gewirtz is the author of How To Save Jobs and Where Have All The Emails Gone? For more than 20 years, he has analyzed current, historical, and emerging issues relating to technology, competitiveness, and policy. David is the Editor-in-Chief of the ZATZ magazines, is the Cyberterrorism Advisor for the International Association for Counterterrorism and Security Professionals, and is a member of the instructional faculty at the University of California, Berkeley extension. He can be reached at david@zatz.com and you can follow him at http://www.twitter.com/DavidGewirtz.