#7536
Support 1
Participant

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.]