About XFDef defintions

XML Attribute Definition (XADef) are used to define a dynamic form for the entry of Extensible Markup Language (XML) data. The XML Form Definitions (XFDefs) defines the style, order of parameters, and so on. The structure and value checking of the XML is defined by the XADef. The XFDef structure is designed to be simple, yet flexible and is based on XML.

An XML may have a default XFDef. This is specified similar to the XADef used as tag of the form <XFDef>.

The XFDef file has an element called XFDef_HEADER that defines attributes of the form and then multiple elements. The elements should represent the elements in the XADef. If only one element exists, then it is assumed to be a single form. If multiple elements exist then each element should have its own tab.

Example

<XFDef_HEADER>

Caption = “XFD Window”

Left=”100

Top=”10”

Width = “200”

Height = “100”

Startopposition=”cs” [optional] To center the XFDef window on the parent display.

</XFDef_HEADER>

The <XFDef_HEADER> is optional. If omitted, the size of the main window will be calculated based on the placement of child controls on the main window.

<Tag>

Tag or Attribute as per the XADef

The following are special tags or attributes. They can be defined as

<__XXX__> value </__XXX__>

__XXX__=”Value”

•	__LINE__—Line thickness in pixels

•	__TEXT__—Text value to display

•	__HEADING__—Heading value to display

•	__PICTURE__—Value could be an icon file on disk.

•	__LABEL__—Label value

•	__COMMAND__—Command Button. Attribute is Text:Key

•	__MATGRID__—This control is placed where this node name is defined and the attribute _TPD_ will be used to set the TPD file for loading the database.

The following tags or attributes can be associate to each.

•	_HEIGHT_—<default computed>

•	_LEFT_—<default computed>

•	_TABINDEX_—<default computed>

•	_TOP_—<default computed>

•	_WIDTH_—<default computed>

•	_BOLD_—Display in bold

•	_READONLY_—Do not allow editing

•	_VISIBLE_—Hide XML node

For each attribute, the program should generate the appropriate user control as follows:

If Bool Then Checkbox

If _VALIDATIONRULE_=_RANGE_

Use _LIST_==[##-##] As MinMax

Else If _VALIDATION_=_LIST_

Else List Box

Else If _LIST_ Then combo box

Else Text box

If constant Or __READONLY__ Then gray And Do Not allow editing.

Functions

Functions required are written at the end of the XFDef using character data (CDATA) as follows:

<![CDATA[

Function Help()

End Function

Function GoodNight()

End Function

]]>

</script>

Handling multiple nodes

MML is able to recognize multiple XML child nodes and is able to display values of each group one at a time. The MML prepropcessor will automatically look for multiple child nodes unless explicitly specified. In case of multiple groups, an entry field of each child node will be added to a list of a group combo box. Therefore, each entry in the combo box will determine which child node values should render the XFDef window. The following examples provide sample structures of XML child groups displaying different ways in which you could define multiple groups in an XML file.

In the sample below, the group combo box list will contain four entries for location, numbered sequentially. For example, the first entry on the list will be location – 1 followed by location – 2 and so on.

<shops>

</locations>

</shops>

In the sample below, the group combo box list will be filled using the values of the child node <name> in each location group. One thing to note about using the __KEY__ attriubte is that, the values for <name> in each child group should not be repeated. MML will warn if it finds a value of the node defined as the key is duplicated in any of the following child groups.

<name/>

</location>

<name/>

</location>

<name/>

</location>

</locations>

Each group combo box will have two buttons accompanying it, namely ‘Add New’ and ‘Remove’. Using these, it will be easy to add or remove new child groups into original XML files as well as to edit their values intuitively. To enable editing of groups, the XADEF has to be edited to include the ‘_EDIT_’ attribute for the group parent node with its value set to a Boolean value.

For example, adding the attribute “locations_EDIT_=’true’” within the locations node, allows the user to add or remove groups to the example shown above.

To define XFDEF and XADEF attributes for groups, it is only necessary to define them for the first in the group. Any special attributes defined elsewhere in the group will be ignored by the MML preprocessor.

With the new __FRAME__ tag provided for XFDef files, you will be able to put a frame on a group of controls to represents a division or a set of related input controls visually. This further enhances organizing of controls on the XFDef window. Until now, you had to resort to either ‘__TEXT__ or __HEADING__ tag to explain or subdivide data on screen. For example:

<__FRAME__ heading="General" id="X" height="0" width="0">

An explanation of the __FRAME__ attributes are as follows:

•	Heading—Title for the frame

•	ID—Unique number that is assigned to each frame

•	Height—Frame height

•	Width—Frame width

Attributes height and width are optional. If these attributes are omitted or their values are set to 0, MML will compute the required extent to enclose all the controls that fall within the frame.

The example below creates tabs for different sections. <__TAB__> must be the first tag after </XFD_HEADER>. The last tag must be </__TAB__> and for each tab boundary there should be a </__TAB__><__TAB__>. The value of the __TAB__ tag is the heading to be displayed in the TAB.

<__TAB__ Heading=”heading text”> …. </__TAB__>

Customizing the command bar

The command buttons, such as OK, Cancel, and Apply, are placed on the bottom of the MML main windows, called Command Bar. A special node named cmdBar could be created as a child node of <xfd_header> header node to manipulate the buttons placed on the command bar. The following XML structure shows how this can be achieved.

<xfdef_header

startupposition="cs"

caption="ColorTst"

left="100"

top="50"

width="600"

height="400">

</cmdBar>

</xfdef_header>

The cmdBar node can have two optional attributes, namely ingorecmdbar, which accepts any valid Boolean value and width, which accepts an integer value. Attribute Ignorecmdbar can be set to True to ignore the cmdBar completely from rendering on display, in which case the default command buttons OK and Cancel will be available. The width attribute sets the width of all the buttons defined within cmdBar node to the value specified.

Each child node within the cmdBar defines the type of control and its attributes further define properties of the command control to be created. Please note, MML only supports Button controls to be created and placed on the Command Bar section. The description of each attribute for command button is shown below.

Caption

•	Text placed as the title of the command button.

•

To set the accelerator key for each command button, so as to allow the user to press the command button using ALT + character, the accelerator character chosen should be enclosed in square brackets as shown in the above example. The character chosen will be underlined automatically and will act as the accelerator key when loaded on the MML window. If the same character is chosen for more than one command controls to act as the accelerator key, the default windows action being to rotate the focus among controls defined with the same accelerator is used.

Command

•

Can be any one of the predefined actions or user defined actions. Predefined actions are OK, CANCEL, APPLY, SAVE, and SAVE_AND_EXIT. The default actions bound to these commands are self explanatory, however, if the user wishes to have a custom command bound to any of the command controls, the value of the command attribute should be set by the user?. The question mark (?) denotes a unique ID followed by name ‘user’ to differentiate between multiple user action commands.

•

Each command control can have an optional attribute named ID to define a unique naming tag to help identify the control within script context. For example, if the user wishes to write script code that is to be executed each time the button is pressed, the ID attribute can be set to any user defined name and a function within the script body of the XFDef can act as the action to be executed. The following example shows how to bring up a message box each time User1 button is pressed as shown in the previous example.

<![CDATA[

Function user1_Onclick ()

msgbox "user1 id!"

End Function

]]>

</Script>

As you can see in the above example, the function name prefixed by “_OnClick()” should match with the value of ID attribute defined for the control ID in cmdBar node within <xfd_header> main XFD header node.

ListView look

The initial MML main window can be configured to include a ListView at the top of the window by modifying the <xfd_header> slightly. The ListView can be used as a navigator and therefore can be used to organize data much like how folders and files are organized on hard drive. The following example shows how to get the ListView look by configuring the XFD header.

<xfdef_header view_type="listview" caption="MML with (navigation ListView)" left="100" top="100" width="560" height="400">

<list_fields>

</list_fields>

<list_values OnDblClick="start.XML"

<windows icon="fldr" onDblClick="windows.XML"

xpath="//folders"

<win_dir0 icon="fldr" date="1/2/2005" ext="exe"/>

<win_dir1 icon="fldr" date="2/2/2005"/>

<win_dir2 icon="file" date="3/2/2005"/>

</windows>

</list_values>

</xfdef_header>

The contents of the ListView on the MML window, once loaded, is based on the structure of <List_values> child node of <xfdef_header>. By looking at its XML structure, the parent and child relationship of each node is determined and the folder/files relationship structure is created in the MML ListView. Each node within the List_Values node can act or look as a folder or a file simply by changing the attribute value of Icon to “Fldr” or “File” respectively. If an attribute named onDblClick is defined for a node within <List_Valus>, which points to a valid XML file, the MML window will render to its contents on that node/(Folder/File) being double clicked by user, thereby replacing the previous contents on main window. This is one way of loading different XML files within MML while keeping the main MML window visible between each transition. For each node within <List_Valus>, any other attributes can be defined to match the names of any headers defined within <List_Fields> node.

The new attribute introduced in <xfdef_header> named view_type, controls the desired look of MML. By default the listview look is disabled unless specified explicitly by adding the attribute with the value as shown in the sample above. Possible values for the view type can be listview or defaultview. If omitted, the default view is implied.