Generator Options
Package Name
This option stipulates the base package name in which code should be generated. A sub package for enumerations (enums) and COM interface implementation wrappers (impl) will be created from this base package name.
Include imported types in generated code
Determines if imported types should be included. If this option is false then the generator will skip all methods, variables, events, interfaces and enumerations that include a type from an imported library. For example if a method includes a parameter that references an imported type this method will be quietly skipped and have no code generated. This option provides support to generate wrappers that are not dependant on any other wrappers and will then compile and package as a single unit. As an example the MSWord type library imports the MS Office and VBA IDE type libraries. If you wish to automate MS Word but do not have a need to automate MS Office or the VBA IDE then you would set this option to true.
JDK Source Code Compliance Level
Determines the Java compliance level for which the code will be generated.
This option mainly affects Enumerations and Collections. If Java
1.5 is active then the native enum java type will be
used along with Generic types provided for collections.
COM Type Library File Name
This is the fully qualified pathname to the type library for which wrapper code should be generated. You must specify either a type library file name or GUID to generate. If you specify both the type library GUID is ignored and only the file name is used.
COM Type Library GUID
This is the global unique identifier of the type library for which wrapper code should be generated. You must specify either a type library file name or GUID to generate. If you specify both the type library GUID is ignored and only the file name is used.
Generate Classes for embedding controls in SWT Composites
If the type library is for a visible component it is often possible to embed the component as a widget in to SWT. This option will generate a SWT Composite to support this behaviour. SWT currently only supports activating these by ProgID so the generator will only generate Composites for types that have a ProgID and an IID.
Generate SWT Composites as delegates
Determines if the embeded Composite will be generated as a delegate. This option is only applicable when the previous option to generate embedded Composites is also selected. A delegate Composite will implement the default interface and will have all of the required methods implemented as delegates to the wrapped Interface or CoClass. In some cases this can cause problems since some COM types have methods for which the return type conflicts with the SWT hierarchy (eg: getParent or getBackground).
Generate Classes for COM types marked as restricted
Type libraries mark some methods and interfaces as being restricted. Since these interfaces are usually for internal use by the component, accessing them via automation is often not required. This option provides support to override this behaviour and generate code to access restricted members.
Bind CoClasses as Alias to its default interface
By default the Visual basic Object browser uses the CoClass Name as an alias to the default interface name. This option provides support for this same behaviour in the generator. Setting this option to true will mean that the Java code will have a very visual basic like syntax.
Generate dispatch ids as constants
By default the disp ids used for calling the dispatch interface is hardcoded as a hexidecimal value. This makes it difficult should you want to use the disp id elsewhere in your code. This option provides support to generate the disp ids as constants on the interface to which they belong making it then much easier to reuse them within calling code.
Generate enumerations as static final constants
By default type library enumerations are generated as classes. This provides for strong type checking at compile time. However some type libraries provide loosly coupled enumerations or lots of enumerations. In these cases it might be preferred to have the enumerations as static final integer constants.
Generate using dispatch interfaces
Determines if the dispatch interface should be used for generating wrappers. This flag is only applicable for dual interfaces. By default SWTtoCOM uses the Interface definitions for dual interfaces since the interface definition includes the type heirarchy of the component. In some cases it may be desirable to force the use of the dispatch interface which is done using this flag.
Generate optional parameters as overloaded methods
Determines if optional parameters should be provided for by overloading methods. In COM optional arguments can be passed in two ways.
- Positional With this method optional arguments must appear at the end of the parameter list. If an optional argument is omitted when calling the method, all arguments to the right of this one must also be omitted. This is similar to the C++ rules for calling functions with Default values for parameters.
- Non Positional With this method the optional arguments can appear anywhere in the parameter list. Parameters that are left unspecified should be filled in as variants of type VT_ERROR with the value DISP_E_PARAMNOTFOUND.
- A method that accepts the first 2 arguments only
- A method that accepts the first 3 arguments only
- A method that accepts all 4 arguments
Generate Automation Object Factory
Determines if automation objects should be created using a factory. An
automation object factory converts a COM interface into its corresponding
Java wrapper at runtime. In some libraries the types returned at runtime
are different to those declared in the type library and therefore used at
generation time. For example in the SHELL32 type library the
FolderItem.getFolder() method defines its return type as
IDispatch however at runtime it returns a Folder3
interface. If a runtime automation object factory is used then you can simply
cast this to the correct Java type. For Example;
Folder folder = (Folder) folderItem.getGetFolder(); String title = folder.getTitle();If you do not use a runtime automation object factory then you cannot cast to the corresponding Java type and must instead either use automation methods or manually call the runtime automation object factory from user code. For Example to use automation methods;
IAutomationObject folder = folderItem.getGetFolder();
Variant variantTitle = getProperty(Folder.DISPID_FUNC_GET_TITLE);
String title = null
if (variantTitle != null) {
title = variantTitle.getString();
}
Or to use a runtime automation object factory from user code;
IAutomationObject folder = folderItem.getGetFolder();
Folder folder = (Folder) STCAutomationObjectFactory
.createFromAutomation(folder);
String title = folder.getTitle();
NOTE: Using a runtime automation object factory adds a small performance overhead since each type is interogated for its IID and then the corresponding class is initialized via reflection. If your type library contains good type checking then you should not need to use a runtime automation object factory.
Generate Event Listener Adapter Classes
Determines if event adapeters will be generated for each listener. Some COM event interfaces are quite large and can contain many event methods. To help avoid user code from implementing empty body event handler methods, SWTtoCOM can generate an event adapter for each listener. This means that the user code need only extend the event adapter and implement the event handlers that it is really interested in.