General Guidelines on how to deal with Application Form classes

Note: This page includes content based on the F1 documentation for Centura development. It may be partially converted to support APF development, but should be regarded to be of uncertain actuality. It is provided as is. Eventually, it should be replaced by documentation available from within Visual Studio.

This page will provide you an idea of how to deal with Centura converted application form classes and how the Centura event base coding is mapped to tally with the .Net framework. We will discuss a few of the implementations which are widely used in Application forms development.

Contents

Using Interfaces

A powerful companion to inheritance is the use of interfaces. Interfaces are like a hundred percent abstract super class that defines the methods a subclass must support, but not how they must be supported. The .Net client is using a set of common interfaces in order to keep the integrity of the coding.

These will be shown under Interfaces topic in each class reference.
 

How Multiple inheritance is mapped

In many cases, multiple interface inheritance can get the job done easily, but Multiple inheritance in the EE is handled in the below shown manner.

public class cContainerTabDialogBox : SalDialogBox, cDataSource.LateBind
{
// Multiple Inheritance: Base class instance.
protected cDataSource _cDataSource;

/// Multiple Inheritance: Wrapper function.
public SalBoolean DataSourceExecuteSqlStateEvent(SalString sEvent) { using (new SalContext(this)) { return _cDataSource.DataSourceExecuteSqlStateEvent(sEvent); } }
}

An Instance is created and the base class is been called through the reference. This way the multiple inheritance is been achieved with out the confusion of which class we are inheriting the method from.

These will be described under Instance Objects with mapped interfaces topic in each class reference.

Using Late Binding in Application Forms

Late binding is widely used in Centura in order to bind an Object at runtime. This is also called Dynamic binding. The symbol used in Centura is  ..<method name>.

In the new dot net frame work late binding is achieved by using a separate method, name with Vrt<method name> format, which is been declared in the LateBind Interface. “Vrt” is the prefix for virtual methods (late bound)

When an application is converted from Centura to .Net, virtual method stubs are generated for all methods that have been called late bound. If a specific method is not called late bound when converted that method will not have a Vrt<method name> stub generated. Later when an application by some reason is calling this framework or external method late bound the conversion tool try to call the Vrt version of the method which then is not existent.

Fix: Investigate why there is a late bound call made in the application layer that is not used as late bound by the framework.

  1. If there is a clear reason to why this construction exists, implement the method signature in the application class so that the virtual stub can be generated at this level. This can be done by implementing the LateBind Interface. An example of this is shown below.
  2. If this call is made by no apparent reason e.g. there is no deriving class that is overriding this hook. Just convert the late bound call into a direct call. 

 

#region Multiple Inheritance Late Bind Interface
public interface LateBind
{
	SalBoolean vrt_Parse(SalString sURL);
}
#endregion
#region Late Bind Methods
/// <summary>
/// Virtual wrapper replacement for late-bound (..) calls.
/// </summary>
public virtual SalBoolean vrt_Parse(SalString sURL)
{
	LateBind lateBind = this._derived as LateBind;
	if (lateBind == null) 
	{
		return this._Parse(sURL);
	}
	else
	{
		return lateBind.vrt_Parse(sURL);
	}
}
#endregion
//Using the vrt methods
public SalBoolean SetURL(SalString sURL) { // URL // Ifsapp protocol based URL to be parsed. #region Local Variables #endregion #region Actions return this.vrt_Parse(sURL); #endregion }