Does this error appear for all folder types, or just for shared incoming folders? Does it always occur for this folder? Does it occur for other shared incoming folders?
You are correct in assuming that the message title “Sorry, the applet could not be executed” is related to Formativ. Given the steps you describe, this indicates that a Formativ applet was triggered by a GroupWise event. The specific error has occurred inside one of the GroupWise binary modules, “gwenv1.dll”.
The message “Catastrophic Failure” is most likely from GroupWise – it is definitely not from Formativ.
Both of these errors are likely to result from the GroupWise Object API state becoming unstable. This can arise due to a Formativ applet calling into the API in a sequence which leads to a memory leak or a dangling pointer. In fact, an applet may need to “manage” internal API resources. This applies to other C3PO Developers (eg. Delphi, VB, C++), as well as Formativ Developers.
Our experience with the GroupWise APIs has taught us that sometimes an obvious or intuitive approach is not feasible; that an applet must be redesigned to work around an API defect or to manage internal API resources. In rare cases we have never found a workaround. For example, given a message object reference, accessing its properties can provoke misleading GroupWise errors – where the message’s enclosing folder is a query folder or shared incoming folder.
The first thing, however, is to determine which, if any, applet leads to the “on open” error. This requires a process of elimination, as suggested by the following steps:
- For each applet, go to the Integrations tab in the Formativ IDE and uncheck the box at Enable integrations.
- Now that all applets are disabled, close the Formativ IDE and try to open your message in the shared folder. If no error appears then the problem is definitely related to one (or more) applets. But if an error appears then enable your applets’ integrations, restart GroupWise and send your Formativ configuration to email@example.com (ignore the step below).
- Enable one applet and try to open your message in the shared folder. If it opens without error, enable another applet and try again. And so on.
If you find that the error appears when one of your applets is enabled, you may need to add some bullet-proofing to the applet. That is, change the source code to bypass processing if the enclosing folder of the active message is one of the usual suspects. You can also add Trace commands to your source code to get a real-time picture of the execution sequence. See the Developers Guide section Error Handling and Debugging for details.
I hope this helps.