Skip to main content

Classes

Functional Classes​

Functional Classes from the original OpenText Team Developer application are all ported to public classes. The files are located either in the main application's directory or in the \Classes subdirectory, depending on the options set in Ice Porter.

The structure of the generated classes is simple and reflects the original structure. The description of the class is ported to the <summary> comments for the class. Variables and functions are grouped together and enclosed in regions.

If the class had a ObjectDestructor() method, the code is ported into a destructor in .NET. However, destructors in .NET are not called in a predictable manner because of the garbage collector. This difference in behavior may cause problems in the ported application and needs to be addressed by a developer.

The base class for Functional Classes is PPJ.Runtime.SalFunctionalClass.

Visual Classes​

Visual classes are all ported to public classes derived from the corresponding control class in the PPJ Framework. The files are located either in the main application's directory or in the \Controls subdirectory, depending on the options set in Ice Porter.

The structure of visual classes is compatible with the Visual Studio Designer guidelines. All the visual properties are generated in the InitializeComponent() method. A call to InitializeComponent() is placed in the constructor. When the corresponding Ice Porter option is enabled, the designer's code is generated into a separate file called <class name>.Designer.cs.

Design-time editing depends on the class, its base type, and the designer supplied by the installed tooling. A form or UserControl normally provides a visual design surface; a single-control subclass may expose properties without offering the same editing experience. Successfully compiling a class does not guarantee the designer can construct it.

Constructor, Designer, and Runtime Work​

Keep generated InitializeComponent() calls in their expected place: this is where controls, properties, and event connections are established. The designer may instantiate the class, so avoid putting database logins, file writes, or business operations unconditionally in construction code.

When an inherited form fails to open in the designer, build its base-class project, resolve missing design/runtime dependencies, and inspect the first construction exception. Do not remove initialization or change the base class just to dismiss the designer error; either can change the running application's behavior.

Resource Ownership​

A C# destructor is a finalizer, not deterministic cleanup. Move time-sensitive cleanup of owned connections, files, or subscriptions into an explicit lifecycle method or IDisposable implementation as appropriate. Do not access UI controls from a finalizer. See Microsoft's Dispose pattern.

Keep custom logic out of designer-managed initialization where possible. Inherited controls and multiple-inheritance wrappers may require runtime checks even when the form looks correct in the designer.