Support 1

[Support 1]

Dear L.P.,

Thank you for your enquiry below.

Formativ does not provide a mechanism for storing ‘handles’ to objects created by an applet. This means an applet cannot retrieve a ‘custom object’ at any time during a GroupWise session. In your case, the custom object would be a handle to an ADO session and/or recordset.

Here are two suggested approaches to resolving your requirement:

• Implement 2 applets, A and B:

  Applet A collects and saves data to a file F in a well-defined location on the workstation, eg. Windows temporary directory or an appropriate applet-defined data directory. This might be a plain-text file containing multiple records, which are added (or modified/deleted) whenever the applet executes.

  Applet B connects to the required database(s) and adds/updates records from F, then deletes F.

  Of course, this approach does not provide for ‘real time’ updates to the database; applet B must be executed at suitable intervals when ‘enough’ data has been gathered.

• Implement a COM server which can be used by an applet as shown in the following example:

    set oAdoHelper = GetObject("AcmeCorp.Data.Ado.AdoHelper", )
    if not IsObject(oAdoHelper) then
      set oAdoHelper = CreateObject("AcmeCorp.Data.Ado.AdoHelper")
      if IsObject(oAdoHelper) then
        ' do stuff with database
        ' ...
      end if
    end if

  The server will need to maintain a connection to the database(s) between requests from the applet. In addition, the server will need to remain loaded in memory for as long as any applet requires access to the database connection.

I hope this helps you.

Regards,
Advansys Support

[Support 1]

Thank you for your enquiry.

The scripting language used in Formativ solutions is VBScript, which is executed by the Windows Script Host (WSH). This environment provides the means for a Formativ solution to be a COM client.

For each .NET module that you want to be callable from a Formativ solution, you will need to ensure that there is a COM-callable wrapper (CCW). One way to do this is by using the .NET command-line utility regasm:

C:WindowsMicrosoft.NETFrameworkv1.1.4322regasm <PathToAssembly>MyAssembly.dll /codebase

See the .NET Framework documentation for details on this utility.

Then in a Formativ solution, you could create an instance of the wrapper class (MyClass in the MyAssembly assembly in this example):

  set oMyObj = CreateObject("MyAssembly.MyClass")
  if not (oMyObj is nothing) then
    ' Do stuff with oMyObj...
    ...
  end if

NB: There are some important gotchas to be aware of with COM Interop:

• We have seen, at least with .NET Framework 1.1, that only simple .NET types will marshal correctly from/to COM. Simple types include Int32, String and the root class type Object. For example, consider the following strongly-typed C# method of a public class:

      public void Add(Message msg) { ... }

  An instance of the GroupWise Object API type Message cannot be passed to this method by a Formativ solution. The type-checking mechanism in the .NET runtime does not recognize the passed object type as Message, and will throw an exception. The workaround is to “wrap” the method inside a weakly-typed helper method:

      public void InteropAdd(Object msg)
      {
          // An explicit typecast is required to use the strongly-typed Add().
          Add((Message) msg);
      }

• A corollary to the point above is that overloaded methods cannot be resolved by COM Interop. For example, consider the following C# methods:

      public void Add(Mail m) { ... }
      public void Add(Appointment a) { ... }

  The inability of the .NET runtime to determine the type of the passed object means that it cannot determine which of these overloaded methods to invoke.

  In addition, we have seen that a Formativ solution cannot use any of the following overloaded methods:

      public void SaveToFile(String text, String path) { ... }
      public void SaveToFile(String text, String path, Boolean replace) { ... }

  Whether a solution specifies the first or second method signature, only one of these overloads will ever be invoked. It may be tempting to use the overload that is invoked, but we believe it is unwise to assume it will always be the same; it may change with a later version of either the .NET Runtime or your .NET assembly. To provide the choice of these methods to a Formativ solution, they would need to be explicitly named, as in the following example:

      public void SaveToFileReplaceAlways(String text, String path) { ... }
      public void SaveToFileReplaceOption(String text, String path, Boolean replace) { ... }

Depending on the complexity of your .NET object, you may need to create a separate “wrapper object” which delegates COM client requests to the wrapped object. This might be necessary for security, to avoid exposing certain methods in the wrapped object. The wrapper would expose weakly-typed methods/properties which make internal references to the wrapped object. It might also expose explicitly-named methods to avoid depending on automatic resolution of overloaded methods.

I hope this helps.

Regards,
Advansys Support

[This message was edited by Support 1 on June 28, 2006 at 07:08 PM.]

[Support 1]

No problem.

Note: The sample code acknowledges the possibility that an existing message class can be subclassed. The test against class name looks for a substring, not an exact match. For more details on subclassing messages, see the Novell Web reference cited above.

Regards,
Advansys Support

[Support 1]

Thank you for your enquiry.

We have not had this behaviour reported previously. Here are some questions/comments:

• Did you upgrade recently from an earlier version of Formativ – if so, which one?
• The Formativ Help Center is a Web browser-based feature of Formativ. It is displayed when GroupWise starts; your firewall or other security settings might be preventing it from connecting, which could cause the delay. You can configure Formativ not to display the Help Center: select Help | Formativ Help Center… from the GroupWise main menu. When the Help Center dialog appears, click the Options button to specify when you want it to be appear; select “Never” from the displayed list. Then restart GroupWise to see if the start-up time is reduced. If so, you may need to modify your firewall settings or else disable the Help Center (this can be done at installation using a configuration file; this is documented in the Formativ Users Guide).

Please send the Formativ configuration from an affected machine to support@advansyscorp.com. You can obtain the configuration by selecting Help | About Formativ… from the GroupWise main menu. When the About Formativ dialog appears, go to the Configuration tab and click the button Copy to clipboard. Then paste the text into your email (or save it to a plain-text file and include it as an attachment). We will take a look and let you know if anything is amiss.

Regards,
Advansys Support

[Support 1]

Thank you for your enquiry.

You will need to test the ClassName property of the Message object. This web reference is documented in the Introduction to the Formativ Developers Guide.

Here is some sample code to get you started:

  iClassName = oMessage.ClassName
  If InStr(1, iClassName, "GW.MESSAGE.MAIL", vbTextCompare) = 1 Then
    ' Process Mail message...
  Elseif InStr(1, iClassName, "GW.MESSAGE.APPOINTMENT", vbTextCompare) = 1 Then
    ' Process Appointment message...
  Elseif InStr(1, iClassName, "GW.MESSAGE.TASK", vbTextCompare) = 1 Then
    ' Process Task message...
  Elseif InStr(1, iClassName, "GW.MESSAGE.NOTE", vbTextCompare) = 1 Then
    ' Process Note message...
  Elseif InStr(1, iClassName, "GW.MESSAGE.PHONE", vbTextCompare) = 1 Then
    ' Process Phone message...
  Elseif InStr(1, iClassName, "GW.MESSAGE.DOCUMENTREFERENCE", vbTextCompare) = 1 Then
    ' Process DocRef message...
  End If

I hope this helps.

Regards,
Advansys Support

[Support 1]

I would say that resolving this issue will require some analysis of which files are missing.

It is most likely that the name lengths of the lost files is the problem. CD-ROM file systems have not evolved to match the flexibility of the Windows FAT32/NTFS file systems. Given the current standard in CD-ROM file systems, I think you will find that no CD-ROM writing software can support “long” file names.

Message Saver does a file existence check when it saves each message. If you specify a subject length limit, the existence check will honour the limit. In addition, Message Saver ensures that a sequence of messages with the same subject will be preserved (with a distinct file name for each message). However, when copying from hard drive to CD-ROM the truncation may, as you suspect, cause the distinctness to be lost and files to be overwritten.

I would suggest that you investigate the maximum allowed file name length (it may vary depending on the directory depth). Then specify an appropriate subject length limit in Message Saver, taking into account that up to 11 additional characters will be required for the suffix. Then the distinct file names created can be copied unchanged to CD-ROM.

I hope this helps.

Regards,
Advansys Support

[Support 1]

Thank you for your enquiry.

Have you tried creating an equivalent HTML-format message manually, ie. without using Stationery, to send to a non-GroupWise client? To do so, you would use the GroupWise 7 composing message editor features to insert images inline.

I look forward to hearing of your progress.

Regards,
Advansys Support

[Support 1]

Thank you for your enquiry.

This is not a known problem with Message Saver Pack.

From your description, the issue is specifically to do with writing files to CD-ROM. The behavior may differ between Roxio Easy CD Creator and other software for writing CD-ROMs. Could you describe what happens when you are “losing thousands of messages?” Do you see error messages while writing files from hard drive to a CD-ROM?

It’s difficult to guess at a solution without specific details of how messages are being lost. Perhaps you could review the CD-ROM file system specification in the Roxio documentation. Your lost message file names may be longer than the file name limit allowed. Or the directory hierarchy may be deeper than Roxio allows. Or the problem could be a combination of the two.

Message Saver can be configured to limit the length of the message subject (which will be included in the file name) to a specified amount. The default is unlimited. You will need to take into account the 10-11 character suffix in each FML filename.

I hope this helps.

Regards,
Advansys Support

[Support 1]

Thanks for your answer, MA.

Simon,

1) According to Novell, a defect prevented the On Reply event from firing when choosing an item from the Reply dropdown button. This was fixed in GroupWise 6.5 SP1 (and I believe also in 6.0x, retrospectively). However, I think the issue you have seen is probably related to the following.

In general when installing an applet which registers GroupWise integrations (eg. the On Reply event), GroupWise will need to be restarted twice. When GroupWise starts, Formativ checks each installed applet for integrations and registers them if not already registered. However, at this point GroupWise has completed its loading of integrations; only on the next start-up will the newly registered integrations be loaded. This issue is documented in the Formativ Developers Guide.

If Formativ Creator or Studio is used to change an applet’s integrations (ie. at design-time), GroupWise will need to be restarted just once. This is because the Formativ IDE registers changes to integrations whenever they are made.

Neither your Trace Events applet nor a specific way of closing GroupWise will make the integrations apply.

2) An alternative way to access the selected message (ie. a message which is not open for viewing/composing) is via the SelectedMessages collection. This might be required as a workaround for an earlier version of GroupWise than MA’s. Here is some sample code:

  set oMessageList = oClient.ClientState.SelectedMessages
  if oMessageList.Count > 0 then
    set oMsg = oMessageList.Item(1) ' this is a 1-based collection
    ' do stuff with oMsg...
  end if

I hope this helps.

Regards,
Advansys Support

[Support 1]

This enquiry has been answered by direct email.

Advansys Support

[Support 1]

Thanks for your replies L.P. and MA.

Simon:

Formativ also displays error messages which originate from GroupWise and the Windows Script Host. This is why you see a dialog titled “Sorry, the applet could not be executed” with a message like “Catastrophic Failure” or “Object required…”

Another way to determine whether a folder is shared incoming is to check its Shared property, as in:

  if oFolder.Shared = fgwSharedIncoming then
    ...
  end if

Given a Message object reference, you can obtain its enclosing folder from the property EnclosingFolders.

To find out how a given GroupWise event works, try this. Create a simple applet that displays a message box, associate it with the appropriate event(s) and see when it gets executed. The behavior you see will dictate when to use one event over another.

It’s often worthwhile posting questions about the GroupWise APIs to the appropriate Novell Developer Support Forums. While we always try to respond where possible, time constraints may prevent us from fully answering enquiries about issues that are specific to the GroupWise APIs.

I hope this helps.

Regards,
Advansys Support

[Support 1]

Simon,

You are right that the Registry key mentioned in your post is required for each user. To make this available to all users, add the key value to the hive HKEY_LOCAL_MACHINE rather than HKEY_CURRENT_USER. This will be possible if the GroupWise client is version 6.5 SP1 or later.

We will shortly be releasing a minor update to the Formativ installer, to write the key value to the appropriate Registry hive automatically.

I hope this helps.

Regards,
Advansys Support

[Support 1]

Dear Simon,

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 support@advansyscorp.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.

Regards,
Advansys Support

[Support 1]

Thank you for your enquiry.

Unfortunately Templates does not have support for a “repeating field” whose value is obtained from a dynamic template.

If your users have the solution Search and Replace installed, you could direct them to use it to replace a special marker in the text produced by Templates. For example, the marker could be:

  [[CompanyName]]

I realize this is not an ideal work-around. Alternatively, you could build a Formativ solution to do this. In addition, you may be able to find an existing free solution that fits this need at Formativ Applet Central.

I hope this helps.

Regards,
Advansys Support

[Support 1]

Your suggestion has been added to the enhancements database, and will be considered for a future release of Formativ.

Regards,
Advansys Support

[Author]

Replies