Indirect Ancestor Event in an Override Event
In PowerBuilder classes (Window, User Object and Menu), calling an indirect ancestor event in an override event of a descendent class results in different behavior when the application is deployed as a .NET WebForm due to C# restrictions.

For example, Window w_master is created from base window, w_employee is inherited from w_master, and w_employee_contact is inherited from w_employee. The open event of each window has the following script:

Script in w_master

//Instance variable
string msg

//Open event
msg = "Text written by Open event of w_master"
st_1.text = msg

Script in w_employee

//Open event override from w_master
msg = "Text written by Open event of w_employee"
st_1.text = msg

Script in w_employee_contact

//Open event override from w_employee
call w_master::open  //calling open event of w_master

In C# calling base methods of an indirect base class from an override method is not allowed. Hence, the code  call w_master::open in w_employee_contact gets transformed to base.open() and, as a result, it produces outcome shown in Figure 1 and Figure 2.

A workaround to this limitation is to move the script in the ancestor open event to an object function and then call this function from a descendant object.

Semantic Issues
Narrow (down) casting
NarrowCasting or DownCasting means casting a reference of an ancestor object to its descendent object. Although NarrowCasting works in PowerBuilder Win32 applications, it's considered poor coding because it's the opposite of the basic object-oriented rule. On the other hand, in a .NET language, NarrowCasting is not allowed and results in a runtime exception in .NET WebForm.

//Poor Coding practice
n_ds ds
ds = create DataStore

//Good Coding practice
DataStore ds
ds = create DataStore

Do Not Use "This" Pronoun in a Function Objects
A function object is essentially a static method of a class. Although the PowerScript compiler does not prevent using a "this" pronoun in a global function object, the PowerBuilder .NET compiler does not allow using the "this" pronoun in a function object.

A Limitation of the IsNull() PowerScript Function
In PowerBuilder .NET deployment, the IsNull() PowerScript function only works with primitive data types and does not work with structure and class objects. If PowerScript code contains IsNull() for structure  and class objects, they can be reworked with an IsValid() method as an alternative to IsNull().

Do Not Code "Return" Statement in a Finally Clause
PowerBuilder Win32 (PB native) compiler lets you code a "return" statement in a Finally block of Try - Catch - Finally - End Try statements. If you deploy this code to PowerBuilder .NET deployment, this will result in a compiler error "Return statement cannot be used in finally clause" because C# (a .NET language) does not allow a code "return" statement in a finally clause.

Do Not Change the Event Signature in Descendant Objects
If an event is declared in the ancestor object, then in a PowerBuilder native Win32 deployment you can modify the event signature in descendant objects by changing the return type or parameters of the event. However, this is not allowed for .NET deployment; the event signature in descendant objects should be identical to the ancestor, otherwise a compiler error is thrown.

Issues with External Functions
If an external function has a string parameter by reference, then enough space should be allocated for the string parameter (using the PowerScript Space() function) before passing the string to an external function by reference.

• The data type of a parameter passed to an external function should be the same as the one declared for it.
• For external functions that take structure parameters, PowerBuilder native (Win32) deployment can take structures by value, but for .NET deployment, these external function declarations have to be reworked to take structure parameters as by reference and need to pass the structures by reference rather than by value.

Avoid Naming Conflicts
In PowerBuilder two objects of different types can have same name, but in a .NET language it is not allowed. For example, you may have a global structure with a name "customer" and NVO with the same name "customer" in your application. If you deploy this application as a .NET target, it will result in a compilation error because in a .NET language, no two objects can have the same name (even if they differ in type).

Hence avoid using the same names; and if your existing applications have such a scenario, try to rename the conflicting name prior to .NET deployment.

Unsupported Features for a Web Environment
Since the user interface of the application is rendered in a browser environment, some of the user interface elements that work well in a client/server environment will not work in a browser environment and will need to be implemented by alternative means for the application to work properly.

When you deploy a PowerBuilder application as a .NET WebForm application, all the unsupported features for the .NET WebForm application are listed in the Power Builder IDE output window. For unsupported features in the .NET WebForm applications, the feature fails silently at runtime but the application is not prevented from running.

You can download a .NET Feature Analyzer utility from the PowerBuilder CodeExchange Web site created by Jim O'Neil to scan your application for unsupported .NET features and re-factoring tips.

Clipboard Functions
Clipboard functions such as edit, cut, copy and paste in the PowerScript application does not work in a .NET WebForm application. These functions are pure PowerScript functions in the application and they are not to be confused with Internet Explorer's Edit menu functions. IE menu functions continue to work as before.

Drag & Drop Functionality
All the drag and drop-related methods, properties, and events in the PowerBuilder application will not work in the .NET WebForm application. Consider reworking with alternative code for this feature to preserve the functionality of the application

EditBox & MultiLineEdit Control Functions
Some of the EditBox and MultiLineEdit control functions such as LineCount(), LineLength(), SelectedLine(), and TextLine() do not work in the .NET WebForm application.

TreeView Control Functions
Most of the PowerBuilder treeview control functions are supported in the .NET WebForm application, but there are a few functions that are not supported in the browser environment such as EditLabel(), GetItemAtPointer(), and SetFirstVisible()

DataWindow Support

• Presentation styles: RichText and OLE DataWindow are not supported in WebForm
• DataWindow Expressions: The DataWindow expressions containing the DW functions LookupDisplay, Page, PageAbs, ProfileInt, and ProfileString are not supported
• DataWindow object controls: The DataWindow object controls Oval, RoundRectangle, InkPicture, InkEdit, OLE Object, and OLE database Blob controls are not supported.

Any Other Desktop Features
Any other desktop features in your application that are not supported by the browser environment may need to be reworked to deploy the application as a .NET WebForm. For a complete list of unsupported properties, functions, and events for .NET WebForm, refer to PowerBuilder 11.0 documentation.

Recommended Coding Practices
Unlike the client/server application where both the application logic and the user interface are executed on the same machine, in a Web application, application logic is executed at the server (Internet Information Server) running in a different machine and the resultant code along with HTML are rendered to the browser running in another machine.

Due to this fact, a simple user action such as a mouse-click or any piece of code that requires server logic may generate a round-trip back and forth between the server and the client browser. This will cause application performance to degrade or create hindrances to an interactive data entry application. If you intend to deploy an existing PB client/server application as a .NET WebForm application, you may have to rework your application to remove or re-factor the code that contributes to frequent round-trips to the server.

This section describes some of the recommended coding practices when an existing application is deployed as a .NET WebForm application.