Modified and Unsupported Features in PowerBuilder .NET

Some features in PowerBuilder Classic are not supported in PowerBuilder .NET. Other features are partially supported or use a different method to obtain similar results or to display similar functionality.

Several differences are the result of .NET restrictions, or the Visual Studio isolated shell designer and functionality that PowerBuilder .NET leverages. The following features are not currently supported or are only partially supported in PowerBuilder .NET:

• Target location – you can save workspaces and libraries to the root directories of computer drives, but do not save PowerBuilder .NET target files (PBTX) to root directories.
• Event sequence – the difference in event sequence in WPF applications may affect applications that are dependent on a strict order of triggered events. You must manually refactor migrated applications to take into account the order of triggered events.

  Although Web Forms applications also use a different event sequence than Windows 32 or Windows Forms applications, in Web Forms applications, you can save the events to a queue and execute them during a postback operation. For WPF applications, events must be handled immediately after they fire.

• User-defined custom events (partial support) – PowerBuilder .NET uses a different event model than PowerBuilder Classic. For a list of supported custom events in PowerBuilder .NET, see Supported Custom Events.
• Fonts that are not TrueType or OpenType fonts – although you can only select installed TrueType or OpenType fonts in PowerBuilder .NET, you can still enter the names of other fonts for the FaceName property of controls that display text. You can also migrate applications that use non-TrueType fonts from PowerBuilder Classic. However, at runtime, the .NET Framework replaces fonts that are not TrueType or OpenType fonts, causing unexpected changes to the way the text appears to end users of PowerBuilder .NET applications.
• Coding restrictions – several PowerScript coding practices, such as dashes in identifiers or colons for microsecond separators in time functions, are not permitted in .NET environments. For more information, see Coding Restrictions.
• Section 508 support – uses UI Automation (UIA) to implement accessibility instead of the Microsoft Active Accessibility (MSAA) used by PowerBuilder Classic. UIA implements a UIA-to-MSAA bridge, so you can still use MSAA tools for application accessibility in PowerBuilder .NET. You can also use newer tools based on UIA for this purpose.

  UIA supports the AccessibleName property, but does not support the AccessibleRole and AccessibleDescription properties on windows and controls that inherit from DragObject.

• Window previews – do not work for untitled windows. You must save a window before you can preview it at design time.
• Control handles – in PowerBuilder Classic applications, each control has its own window handle, and many operations depend on the window handle. In PowerBuilder .NET, there is only a single "big" handle for a window, but the controls nested in a window do not have their own handles. You must refactor migrated applications that use API calls relying on control handles before importing them to PowerBuilder .NET.
• Design-time list views – the Control List, Non-Visual Object List, Function List, and Event List views are replaced in PowerBuilder .NET by the Document Outline and the PB Object Outline.
• Library painter and the (PowerScript) Browser – most of the functionality of the Library painter and the Browser is available from Solution Explorer context menu items and the PB Object Outline.
• External visual objects – are not supported in PowerBuilder .NET. You must remove these objects manually before you migrate applications from PowerBuilder Classic. Although the Migration wizard reports unsupported system features, it does not report user-defined features, such as external visual objects, that are unsupported.
• Resource files – are added directly to a target or a folder under the target. PowerBuilder .NET does not use PBR files, although if you convert a target from PowerBuilder Classic, the new target wizard lets you select resources that are listed in a PBR file associated with the target you are converting.
• The Plug-in Manager – in the PowerBuilder Classic IDE is replaced in PowerBuilder .NET by the Add-in Manager from the Visual Studio isolated shell. To enable add-ins, see Add-ins in the PowerBuilder .NET Environment.
• Pipeline and query objects – cannot be created from the New dialog box. In PowerBuilder .NET, you can create query objects only in the SQL Dialog invoked from the DataWindow painter, although you can also import or migrate them from PowerBuilder Classic. Pipeline objects are not currently supported in PowerBuilder .NET, and if you import or migrate these objects, they are ignored at runtime.
• OLE controls – only partially supported in PowerBuilder .NET.
• PBNI (including PBDOM objects) – are not supported in PowerBuilder .NET.
• Profile- and trace-related objects – are not supported in PowerBuilder .NET.
• EAServer components – are not supported in PowerBuilder .NET.
• EMF and WMF image formats – these formats are not supported by WPF because they are more susceptible to security vulnerabilities than other image formats.
• Syntax and semantic checking – occurs in the background, and you do not need to save or compile a script to detect any scripting errors. The Script Editor inserts a red caret under the errors that it detects, and you can also view the list of detected errors in the Error List window. In semantic checking, the parser uses type information to validate the script.
• Passing strings by reference – before passing a string to an external function by reference in PowerBuilder .NET, allocate memory for the string by calling the Space system function. This enables you to pass the same string to the function in subsequent calls to the function, even if the string becomes empty.
• Global variables and global external functions – can only be declared in the Application object of a WPF Window Application target.
• Timer system function – may require the WindowName parameter to trigger the Timer event, particularly if several windows are open. This parameter is optional in PowerBuilder Classic. Also, there is a slight timing interval difference (typically about 1 millisecond) due to the threading model in WPF applications.
• Debugger – is now based on the Visual Studio debugger. The Debugger Changes topic summarizes differences with the PowerBuilder Classic debugger.
• Source control – connections to source control use completely different mechanisms in PowerBuilder .NET and PowerBuilder Classic. For more information, see Source Control in PowerBuilder .NET.
• Resource objects – all DataWindow and query objects in WPF targets are compiled in a separate DLL (appName.resource.dll) rather than in the application executable.
• Look and feel differences – the size of WPF controls is determined by the controls' contents.

For a list of unsupported PowerScript properties, events, and functions in PowerBuilder .NET, see Unsupported Properties, Events, and Functions.