The form transformation tool was designed with the following principles:
-
The tool converts all existing Microsoft Dynamics NAV forms into pages while retaining the same functionality as the original forms.
-
Basic conversion rules (built into the tool) assume that the user interface and code on the form are compliant with the standard application development guidelines.
-
The tool identifies deviations from the guidelines that may result in missing user interface (UI) elements or functionality of the original form. The tool logs these deviations for manual consideration.
-
If the rules for modifying the page UI are generic to all pages, then the tool incorporates them into the tool mapping logic. The tool regards rules that represent "manual" decisions about certain user experience (UX) behavior, layout, and business logic as additional input. You define this additional input manually.
These principles turn the transformation into a highly automated process that makes the migration path to the new architecture as efficient as possible.
Fully automatic transformation is not possible for the standard global application or for add-ons and customized solutions. This may be caused by the following:
-
Some control types in the Classic client are not available in the same form in the RoleTailored client. For example, the MatrixBox and Shape controls are not supported.
To generate a page with the same functionality in the RoleTailored client, you have to either replace the original form with an alternate form containing controls that can be transformed, or modify the original form. One of the steps to prepare for form transformation is to redesign forms by either replacing or modifying forms. For more information, see Preparing for Form Transformation by Redesigning Forms.
-
The RoleTailored client has enhanced behavior hard-coded into its controls. Therefore, some code that was necessary in previous versions of Microsoft Dynamics NAV is now obsolete when using the new controls. This means that pages contain fewer triggers than forms. For more information, see Method Mapping Rules.
-
Automation that has no UI and does some kind of processing which includes generating files as output (or consumes files as part of input) requires special consideration. To make this work, you must rewrite C/AL code to properly supply the input or output files needed for the automation. For more information, see Evaluating Client Files and Automation.
-
Automation that uses dialog boxes to display messages or errors requires special consideration. The automation may have its own window (like an OCX) or it may interact with hardware that is local on the client (like a bar code reader or card scanner). These are now unsupported scenarios. Any solution to this problem may require a redesign that functions the same way but takes advantage of Web services, C/FRONT.NET, or another integration technology. For more information, see Evaluating Client Files and Automation.
The more your forms deviate from the design guidelines of the standard application, the more challenging it will be to transform them successfully to pages so that they support the same functionality and are compliant with UX guidelines. For more information about the UX guidelines in Microsoft Dynamics NAV 2009, see User Experience Guidelines for Microsoft Dynamics NAV 2009.
If your goal is to retain one code base in the Classic client and the RoleTailored client, rather than moving all your application development onto the RoleTailored client, you will have to plan for some redesign efforts. For more details, see Preparing for Form Transformation by Redesigning Forms.