vs
    Img.OCR.ViewLog()

VB
    Set swObj = CreateObject("Summation.Application")
    swObj.Img.OCR.ViewLog()    

C#
    Type summationType = Type.GetTypeFromProgID("Summation.Application");
    object swObj = Activator.CreateInstance(summationType);
    object swImgMethod = swObj.GetType().InvokeMember("Img", BindingFlags.InvokeMethod, null, swObj, 
        null);
    object swOcrMethod = swImgMethod.GetType().InvokeMember("OCR", BindingFlags.InvokeMethod, null, 
        swImgMethod, null);
    swOcrMethod.GetType().InvokeMember("ViewLog", BindingFlags.InvokeMethod, null, swOcrMethod, null);        

C#
    using swsom;
    ...
    sw.Img.OCR.ViewLog();

VB
    Imports swsom
    ...
    sw.Img.OCR.ViewLog()

Parsing & Cleanup

In order to create the code, I wrote an app that processed the xml file (sumscript.xml) that holds the scripting help file documentation and as output created several .vb files:

• create two .vb files (one for items marked as Properties in the sumscript, another for Methods, were later manually combined into a single file) for each object, with appropriate nested Class statements
• for each entry point
  • if it was defined as Method in sumscript, read the Syntax value and write out as a VB Function if it returned a value, as a Sub otherwise
  • it Property, write out as a Read-Write VB Property
  • initially set as Shared i.e. non-instance
  • read the Description, Notes, Syntax values from sumscript and prepend to each method/property as XML comments
  • try to keep original name if possible, surrounding VB keywords with square brackets e.g. [keyword] where necessary
  • for v1.1, all Optional parameters were removed since they had, necessarily, been defined in v1.0 with arbitrary default values. In some cases these values would actually have negative effects, overriding the 'default' values embedded within the application. The lack of real support for optional parameters in C# also presented problems.
    • those Subs and Functions that had Optional parameters were re-written to have multiple overloads, one for each combination of required and optional parameter(s)
  • where it proved more efficient, modify the original sumscript file and re-run the parser application
  
  

  After the initial parsing, each .vb file needed to be reviewed and corrected as necessary. In some cases there were mistakes or inconsistencies in the original documentation that were persisted to the generated code while in other cases the code simply needed to be re-formatted to be more VB friendly.

  Some of the fixing steps involved:

  • looking at each Property and trying to determine if indeed they should be both Read and Write. For some the documentation contained a reference but many did not and I made an educated guess when deciding to set as ReadOnly. The original Set accessor was only commented out though, so it can easily be revived if appropriate (assuming the syntax in the Set wasn't later changed)
  • moving the base Application class into its own child-class, only done so that the Intellisense would be less cluttered at the base level
  • creating a working configuration of those classes that were Collections. Generally this meant changing the members into instance classes and it is quite possible the implementation will change in the future - the goal for now is 'good enough'. They are not enumerable right now and therefore do not act as a true collection
  • conform any Properties that used parameters, a syntax that is generally not supported in C#. Many properties were re-formatted as Functions but still lie with in the 'Properties' region code of a given .vb file
  • an occasional helper method was introduced here and there