Register Form

When a window is developed it needs to be registered in the application dictionary. The dictionary is used by the framework to lookup information about the windows in runtime. The dictionary describes relations between windows, views and LU:s. This information is used by framework concepts like security, zoom, object connections, selections etc.

Contents

Registration Process

The registration is made by annotating the form main class file (frmX.cs) with certain attributes depending on what kind of registration that is needed. During build, all the annotations are compiled to the dictionary.xml.gz file which is used by the application runtime.

In previous version form registrations were made in other places, like component.xml. This is now replaced with annotations in the source code for the form. Figure 1 and 2 shows the difference between 7.5 and 8.0.

<TabPageEntries>
    <TabPageEntry>
        <ParentObject>frmCompany.picTab</ParentObject>
        <WindowVersion />
        <Window>frmCreateCompany</Window>
        <TabTag>DOMAIN-frmCreateCompany</TabTag>
        <TabTitle>WH_CreateCompany: Accounting Rules</TabTitle>
        <Ordinal>0</Ordinal>
    </TabPageEntry>
</TabPageEntries>
<WindowEntries>
    <WindowEntry>
        <Name>frmCreateCompany</Name>
        <View>COMPANY_FINANCE</View>
        <LU>CompanyFinance</LU>
        <DefaultWindowText />
        <Flags>0</Flags>
        <OverrideDefaultHome>false</OverrideDefaultHome>
        <AssociatedHomepage />
    </WindowEntry>
</WindowEntries>

Figure1: Component.xml (in IFS Applications 7.5)

[FndWindowRegistration("COMPANY_FINANCE", "CompanyFinance", "", FndWindowRegistrationFlags.None, false, "")]
[FndDynamicTabPage("frmCompany.picTab", "", "DOMAIN-frmCreateCompany", "WH_CreateCompany: Accounting Rules", 0)]
public partial class frmCreateCompany : cMasterDetailTabFormWindowFin 

Figure2: Annotated frmCreateCompany.cs (in IFS Applications 8)

Basic window registration

The FndWindowRegistration attribute is the base element type that is used for base registration.

[FndWindowRegistration(View, LU, DefaultWindowText, Flags, OverrideDefaultHome, AssociatedHomePage)]
Element Description
LU Logical Unit associated with the window. This parameter should be the same as the Logical Unit that the main data source is bound to.
View View associated with the window. The view contains the data that is shown in the window. If multiple views need to be specified they shall be separated by a comma; VIEW1,VIEW2,VIEW3.
Flags FndWindowRegistrationFlags.None - None, registers the window for security only.
FndWindowRegistrationFlags.HomePage - HomePage, register window as home page for specified VIEW. This makes this window the default navigation target for objects connected to this view, e.g. for zoom.
FndWindowRegistrationFlags.NoSecurity - NoSecurity, disable security checks (typically used for containers).
FndWindowRegistrationFlags.ModelessDialog - Modeless, register a dialog box as a modeless dialog.

Flag values can be combined using |, eg FndWindowRegistrationFlags.HomePage | FndWindowRegistrationFlags.NoSecurity

DefaultWindowText The default window text associated with the window. The Navigator will use this value as default node name. Zoom functionality uses this parameter to show the correct tooltip for the zooming object.
OverrideDefaultHome In a situation where there exists multiple windows that are registered as homepages for a view, setting this parameter will force this instance as the master. Value is true or false.
AssociatedHomepage This element specifies an alternative homepage for the window if needed. This value is not mandatory.

Security registration

Security registration is the most common registration that is done, and most windows in an application should be registered for security. This means that we specify a view or a list of views that a user needs granted access to. Without these grants there is no meaning to let the user open the window in the first place. E.g. the navigator will filter out windows that does not meet this basic permissions requirement for the user.

[FndWindowRegistration("DEMO_CUSTOMER", "DemoCustomer", "", FndWindowRegistrationFlags.None, false, None)]
public partial class frmDemoCustomer : cFormWindow

Figure 4: Simple registration where frmDemoCustomer registered to the DEMO_CUSTOMER view.

Register a Container tab form window as homepage

Normally when a window is registered as home page for a view, this view is also registered for security. This is only logical because if a window should act as home page for a specific view it is probably tightly designed around that view. An exception to this logic is the Container tab form window. This window type provides a series of windows in a tabbed container where each window is acting independently of each other. The container only acts as a logical grouping of interfaces towards the user.

In this example, the container tab form window frmDemoCustomerContainer contains frmDemoCustomer. We want to register the frmDemoCustomer tab as Home Page for the DEMO_CUSTOMER view. I.e. if the user zooms, we want frmDemoCustomerContainer to display the frmDemoCustomer tab, rather than launching a frmDemoCustomer form. To accomplish this, we register the container window as homepage for the DEMO_CUSTOMER view. Just registering the window for the view will make it part of the security registration for the container form, unless explicitly stated otherwise. This means, that if this view is not granted to an end user, the whole container window will be unavailable, even if other tabs should be available. We need to explicitly define the registration not to add to the security rules. Do this by adding the Flag NoSecuritiy.  

FndWindowRegistration("DEMO_CUSTOMER", "DemoCustomer", "", FndWindowRegistrationFlags.HomePage | FndWindowRegistrationFlags.NoSecurity, false, None)]
public partial class frmDemoCustomerContainer : cFormWindow

Figure 5: Container tab form window registered as homepage with the combination of flags HomePage | NoSecurity

Register dynamic tab pages

The FndDynamicTabPage attribute registers a form window, table window or dialog box to dynamically be added as a tab in another window.
This is typically useful when integrating windows with other modules. This way, one module can provide windows that are run dynamically in other modules if installed, but without static dependencies.

[FndDynamicTabPage(ParentObject, WindowVersion, TabTag, TabTitle, Ordinal)]
Element Description
ParentObject The cQuickTabs object to which the tab page should be added (for example frmWarehouseTaskManager.picTabs)
WindowVersion Tag the dynamic tab with a specific window version. Applications uses this parameter to enable / disable tabs in different application processes. Navigating to a container window with a specific window version will load only those dynamic tabs that have a matching WindowVersion tag. Note: This only applies to the dynamic tabs that have a version. Tabs with no window version set will always be available. Also if a container is navigated to with no specific window version set, all dynamic tabs will be enabled regardless of their version.
TabTag Tag used to identify the tab.
TabTitle Title used for the tab. This parameter should be a translatable constant.
Ordinal Specifies the ordinal number of the tab. This value specifies the position of the tab relative to others.
[FndDynamicTabPage("frmWarehouseTaskManager.picTab", " PICKREPORT", " frmPickReport ", "TAB_NAME_PickReport: Report Picking of Customer Order ", 0)]
public class frmDynamicDetails : cFormWindow
...

[FndDynamicTabPage("frmWarehouseTaskManager.picTab", "USERS", "frmUsers", "TAB_NAME_Users", 0)]
public class frmUsers : cFormWindow
...

[FndDynamicTabPage("frmWarehouseTaskManager.picTab", null, "frmAlways", "TAB_NAME_Always", 0)]
public class frmAlways : cFormWindow
...

Figure 6: WindowVersion examples

 In Figure 6 three forms are registered as dynamic tabs for the container form frmWarehouseTaskManager. Two of them have separate window versions set while the third have none. This is what will happen if we navigate to the container form with different window versions.
 

Register dynamic wizard pages

The FndWizardPage attribute registers a form window, table window or dialog to dynamically be added inside a wizard as an extra step.
This is typically useful when integrating windows with other modules. This way, one module can provide windows that are run dynamically in other modules if installed, but without static dependencies.

[FndWizardPage(ParentObject, Resource, Title)]
Element Description
ParentObject The wizard to add the form to
Resource The resource name to display as the picture with the form on the wizard. If no picture is needed, the value should be null.
Title Title to be used for the wizard step. This parameter should be a translatable constant.
[FndWizardPage("dlgChangeMultEmpAsignWiz", "", "NAV_TEXT_EmpSchedRec: Recalculate Transactions")]
public class frmWrkschRecalculate : cFormWindow

Figure 7: This example dynamically adds frmWrkschRecalculate to the dlgChangeMultEmpAsignWiz

Register Task Parameter Sheet

The TaskParameterSheetEntry element is used to register parameter sheets for the scheduled tasks dialog for a specific method.

[FndTaskParameterSheet(MethodName]
Element Description
MethodName The name of the method that the parameter sheet is assigned for.
[FndTaskParameterSheet("OUTSTANDING_SALES_ACCTING_API.CREATE_INTERIM_VOUCHER__")]
public class dlgPSheetCreateInterimVoucher : cDialogBox

Generate Dictionary

To be able to verify the registration you need to generate the dictionary.