Interface Builder Documentation

2 Run the IB & IE-WEBS setup software to install on your local PC drive. This PC should have accessibility to the Internet for online registration of the software.

3 The IEG welcome logo will be displayed, press NEXT to continue

4 The InstallShield Welcome screen will be displayed, after reading press NEXT to continue.

5 A ReadMe window will be shown as a reminder of how you might wish to install this software.

6 The Destination Location gives you the opportunity to install the software into the default path or change the location to your choice. If IB is installed multiple times a unique Location should be entered now to differentiate one installation from another. This is approach is beneficial in handling multiple models on the same workstation.

7 The Program Folder gives your the opportunity to install the software into a default Windows folder or change the folder to a name of your choice.

8 The software installation will begin

9 You will be asked to complete a Registration Form and identify your Computer Name a for the IB IE-WEBS software. If you do not wish to complete this form you may EXIT the form and register at a later time.

For clients with an IB license the software can be installed on multiple workstations or on the same workstation multiple times. This may help facilitate working with several applications or versions of the same application. See Loading a Model for more on this topic.

At the completion of the software installation you will be able to view the README file and /or finish the InstallShield installation.

The default installation directory name is IEG\IB.

Under the IEG and IB folder are:

iewebs – contains the actual application Database

rep – contains the LDA repository for the IB application code

startup – contains various utilities supplied by IEG for IB

tpl – contains the IEG released template files

work – this is where you can location CASE model files. This is also where the iewebs-ini file will be created if it does not exist. This ini file contains information directing IB how to generate various features in the ASP forms. See Maintaining the INI for more information.

A new sub-folder will be automatically created and named based on the IB generated model names. For example, the model SAMPLE.MDL was located under WORK. IB will create and generated all of the ASP forms under the folder named SAMPLE.

IB will also create two other folders “env” and “img”.
env - will contain the generated routines for ActiveLINC.
img – will contain gifs used in the generation of drop down combo list boxes.

Destination Location:

Registration Form:

The registration form needs to be completed each time IB is installed or updated with a new release. This requires the PC on which IB is being installed to have internet access. A registration key is submitted to the IEG web site for verification and approval.

Installation Folder

The IEG Interface Builder installation folder consists of various ICONs to help in the administration of IB.

Ø Local IB Run Time – starts the local IB (EAD/LDA) Run Time session

Ø IB Help – invokes Internet explorer and navigates to the IB documentation web site

Ø HousKeeping – removes or clears various error and log files built by EAD/LDA Run Time

Ø IEWEB INI – the INI file used by IB. This is also maintained and explained by the Maintaining the INI File

Ø LdaWeb INI – the INI file used by IEG’s vIP Connector

Ø LICENSE – the license agreement for trial usage

Ø Readme – information regarding the current release changes

Ø Uninstall – uninstalls the IB folder and program files

IB Installation Folder:

Customizing the IB Run Time ICON:

You may customize the Run Time ICON by right clicking on the ICON and selecting properties.

To automatically start the IB session, add “IEWEBS” at the end of the target line.

Beginning an IB session

· IB is normally run locally by selecting the Local IB Run Time ICON

· Selecting File, Open Session

Creating a new IB Run Time database

· If you wish to create a new IB Run Time database you made do so by selecting File, Database Utilities, Create New Database

Ending the session

· End the session by selecting File, Close Session

Interface Builder software operations:

Loading an LCIF model

The F1 key while in EAD/LDA Run Time pops up field level HELP.

· The process begins by first creating an EAD/LDA model by extracting screens or selected screens from the EAD/LDA specification that you want to process using IEG’s Interface Builder.

· Place this model under the “WORK” directory of IEG/IB or a directory of your choice. It is recommended that a “WORK” directory be named and associated to each LINC specification. For example: PAYROLL might be where you locate the case file for your payroll specification. When working with several applications, it may be desirable to create folders for each application and place the model file under each respective folder. While only one model can be loaded at a time, the work environment will be ready to access any of these model. Another option for handling several model files would be to install IB into different folders (see Installation step 6 for more information).

· Upon opening a Session for the IB run time you are requested to locate the LCIF model you wish to load or, if already loaded, you are presented with a setup configuration form (CONFG)

· Verify the name of the model to be processed or use the LCIF Model Locator button to locate the LCIF model you wish to process

· Select from one of the three Generate Options.

· Press NEXT PAGE for more information on Generate Options.

LCIF Model Locator

Generate Options

There are three options to select from.

· Modify/Build GUI settings/model - This option is used when you wish to generate EAD/LDA GUI forms. If you already have GUI forms using this option will replace existing GUI forms when the output model is loaded into EAD/LDA.

· Build DHTML forms - This option is used to generate DHTML forms that are used with the IEG IE-WEBS product which allows EAD Test or LDA runtime applications to be accessible over the Internet.

· Build ASP forms - This option is used to generate ASP pages for use with Unisys Component Enabler/ActiveLINC to front end EAE/LINC applications.

· About IB – This option will display one message to document the current version of IB that you are using. A second message might appear after IB retrieves the latest version of IB from the IEG web site. If you are using the latest version, only one message will appear.

· After selecting the Generate Option, press the “CONTINUE” button and processing will process to the next form. If a new model has been identified, IB will scan and load that model otherwise information from the last scanned model will be used.

NOTE: IB will automatically detect when the model name changes, when a new version of the same model is located, or when the Generate Option changes between GUI and DHTML/ASP. If any of these situations are encountered, a background task will be initiated to scan the model.

Other options available on the CONFG form are:

· Maintain Style Sheets - this option will enable you to maintain style sheets associated with the ASP and DHTML forms. Making changes to the style sheets can impact your forms without having to rebuild all or selected ASP/DHTML forms.

· Maintain IEWEBS.INI - building ASP/DHTML forms has several options that you can customize as you wish. If the IEWEB.INIT does not exist or features are introduced in future IB releases, IB will guide you to the IEWEB INI maintenance form. The IEWEBS-INI file retains your options and is saved in the “WORK” directory where the LCIF model is placed. IN this manner the settings are associated to the LINC application. You will have a IEWEBS.INI file for each “WORK” directory.

Setting GUI standards:

GUI OPTIONS

This form allows the setting of display attributes such as font name, size, foreground and background colors for each ISPEC type that EAD/LDA permits (Component, Events, Memo, Tables, etc). There is a global default called ”IEG Default” that is applied to all ISPEC types unless a specific screen type has its own values.

· There are also some ISPEC level choices to define, such as how the MAINT field will be painted. Possible choices are as a Field, Push Button, List Box, or Combo Box. By default, the ADD, CHG, INQ, and DEL values are defined. Depending on the option setting for the ISPEC, the automatic logic values of FIR, LAS, BAC, NEX, and PUR are defined. Customizing of these values can be made on the GDAOP Data Item Options form.

· Not Entered fields can be painted with the attributes used for either Data fields or Inquiry fields.

· For further implementation, EAD/LDA will allow the setting of vertical and horizontal scroll bars.

Font name, size, and colors can be set for painted Display, Data, Inquiry, and Ordinate fields. If you double click on any of these four entries a pop window will be displayed allowing you to preview what this entry actually looks like. For example, double clicking on the ORDINATE will show that these setting are black on yellow.

By depressing the
“Change FaceName/PointSize” button the Font dialog window will open allowing changes the Font Name, Font style: regular, italics, bold, point size, and underline.

While this dialog shows the foreground color, the foreground color will not be changed using the Font dialog.

The “Change Foreground Color” and “Change Background Color” buttons will open a Color dialog window which you can select standard or custom colors.

Importing/Exporting GUI Settings:

After making changes to various colors and fonts you wish to revert back to square one, you can reload the IEG defaults GUI settings by pressing the “Load IEG Defaults”. A confirmation window will pop open asking for you to proceed or cancel.

You should select a location folder where you wish to write the Export file and enter the name of the file or you can over write and existing file by selecting an existing file name. The Export file will have the suffix of GUI.

To import an existing GUI file, press the “Import GUI Defaults” button. A confirmation window will ask if you wish to proceed. Importing will remove all prior GUI settings. If you proceed, the File dialog window will open allowing to import a previously export file.

Many of the other GUI screens have buttons to preview or change colors, font names , styles and sizes. They will open Color or Font dialog boxes as described above.

GUI Screen Options

This form allows the selection of a font name and size and a background color to be used as the default grid size and background color in EAD/LDA. Whenever a new ISPEC is painted these values are applied as the default attributes. As indicated on the form, these settings can impact the GRID size, which in turn can spread the lines and fields further apart both horizontally and vertically.

GUI Line Options

This form allows the setting of values for a given line (1-24), which is then applied to all ISPECS. Display attributes such as font name, size, and colors can be set for painted Display, Data, Inquiry, and Ordinate fields if any of these type of items are found on the selected line. These attributes override the ISPEC level and Data Item level attributes. This form is used to define HEADER and FOOTER attributes for the specified line, if the character mode screens were consistently painted.

Dictionary Value Logic

In a system with a Data Dictionary which has data items defined with Value Logic, the Value Logic can be used to determine the presentation type for those items. If the Data Dictionary with Value Logic is included in the model used for GUI generation, the data items which have Value Logic will be painted using that information. Items which have two Value Logic options will be constructed as either check boxes or radio buttons. Items which have more than two Value Logic options will be constructed as combo boxes.

Check boxes will be created for each of the following two value pairs: Y/N, YES/NO, Yes/No, ON/OFF, On/Off, T/F, TRUE/FALSE, True/False, ENABLE/DISABLE, and Enable/Disable. In addition, Check boxes will be created for OK or Ok and any other value above. Check boxes will also be created for any value and GLB.SPACES. All other value pairs will be created as radio buttons.

These automatic settings can be overridden by defining specific data item options as described below.

Data Item Options

GUI attributes can be defined for each specific data item painted on every ISPEC scanned. Presentation types such as push buttons, boxes (check, list, combo), or radio buttons can be assigned to a specific data field. In addition, font name, size, and colors can also be assigned to a specific data item. Once the GUI settings are defined for a data item level, they are applied wherever the item is painted. In other words, the GUI attributes are applied like a dictionary setting.

Short Explanation of the Command Buttons

ü Preview – Pressing the Preview button will pop-up a preview of how the data item field will appear.

ü Change FaceName or Colors – Select the desired button to maintain the Face Name, Point Size, Foreground Color, or Background Color for the highlighted selection.

ü MAINT – The Add, Change, Purge or Inquiry will maintain the selected data item

ü Navigation – The Return, GUI Opt, Line Opt, and Generate will proceed the form selected.

Short Explanation of each field

ü Data Item – This field will contain the name of the data item for which GUI settings are being selected. All data items visible in the system will appear in the Combo box for selection. Indicators will appear for data items which have settings and which have Dictionary Value Logic.

ü Attributes – An informational display window showing the current attributes or the default attributes applied to a selected Data Item.

ü Set Values from DCT Value Logic? – If a data item has Dictionary Value Logic, checking this box will tell the generator to retrieve the valid values from there instead of you entering the values.

ü Border - You may choose to place No Border, a 2 Dimensional Border, or a 3 Dimensional Border around this data item.

ü Presentation Type – This field allows you to select the format of the data item for which GUI settings are being chosen. By default, data items are assumed to be Fields.
Other choices are: Push Button, Radio Button, Check Box, List Box, Combo Box, and Image.

ü Layout – If the Presentation Type is a form of Button, this field will tell the generator whether it is to be painted Vertically or Horizontally if the button has multiple values.

ü Labels – This field allows for entry of the Labels associated with the valid Values. A comma should be placed after each entry.

ü Values – This field contains the valid values (or groups of values) for the selected data item. The format is dependent on the Presentation Type selected. e.g. If the field is a Check Box, you must enter both a Checked and an Unchecked value. A comma should be placed after each entry.

ü Radio Button/Check Box Label Position – This field tells the generator whether to position the labels defined for Radio Buttons or Check Boxes to the right or the left of the Button or Box.

ü List/Combo Boxes Contents – This field tells where the contents of a List box or Combo box are obtained. Valid choices are: Defined where the values are specifically provided in the Values field {above}, LBX or LBX*, where the values are supplied by a Send List command in the system, and File where the name of a file is provided which contains the table of values.

ü Files Name – This field will contain the name of the file containing Listbox or Combo box values if the Contents choice was File.

ü Show Lines – This field will tell the generator how many lines to use to display an open Listbox or Combo box. If no value is supplied, it will use a default value of 11 lines. If more

ü than 15 lines is entered, the generator will limit it to 15.

ü Style – This field works in conjunction with the Presentation Type field. When the Presentation Type is Combo, this field will determine whether the Combo is a Simple or Drop Down Combo or whether it is a Drop Down List box (which is defined as type Combo).

ü Validate – When checked, this field indicates that the validate values option should be set. When set for any Combo box, only values in the list will be accepted.

ü Image Resize – This field applies to a Presentation Type of Image. When checked, the image will be resized to the size drawn on the form. When not checked, the image will appear as its default size.

ü Width – This field tells the generator how many characters wide to make the image area. If a Presentation type of List box or Combo box was selected, it will do the same for the box.

ü Height – This field tells the generator how many lines tall to make the image area. For a List box or Combo box, this field will set the height of the box, if a value is not provided in the Show Lines field.

The Generation Process

· If the Refresh message appears in the display window (Figure 1) , press the SEND button in the upper right corner or double click either list box to fill in with data.

· ISPEC List - contains a list of all ISPECS found in the Model last scanned. To selectively generate forms, double click an entry and a “g” will appear indicating that this selection will be included when Generate Selected Forms is requested. Double clicking an entry already marked with a “g” toggles the selection and excludes this ISPEC from the Selected Generation List. (Figure 2)

· Action - Select which generation option you wish to request. “Generate All Objects” will generate forms for ALL ISPECs in the list regardless of whether they have been marked with a “g”. “Generate Selected ISPECS” will search for only those ISPECs that have been marked with the “g” selected generation flag.

· Highlight Action and Generate - based on the selections in ISPEC list and Action, IB will initiate the form generation for the GUI interface or the DHTML depending on the dynamic run time option selected on the CONFG form.

· Back to Previous form - this request will return you to the form you were on prior to coming to the Generate Output (LINK)

· Modify IEWEN INI - prior to generation if the user remembers something they would like to change in the IB generate options, they can navigate to the IBINI form and make changes to the IEWEB INI.

· “Generate Application AS” allows the user to specify a different title bar value to be generated for all forms. This only affects the displayed title bar value.

· “User Defined Application Value” allows the user to specify a 40 character documentation only string which will be generated into each form as a META tag

· The “Run Deploy Script” button allows the user to run some script, such as a bat file, associated with this application as defined on the IBINI form, or an alternative file name can be entered in the field located beneath the “RUN” button. Pressing this button will immediately initiate the specified script.

Figure 1

Figure 2

Maintaining Style Sheets:

Maintaining Style Sheets (IEGSS)

A Style sheet file (IEGCSS.HTM) is generated if you have set the “Include CSS scripts” option in your IEWEB INI. The user can define the file name if they wish to have different CSS files for each application. This file is automatically generated and contains CLASS names with attributes such as Font Names and Font Sizes, Foreground color, and Background colors. Changing these attributes in the deployed copy of the IEGCSS.HTM will impact forms that reference the same CLASS.

The IEGCSS.HTM file built by IB should never be changed. Makes changes only to a copy of this file.

Available options are:

Ø Import the CSS file – allows for the navigation to the CSS file you wish to load

Ø Export the CSS file – the CSS file can be written to a new file or replace an existing file

Ø Return to the MAIN menu

Ø Preview Selection – highlight a Class Name and see what this font, size, and colors really look like.

The purpose of this approach is to change selected attributes in the style sheets without having to generate new forms. Each presentation type (i.e. Display, Inquiry Fields, Display fields, Buttons, Check Boxes, Combo Boxes) when generated using IB is assigned to a CLASS NAME.

Previewing a selected ClassName attributes: Arial 14, ForeGround Color or Maroon and BackGround Color of Gray.

For example you might have painted Screen Titles as Arial, 14, Maroon foreground color, Gray background color. A Class name will be created with these attributes such as IEGINQUIRY0004. Using the Change buttons, the Font, PointSize, ForeGround or BackGround colors attributes can be changed.

Resulting in new font, size, foreground and background colors:

After exporting and implementing the new IEGCSS.HTM style sheet file, all changes made to the style sheet will be automatically applied without generating new ASP/DHTML forms.

This feature is particularly helpful if GUI painting standards have been applied to your application.

Maintaining the IEWEB INI

The INI file is where options or settings are saved that are applicable for your site or application(s). There are currently four (4) sections in the INI file. Each section is color coordinated. IEG will provide default values for fields that are required. These default values can be changed by the user.

When running the local IB run time F1 will display field level help. In IE-WEBS the field level help is displayed by hovering over the respective field.

After reviewing and making changes to the INI options, the user can select “Build New INI and Globals”. This option will save the INI file and generate new globals: global.asa, iegglb.inc, ieglib.js, etc. If no changes were made, the user can press “Update INI only” and they will be returned to the prior form.

Use the Option Page 2 to navigate
to the second IBINI form.

Page 1 of 2

Use the Option Page1 to navigate
to the second IBINI form.

Page 2 of 2

Section Blue contains options impacting how IB generates ASP/DHTML forms. There are two levels of impacting generated forms. “Interface Builder Setup” parameters and “Dynamic WEB Design” parameters.

“Interface Builder Setup” parameters

· IEWEB.DAT template name - IEWEB.DAT is a template of various HTML, VB and JavaScript. The user can modify this file, but IEG will from time to time release new versions of this template.

· HTML form name - TBD

· Template Path Name - this entry identifies where the various templates used by IB are located. IB can be installed more than once on the same PC. This path entry is used by the user to perhaps reference the same templates for all IB versions installed. It is recommended that this entry not be changed unless the user is using there own user defined templates.

· Ieglib.js.tpl - the name of the IEGLIB.JS.TPL template file

· Ieglib.js - the name of the java script file.

· Deployed IEGLIB.JS path - the directory where ASP forms will locate the ieglib.js file on the host Application Server (IIS)

· Iegglb.inc.tpl - the name of the IEGGLB.INC.TPL template file

· Iegglb.inc - the name of the server side scripts used in the INC file

· Deployed Path for iegglb.inc - the directory where the iegglb.inc file is found on the host Application Server (IIS)

· Bat file script to be initiated at the end of each “Generate” request.

· Generated FORM Suffix - A user defined suffix to be appended to the end of each ISPEC name. This allows the user to specify a suffix that can be excluded from Anti-Virus software. AV software can greatly impact generation times.

· Include CSS scripts - This controls whether the iegcss.htm file is generated and whether Class names are used in the generated ASP/DHTML forms. If checked Style Sheets will be included. Unchecked, style sheets will not be generated and the class attributes will be generated directly in the ASP/DHTML form.

· Iegcss.htm.tpl - the name of the CSS iegcss template style sheet file

· CSS Name – the default is IEGCSS.HTM however this can be changed to any value. If multiple applications are deployed under the same IIS package it is recommended this name be unique for each application.

· Deployed CSS path - the directory where ASP forms will locate the iegcss.htm file on the host Application Server (IIS)

· Deployed IMAGE path - the directory where ASP forms will locate IMAGES on the hosting Application Server (IIS)

· Image Suffix - select from the list provided. IMAGE files painted or dynamically named in LINC code will be modified to have this suffix.

· Browser IE+NS or IE – determines whether the generated forms will be compliant for Internet Explorer and Netscape 6 or just Internet Explorer

“Dynamic WEB Design” parameters

· IEG HEADER - The IEG Header includes a next form field, a Sign Off button, and a Send or submit button. Valid responses: No—do not include the IEG Header, Top—paint the IEG header at the top of the form, Bottom—paint the IEG header at the bottom of the form after the last user painted field, Hide—will will generate a red line at the top of the form which will expose the HEADER when the mouse hovers over this top border.

· Header Options: The Header bar can include all or none of the following standard features: NEXT FORM field a Submit button a Sign Off button and a Separator line. The dimensions of the Header Area can be user define.

· Page 2 Request – for ASP generation a page 2 field can be generated as part of the Header or initiated through a Function Key.

· Auto Tab can be defined and generated as part of the functionality of each form.

· TABS - IEG will calculate TAB order based on the layout of the character based form or if TAB values have been entered by the user on the painted GUI forms, then the user maintained tab order will be used.

· Generate Width/Height for “Displays” – for painted displays the width and height can be generated as an explicit attribute or an implied attribute. This has an impact on how the browser page displays and prints forms.

· Field Types/Titles- IB will generate hover text for all painted objects based on the Data name, the LINC DAD, the LINC description or field level GUI help text. Moving the mouse pointer over the respective painted object will display this hover text in a small pop up display box. Moving the mouse pointer automatically closes this pop-up.

· Convert Fields to 3D – For forms painted prior to 3D capabilities in EAD, this options allows for the generation of 3D data fields even though the form may have been painted as 2D. This includes the ability for the user to specify a Width and Height adjustment to be applied for fine tuning the generated 3D field.

· Navigation ISPEC 1 & 2 - Scripts are generated automatically by IB based on selected LINC attributes found in the LCIF model file. These scripts are executed at the local browser level and include tests for Required, Numeric etc. There are some fields defined within the application that control ISPEC flow. In order to bypass local browser editing, the user can specify two data names used for ISPEC navigation. When either of these data names are found painted on the generated form, IB dynamically includes additional scripts to test on the values entered or selected for these specific data items and skips local editing routines.

· Labeled Keisen Boxes – If a box is painted in EAD and the top border intersects a painted DISPLAY, then IB will generate the box as a labeled box. Various attributes can be specified to make these boxes stand out on the generated form.

· New Wallpaper – controls the background of the form and can be a customer RGB color, a color name or a external file such as a jpg file.

· Time Duration - This time interval is in seconds (it can be .5 for 1/2 second) and is the time allocated for the form to complete it’s transition.

· Transition Type - there are 24 difference ways for the form to be presented such as: circle out, wipe left. The transition is how the form is rendered in the browser. “None” is a valid selection.

Section Green contains environmental options (iegglb.inc)

· LSS Name - the default asp provided by IEG is DataToRatl.asp

Section Red contains environmental options (global.asa)

· Host Server name - The network name or IP number of the computer that host the RATL interface to the desired LINC system. Do not use special characters such as dashes, or slashes in naming this item.

· RATL View Name - The name of the view as declared to the RATL "listener" and used in the connection process from Active LINC to RATL. Do not use special characters such as dashes, or slashes in naming this item.

· Environment Name - The name of the Business Segment (COMS window name) in all upper case. Do not use special characters such as dashes, or slashes in naming this item.

· Package Prefix - The industry convention is "com.company" where company is your organization name with no special characters such as dashes and slashes.

· Application Name - The Host LINC application name in all lower case. Typically the same as the Business Segment name. Do not use special characters such as dashes, or slashes in naming this item.

· Bundle Name - The name of the bundle (group) of Ispecs generated by the ActiveLINC generator. Quite often "all" is the default value. This is case sensitive and must match case declared to the ActiveLINC generator.

· User Name - Name/Password to use as the signon if RATL has been configured to require a signon.

· Password - Name/Password to use as the signon if RATL has been configured to require a signon.

· Domain Name - For NT systems, the NT's domain name. Quite often a dot "." is used as a wild card indicating "current" domain.

· Session TimeOut - Timeout interval in minutes

· Sign off URL - This URL is use when the application user signs off the application and you want to navigate the user to some other URL address.

· Alternate FireUP ISPEC – If desired the user can specify an ISPEC that is different that the LINC fire up ISPEC to be the FORM rendered the first time the user opens a browser session to the application.

Section Black contains message handling options. IB pops up a window to display messages generated by locally generated JavaScripts and for messages received from the host. IEG has also implemented a special “format” for host originated messages., using the MESSAGE verb and it’s variations of syntax: ME; ERROR, ME; ATTENTION and ME; DataName. In the text string between ( ) is properly formatted, the result will be a painted data object will change colors in the browser and the text string will become hover text associated with that field. I.E. ME; ERROR (`CREDAMT` has been exceeded). When this message is issued from the host the field CREDAMT will turn colors and the string will become hover popup text. Colors can be selected from the list provided or the hex representation of the color can be entered such as #C0C0C0 for gray. The text is formatted with a backwards quote ` delimiting the data name.

· Local and Message DataName Background color - this is the color of fields when messages are generated by local edit scripts. For example if CUSTNO is a required field, if CUSTNO is left blank then that field will change to this color. The form is not submitted to the host until a non-blank entry is made in the required field. This will also be the back ground color for “formatted” messages received from the host when using the message dataname syntax.

· Message Error Background - This will be the back ground color for “formatted” messages received from the host when using the message error syntax.

· Message Attention Background - This will be the back ground color for “formatted” messages received from the host when using the message attention syntax.

· TEACH/HELP Background – this will be the background color for each TEACH/HELP screen generated. Buttons will be automatically generated at the bottom of each form, which has an associated TEACH/HELP screen. The button labels will be the name of the respective TEACH/HELP screen. When pressed, a new browser window will open displaying the TEACH/HELP screen text. If the buttons to display the TEACH/HELP screens are not desired, selecting a background color of black will omit the generation of TEACH/HELP screens.

· F-Key to display errors - A function key can be designated to pop up the most recent message dialog received from the host or generated by local scripts.

IB Templates:

Documentation is not publicly available at this time.

User Templates

For those with DHTML, JavaScript and VBScript knowledge, Interface Builder allows for the development and maintenance of user developed Java or VB scripts for form and data manipulation. As of the 3.08.20 release there are two different user templates. The user templates are never overwritten by new releases of IB and are therefore retained from one IB release to another or when generating new screens. They are used during each generation to insert custom user-defined functions, which can greatly expand the functionality beyond what the EAD painter can provide.

Where are user templates stored?
All user templates (both client and server side) are simple text files and are located in the same “work” folder where the model file was located. See “loading a Model” for the location of the MDL file.

The Client-Side The user template (IEWEB.USR) contains user written Java scripts called “chapters”. Chapters are related to selected ISPEC and data fields, by using field level business rules to contain strings that invoke the generation and calls of these routines. These routines are generated directly into the ASP/HTML form and can be invoked at various processing points: form rendering, form submission and error processing. This provides great flexibility in implementing features by using your own knowledge of the application. A significant advantage of the client side scripts is each routine is generated directly into the ASP/HTML form.

The Server-Side The user template (IEWEB.INC) contains user written VBScripts called “chapters”. Chapters are related to selected ISPEC and data fields, by using field level business rules to contain strings that invoke the generation and calls of these routines. These routines are generated into various INC files and are processed by the web server. Various customer INC files are associated with various processing points during the building of the output ASP/HTML form. A significant advantage of the server side scripts is server scripts are deployed to the web server and filter each ASP/HTML form dynamically modifying the form, as it is processed by the web server. This means that changes to the ASP/HTML forms can be applied without generating a new ASP form but rather by simply deploying a new INC routine.

The Client-Side template

Within the IB IEWEB.DAT template there are entry points which are locations where user written scripts will be inserted. Currently those entry points are in the closing chapter (98) of IEWEB.DAT. User scripts can be inserted in the functions: ParseErrors()-for user error handling, prescreen ()-for processing prior to rendering the form in the browser and prelinc ()- prior to submitting the form to the host and one prior to the edit checking in prelinc().

Expanded Host Integration:

In addition to the entry points, users can use painted display images in LDA to invoke user chapters. The display image’s position and sizing can be used in the user chapter to position ICONs, buttons or any other GUI object. The capabilities of this feature are best illustrated by the following examples:

· Open a calendar ICON to allow the user to point and click on the day, month and year from a calendar image. Upon selecting the appropriate day the date string would be populated into the data entry date field painted on the form with the proper date format.

· Documentation written and maintained using MS WORD or other word processors could be assessed and presented in the browser by adding a documentation ICON to the form that could open another window or open a pop-up window with this documentation.

· Data sent to the browser via a list box can be rendered in the browser as lines of text. Instead of scrolling the list box to see the list box data, the user would scroll the browser page.

· The LINC ISPEC could open web pages or html forms developed by other departments. Data could be selected from these new pages to be placed in one or many fields on the original LINC form.

· Data rendered in a list box could be written into a new browser window thus making it a more PRINTER friendly form for the user to print from their own browser to their attached printer.

Illustrations:

The following illustrates how a user-developed script could identify and manipulate date fields. It is common for date fields to be various lengths and date formats. Other than the LINC attribute EDIT=D, fields that are date oriented usually cannot be determined without close examination of LINC logic. In order to make it easier for an end-user to enter a date field correctly, it has been requested that the user be able to pop open a calendar from which they can select a specific day. This would in turn populate a designated field in the correct date format.

The LINC ISPEC before painting a Display Image:

A data field named “INDATE2” is defined as ED=N LE=8 and contains date information in the format of CCYYMMDD. This example could be for any field, with any edit attributes, representing any date format.

A Display Image is painted next to the INDATE2 field.

The name of the image is DATEADV.USR. IB detects an image that ends in a suffix of USR. IB will match this name against entries found in the ieweb.usr template. When a match is found IB will generate html or java code based on the routine developed and saved in the user template. Any ISPEC/data field can use this routine.

The following entry is entered in the User Template. Indented lines indicate text that is continued from the line above. In the Template these lines would be single lines of text. IB will match the name of the image DATEADV against the entries found in the ieweb.usr template. The next token in the user template is INDATE2 and it associates this image with the data item defined in the ISPEC. The date format is included indicating that this routine will return the date string as CCYYMMDD. ^dt^ is the user designated chapter ID that will be generated into the resulting ASP/HTML form. The text after the last “^” is user information that will appear as pop-up help text as the mouse is hovered over the calendar ICON.

The User Generation String:

00 N^DATEADV^INDATE2^ ^ ^CCYYMMDD^dt^ ^Clicking the calendar will populate the date field according to the date format specified. The following formats are supported:<br>MMDDYY DDMMYY YYMMDD CCYYMMDD MMDDCCYY DDMMCCYY

dt Y<img align=middle alt="Open Calendar ^VA^" src="^IM^calendar.gif"

dtiTLB /= SPACES

dtiY onmouseover="setPopUp('^DN^div', 'visible');" onmouseout="setPopUp('^DN^div', 'hidden');"

dtiTendtest

dt YonClick="document.IEGIspec.^DN^.value = DateConvert('^DN^','^VA^',document.IEGIspec.^DN^.value )"; style="left:^PL^; top:^PT^; width:^PW^; height:^PH^;">

dtiTLB /= SPACES

dtiY<div id="^DN^div" style="left:^2L^; top:^2T^; visibility:hidden; z-index: 99; ">

dtiY <table width="^2W^" height="^2H^" border="2" cellpadding="4" cellspacing="0" bordercolor="#009900" bordercolorlight="#99FF99" bordercolordark="#008000" bgcolor="#CCFFCC">

dtiN <tr><td><span style="left:5; top:5; font-size:12px font-family:Comic Sans MS; color:#008000; background-color:#CCFFCC; ">

dtiY ^LB^

dtiN </span></td></tr></table>

dtiN</div>

dtiTendtest

99 N

The line that starts with “00” represents chapter 00 and this is the record that associates the user written scripts in chapter “dt” and the painted display image name DATEADV.USR. Lines that start with “dt” are the date chapter. This chapter paints an ICON with an image named “calendar.gif”, creates a pop-up only if there is text following the last “^” , and populates the INDATE2 field with the results returned from the DateConvert function.

Once this chapter is written other Chapter 00 lines can call this routine and be associated with any number of Ispec/data combos.

Generation String format:

00 N ^<ispec or function name>^<dataname>^lengthvalue^<one of the 4 entry points or blank>^<user variable>^<chapter-ID>^<language #>^<misc text>

“^” is the delimiter separating field information. Each delimiter ^ must be separated by a character string or at least one single space. The generation string should never have two delimiters together (^^).

The generation string is retained in the IEWEB.USR template file.

· All declared generation strings in the IEWEB.USR template must start with chapter 00.

· Column 3 is blank or can have the letter [c,C], which denotes this line is a comment and is not included in the processing.

· Column 4 must be the letter “N”.

· If the data item is painted in a copyfrom area, you will have to declare each item and name it according to the naming string in the html, that means the item name would be something like DATAITEM__AT_01....etc. and you will have to declare each one.

· an Ispec = ***** means these rules to this data item in all ispecs.

· If a data item has an explicit ISPEC and ***** the explicit ISPEC rules is applied to the specific ispec and everywhere else the ***** applies.

· The length parameter is a value up to 4 digits in size and is the length of the field.

The following formatting rules apply to the generation string regardless of where it is declared:

· The ispec, dataname, call location will all be converted to Upper Case. Dashes (-) will be converted to underscores(_)

· There must be a space or character separating each ^.. YOU can not have ^^.

· The User Chapter is case sensitive, must start with an alpha character.

Illustration of building the User Generation String:

The illustration builds the generation string with an explanation of each item as it is added.

00 N - All generation strings will start with this. If a “c” is in the third column then this line is a comment and is skipped during generation.

00 N^DATEADV^ - The Ispec or function name has now been added. In this case this represents the function name. DATEADV was entered as the Display Image File name along with “.USR” in the EAD painter. The image name is compared against the user generation string for a match and when found triggers the association of this display image with this function.

00 N^DATEADV^INDATE2^ - The data item named INDATE2 has now been added. The DATEADV function will now target this data name as the field to store the result of this function. If the ^DN^ token is used as a wild card in the chapter script it will be replaced with INDATE2.

00 N^DATEADV^INDATE2^ ^ ^ - The next two tokens following the data name are empty. They are the length, which is not used in the function and entry point, which is also not used by this function.

The entry point can be one of the following values:

PS – function CALL is inserted in PreScreen or when the form is rendered to the browser.
PL – function CALL is inserted in PreLinc or when the form is being submitted to the host
PX – function all inserted in PreLinc prior to field editing routines.
PE – function CALL is inserted in the Parse Error routine that handles local and host generated error messages.
UF – function CALL is inserted in the outer layer of the form and is used with the special IEG feature that converts a list box display text and instead of showing a list box it displays the text lines in the browser.
TA – to combines fields together into a text area.
Blank

00 N^DATEADV^INDATE2^ ^ ^CCYYMMDD^ - The next token is the ^VA^ user variable. In this date function this represents the data format of the field INDATE2. Since this is a date routine the typical data formats that might be specified here are CCYYMMDD, MMDDCCYY, DDMMCCYY, YYMMDD, MMDDYY and DDMMYY. This represents the 6 and 8 character US and European date formats. The date function will use this format and return a value to be stored in INDATE2 that matches this format.

00 N^DATEADV^INDATE2^ ^ ^CCYYMMDD^dt^ - The next token is the user chapter “dt”. This can be and two alpha character strings (Aa –Zz) and 0-9 as long as it begins alpha character. This ID is case sensitive. The chapter “AA” will be different than “aa”.

00 N^DATEADV^INDATE2^ ^ ^CCYYMMDD^dt^ ^ - The language slot has now been added and is empty. Since the a Display Image is actually painted in the EAD painter, it is already associated with a specific ISPEC language version so there is no need to specify the language number again.

Finally the last part of the user generation string has been added. “Clicking the calendar…” is help text that will appear in a pop-up window as the user mouses over the ICON. This window will automatically open and close by the movement of the mouse.

Chapter Naming:

The value of “dt” has no special significance other than they represent a unique chapter in the IEWEB.USR template. If the user wishes to declare global variables or other Java functions, the chapter “gl” (GL in lower case) is required. The “gl” chapter is for user-defined global variables and functions. Chapter IDs must start with an ALPHA character and cannot be a chapter defined in the IEG standard template, IEWEB.DAT, or the “gl” chapter,

In the template IEWEB.USR:

glcN user declared global variables and Java functions

gl N<script language="JavaScript">

glcN add more variables or Java functions here

gl Nvar iegDate = new Date();

gl N</script>

99 N

What tokens are available?

DN – the selected data field name (FORMDATE)

FL – the define length of the field (0008)

ET – the Entry type (PL, PS, PE)

VA – a user defined value (MMDDCCYY)

LB – misc. text after the last “^”

What gets generated?

The results of this User DATEADV function:

To handle another date field the steps are very simple and as follows:

1) Paint the display image in EAD painter and name the image DATEADV.USR

2) In the user template duplicate the user generation string and change INDATE2 to the name of the other field, i.e. DATEOUT

Once generation strings are built, generation of the ASP form will always include these additional expand integration functions.

The Server-Side template

Within the IB IEWEB.DAT template there are various ASP calls to subroutines defined in the IEGGLB.INC file. These subroutines can be expanded to include additional user written functions. There are currently 6 points where calls are made to IEGGLB.INC subroutines. There is one additional place within the IEGGLB.INC template for generic Subroutine or Functions to be appended with existing INC Subroutines and Functions. This can be dynamically expanded to as many as 30 calls. The initial seven points are listed along with their associated Tokens :

<% IEGGen_JS_Var_Section_Head %> ^INCJSV^

<% IEGGen_JS_Function %> ^INCJS^

<% IEGGen_Extra_Fields %> ^INCEXT^

<% IEGGen_PL %> ^INCPL^

<% IEGGen_PS %> ^INCPS^

<% IEGGen_End_Of_PS %> ^INCEPS^

and … the outer INC level ^INCOUT^

To start the process the client uses Notepad or WordPad to define and maintain a text file named IEWEB.INC and saves this file in the same folder where the loaded model was located. This file will contain generation strings and user chapters which, when combined together during the IB generation process, produce custom INC files to be deployed on the web server.

The First Step:

The first step in implementing the custom INC routines is to define tokens for each of the seven call points. Note that not all of the tokens have to be defined, but if a routine is desired at a given location that token must be defined. There are two methods that can be used to define these tokens. Each method starts by declaring a token definition record. These token definition records always start with “00 N”.

Defining Tokens:

The simplest way to define these tokens is to use the defaults. Default definition records would look like the following. Note that the spacing between ^ is not critical however each ^ must be separated by at least one space. In the record the 4th location contains the token value as defined in the IEGGLB.INC.

METHOD ONE

01aN Sub IEGGen_JS_Var_Section_Head

01aN%>

01aY^INCJSV^

01aN<%

01aN End Sub

Code found in IEGGLB.INC.TPL

Corresponding “TOKEN” value

Record position: 1 2 3 4 5 6 7 8

Contents of IEWEB.INC: 00 N^ ^ ^ ^INCPS ^ ^ ^ ^

00 N^ ^ ^ ^INCPL ^ ^ ^ ^

00 N^ ^ ^ ^INCJSV ^ ^ ^ ^

00 N^ ^ ^ ^INCEXT ^ ^ ^ ^

00 N^ ^ ^ ^INCJS ^ ^ ^ ^

00 N^ ^ ^ ^INCOUT ^ ^ ^ ^

00 N^ ^ ^ ^INCEPS ^ ^ ^ ^

The result will be code generated into iegglb.inc of: …

… and the creation of a file named INCJSV.INC deployed in the same folder as IEGGLB.INC .

METHOD TWO

This method permits the explicit declaration of file names and INC strings as desired and defined by the client. The IEWEB.inc file would contain:

1 2 3 4 5 6 7 8

00cN^ ^MyJSV.inc^ ^INCJSV^^ ^ ^

Record position:

1=empty

2=name of the external file to be created. This must match the value in position 5

3=empty

4=the token identifier. One of the seven tokens

5=the INC string used to replace the token found in iegglb.inc.

6=empty

7=empty

8=empty

The result will be code generated into iegglb.inc of: …

… and the creation of a file named MYJSV.INC deployed in the same folder as IEGGLB.INC .

It is possible that the ieweb.inc file would contain nothing more than the token definition records. The result would be generating IEGGLB.inc with custom INCLUDE strings. A knowledgeable VBScript developer could do the creation and maintenance of the actual custom INC files manually.

Generating INC routines with user changes:

To generate new INC routines (including
iegglb.inc) navigate to “Modify IEWEB.INI file”
and press the ”Build new INI and Globals” button.
All new INC files will be generated in the
ENV folder.

If you generate new ASP forms, new Global INC routines will be generated only if the iegglb.inc does not exist in the ENV folder.

Letting IB generate the contents of each custom INC file:

Creating custom INC files will be illustrated with the following example ASP forms. The purpose
of the customization is to change the
style of selected buttons on the form to
look more like WEB Links instead of a
standard push button.

The image to the right illustrates the
form before generating and deplobying
new INC files.

Two approaches will be discussed on
how this change was made. The
purpose of this illustration is simply to
show by example how the server side
INC files can produce the desire form
changes.

The next image shows the same form
after the new INC files were deployed
on the web server.

Illustration A:

The initial form was generated using the
CSS style sheets. So the initial planning
step would be to examine the generated
ASP source to determine which CLASS
is associated with the menu buttons.
That class was determined to be
“IEGPBUTTON0002”.

The task now will be to build custom
INC files to modify the CLASS
IEGPBUTTON0002 style attributes
to a web look and feel. The first
approach will be to insert a CLASS
definition with the desired style attributes to make all buttons associated with IEGPBUTTON0002 to look like a web link.

An ieweb.inc file with the following contents will produce the above results. Some lines may be wrapped for readability.

00 N^   ^incEXT.inc ^ ^INCEXT ^^ ^ ^

00 N^*****^globalitems ^ ^INCEXT   ^ ^GL ^ ^

00 N^*****^IEGPBUTTON0002 ^ ^INCEXT   ^ ^nc ^ ^

nccN another way to manipulate CLASSes

nc N

nc N<%

nc Yif (IspecName = "^IS^") or ("^IS^" = "*****") then

nc Yif (IEGLang = "" ) or ("" = "^LB^") or (IEGLang = "^LB^") then

nccN Condition the response write with the correct ISPEC and LANGUAGE

nc N response.write("<style>   " & vbcrlf)

nc Y response.write(".^DN^ {font-family:VERDANA; font-size:9; color:#0000FF; background-color:transparent; text-decoration:underline; border:0; cursor:hand;} " & vbcrlf)

nc N response.write("</style>   " & vbcrlf)

nc Nend if

nc Nend if

nc N%>

99 N

GLcN defining dims

GL N<%

GL Ndim IEGLang

GL Ndim LocalLangs

GL Ndim IspecName

GL Ndim i

GL NLocalLangs = Session("LangNames")

GL NIEGLang = Trim(UCase(objCurrentIspec.getFieldValue("IEGVIEW")))

GL NIf IEGLang = "" then IEGLang = LocalLangs(0) ' where we want to go '16

GL NIspecName = trim(objCurrentIspec.getName())

GL N%>

99 N

A

Explanation:

The “A” record is the token definition record. IB will use the INCEXT location within the IEGGLB.INC and will insert the INCLUDE statement to include the file named INCEXT.INC. (Note the case of the file name does not matter).

The “B” records define what is to be generated and with what parameters. A global chapter is requested as defined by the “GL” chapter. The first 00 record (globalitems) causes IB to generate, into the INCEXT file, some global variables (dim) which are set by the ASP code to define the ISPEC and Language being processed by the web server. The second 00 record inserts the user chapter “nc” which is the routine that modifies the form and inserts a new CLASS definition for the IEGPBUTTON0002 with the desired style attributes. By locally defining this CLASS in the ASP form, the local style attributes override those declared in the CSS file.

The results:

The iegglb.inc will have the following code generated:

Sub IEGGen_Extra_fields

' Example to tell external app where user was in form:

response.write "<input type='hidden' name='XFOCUS' value=''>" & vbcrlf

%>



<%

End Sub

The INCEXT.INC file will have the following code.

<%

dim IEGLang

dim LocalLangs

dim IspecName

dim i

LocalLangs = Session("LangNames")

IEGLang = Trim(UCase(objCurrentIspec.getFieldValue("IEGVIEW")))

If IEGLang = "" then IEGLang = LocalLangs(0)

IspecName = trim(objCurrentIspec.getName())

%>

<%

if (IspecName = "*****") or ("*****" = "*****") then

if (IEGLang = "" ) or ("" = "") or (IEGLang = "") then

response.write("<style> " & vbcrlf)

response.write(".IEGPBUTTON0002 {font-family:VERDANA; font-size:9; color:#00aa00; background-color:transparent; text-decoration:underline; border:0; cursor:hand; IEGtype:52;} " & vbcrlf)

response.write("</style> " & vbcrlf)

end if

end if

%>

The web server will dynamically insert the following line in the ASP/HTML form. (Note line 2 is broke into 2 lines for readability.)

<style>

.IEGPBUTTON0002 {font-family:VERDANA; font-size:9; color:#0000FF; background-color:transparent;
text-decoration:underline; border:0; cursor:hand;}

</style>

Illustration B:

The initial form was generated WITHOUT using the CSS style sheets. So the initial planning step would be to identify the field, which is painted as push buttons. That field name is NEXTPAGE.

The task now will be to build custom INC files to modify the style attributes for the field NEXTPAGE to a web look and feel. This approach will be to insert a JavaScript to change style attributes for all push buttons generated for the NEXTPAGE object.

The IEWEB.INC will contain the following token definition records:

00 N^ ^incOUT.inc ^ ^INCOUT ^^ ^ ^

00 N^ ^end_of_ps.inc ^ ^INCEPS ^^ ^ ^

This approach will generate iegglb.inc and two additional INC files: INCOUT.INC and END_OF_PS.INC. Next we add three additional “00” records to define what will be generated: chapters GL, x1 in END_OF_PS.INC and chapter CS in INCOUT.INC.

00 N^pg000^globalitems ^ ^INCEPS   ^ ^GL ^ ^

00 N^pg000^NEXTPAGE    ^ ^INCEPS   ^ ^x1 ^ ^

00 N^pg000^NEXTPAGE    ^ ^INCOUT   ^ ^CS ^ ^

Finally the iweb.inc file will contain the customized chapter to complete the objective of turning a specified field (NEXTPAGE) from a push button style to a look and feel of a web link.

x1cN When we have the correct form, generate a call to a ChangeStyle routine in INCOUT.inc

x1 N<%

x1 Yif (IspecName = "^IS^") or ("^IS^" = "*****") then

x1 Yif (IEGLang = "" ) or ("" = "^LB^") or (IEGLang = "^LB^") then

x1cN I have now condition the response write with the correct ISPEC and LANGUAGE

x1 Y   ChangeStyle ("^DN^")

x1 Nend if

x1 Nend if

x1 N%>

99 N

GLcN defining a few dims to set ISPEC name and Language of this form

GL N<%

GL Ndim IEGLang

GL Ndim LocalLangs

GL Ndim IspecName

GL Ndim i

GL NLocalLangs = Session("LangNames")

GL NIEGLang = Trim(UCase(objCurrentIspec.getFieldValue("IEGVIEW")))

GL NIf IEGLang = "" then IEGLang = LocalLangs(0)

GL NIspecName = trim(objCurrentIspec.getName())

GL N%>

99 N

CScN generate ChangeStyle subroutine in INCOUT.INC and pass the field name into the subroutine. Check for number of push buttons and change style for each push button associated with the targeted field.

CS N<%

CS Ndim MyTarget

CS NSub ChangeStyle (MyTarget)

CS Yresponse.write("var MyTarget = '" & MyTarget & "';" & vbcrlf)

CS Yresponse.write("for (x=0; x<document.all.tags('input').length;x++) { // from INC" & objLINC.GetLanguage() & vbcrlf)

CS Yresponse.write("if ( (document.all.tags('input').item(x).type=='button') && (MyTarget == document.all.tags('input').item(x).name.substr(0,MyTarget.length) ) ) {" & vbcrlf)

CS Nresponse.write(" document.all.tags('input').item(x).style.fontFamily='VERDANA';" & vbcrlf)

CS Nresponse.write(" document.all.tags('input').item(x).style.fontSize='9';" & vbcrlf)

CS Nresponse.write(" document.all.tags('input').item(x).style.color='#0000FF';" & vbcrlf)

CS Nresponse.write(" document.all.tags('input').item(x).style.backgroundColor='transparent';" & vbcrlf)

CS Nresponse.write(" document.all.tags('input').item(x).style.textDecoration='underline';" & vbcrlf)

CS Nresponse.write(" document.all.tags('input').item(x).style.border='0';" & vbcrlf)

CS Nresponse.write(" document.all.tags('input').item(x).style.cursor='hand';" & vbcrlf)

CS Nresponse.write("    } // if" & vbcrlf)

CS Nresponse.write(" } // for" & vbcrlf)

CS Nend Sub

CS N%>

99 N

Illustration A and B produce the same results. The difference between illustrations is that in illustration B, the generated ASP did not have a CSS file so the selected field’s style attributes had to be explicitly changed by inserting JavaScript into the ASP form which, when executed, changes style attributes during the prescreen function of the form.

Special Features

IB can be directed to generate special features based on the presence of selected information found within the LCIF Model. These features do not require any additional html or java script coding. They are available as part of the standard IB capabilities. These features currently are:

TEXT AREAs

LIST BOXES displayed as lines of text

Hot Keys

Special Feature: TEXT AREA

TEXTAREAS can be viewed as a combination of several fields appearing as one single data entry area. There are occasions where an LDA form may have several similar fields (i.e. LINE01, LINE02, LINE03) defined. These may be for the entry of comments or notes. For ASP and DHTML forms, it is more desirable to combine these fields into a single text area where the user can type up to the maximum number of characters without having to “TAB” between each individual LINE.

painted as Individual Fields

IB allows for the generation of this TEXT AREA feature. To trigger the text area generation, you will need to add special lines to a user maintained “User Template” named “ieweb.usr” which is located in the “work” folder (see “Loading a Model” for information about the “work” folder). The following entries are for an ISPEC named NOTES on which there are 6 note lines (note1 – note6) each LE=50 ED=A.

For each of the Note Lines, we add a special line in the user template:

00cN next 6 lines combine three lines in to two text areas

00 N^notes^note1 ^50^ta^ GRP1^01^

00 N^notes^note2 ^50^ta^ GRP1^02^

00 N^notes^note3 ^50^ta^ GRP1^03^

00 N^notes^note4 ^50^ta^ GRP2^01^

00 N^notes^note5 ^50^ta^ GRP2^02^

00 N^notes^note6 ^50^ta^ GRP2^03^

This instructs IB how to generate the relationship between the fields and the associated internal text area group. The results are NOTE1, NOTE2, and NOTE3 are combined into one text area called internally “GRP1” and NOTE4, NOTE5, and NOTE6 are combined into a second text area called internally “GRP2”. The name of the group is user defined. The trailing number controls the order of which field goes into what part of the text area. The total length of the text area will be the sum of the length of each part. If the user enters more data than can be handled, a local error is generated informing the user what the maximum length can be and by how much this limit has been exceeded.

generated as Text Areas

While the entry of data into the text area is more “windows” like and user friendly, the application may require some minor modifications to handle the possibility of the user using the “RETURN” key to position to the next line. The “RETURN” key is converted to a “ ` ” when sent to the application. The application can then parse for this character and format the data if desired.

Three lines of notes are combined in to one text area and another 3 lines of notes are combined into a second text area. Could all six lines have been combined into a single text area? Yes, all six lines of notes could be combined into a single text area by defining the following information in Chapter 00 of the user template.

00 N^notes^note1 ^50^ta^expnotes^01^

00 N^notes^note2 ^50^ta^expnotes^02^

00 N^notes^note3 ^50^ta^expnotes^03^

00 N^notes^note4 ^50^ta^expnotes^04^

00 N^notes^note5 ^50^ta^expnotes^05^

00 N^notes^note6 ^50^ta^oexpotes^06^

Special Feature: LIST BOXes shown as display lines

IEG offers an alternative means to view data rendered inside list boxes. Instead of scrolling with in the list box, the data lines can be displayed as lines of text or display lines in the browser. For some situations this makes for easier reading. If it is expected that the user might want to print the web page this technique makes for a more printer friendly format.

For each ISPEC/List Box only the following line needs to be added to the User Template:

00 N^STRAC^FEATURE ^20^UF^ ^75^01^

where … STRAC is the ISPEC name,

FEATURE is the painted list box that has been selected to display as lines of text.

20 is the length of FEATURE

UF is the entry point

75 is the chapter to convert list boxes to display lines supplied by IEG

01 is the primary language number

This approach can be modified to enable even more features. As in the case of LIST BOXes data can be selected in the list box and sent into the application.

The feature above can be expanded to select a specific line that is returned to the application. The list box is made up of a left side (typically sent to the application) and the right side (typically shown).

Since the list box has this information, the routine can be expanded to paint a button next to the line of text.

Special Feature: Hot Keys

Forms (ISPECs) can be designed so when a browser user presses the “Alt” key in combination with another key, the cursor jumps to a particular field on the form. The key is called a ‘hot key.’ The field can be any element capable of receiving ‘focus’ in HTML parlance. These include visible data entry, buttons and boxes. They exclude anything not visible or declared as NOE in EAD/LDA (this would produce a Java script error).

To make a field capable of being the target of a hot key, the field must have a tab number defined for it in EAD/LDA. Then a Display (label) is given a non-zero “associated tab #” that has an ‘&’ (ampersand) directly in front of the ‘hot key’. The ampersand will be stripped from the Display, and IB will automatically build the necessary script to sense the hot key and jump the cursor to the data entry field. No two fields can have the same hot key on the same form.

Note that the Display could be painted with the same foreground and background color to make the Display not visible to the user. For example, a site standard might be that “alt-z” always takes the user to the final field on the form; thus, you would not need or want any screen real estate for a label.

Also note that some letters are poor choices for hot keys, as the browser reserves them. For Internet Explorer, these are a, e, f, h, t, v, left- and right-arrows. For Netscape, these are b, c, e, f, g, h, v, left- and right-arrow.

(More information on IEWEB.USR is found in the “User Template” listing in the table of contents).

Known Limitations and Differences in Operations:

1. If your logic executes a RECALL; (BYE) all users will be knocked off the system if you are using the IE-WEBS product.

2. Browsers can not auto tab. Auto tabbing is when the field is full and the cursor automatically advances to then next field. See the IBINI Dynamic WEB Design section for this feature.

3. The drop down combo does not close when a value is selected. Clicking any where else on the form or tabbing out of the combo drop down list box will close the list box.

4. Observe the following restrictions:

· No squiggles (~) in anything painted (displays, defined list boxes, DADs, DESCs, field level help).

· No double-quotes in radio button labels, field data or field level help, returned (from host) list box data, text area data.

· No backward apostrophes in text area data in the database.

· No greater than signs (>) in returned list box data.

· Do not paint data items on the screen having any of these names:
IEGSEND, NISPEC, ACTION, SEGMENT, HOST, SUBMIT, NONE

· For list and combo boxes, only one column can be sent to host.

· No greater than or less than signs (< >) in anything painted (displays, defined list boxes, DADs, DESCs, field level help).

5. No push (command) buttons called SUBMIT or having that value returned, no list boxes called “NONE”, and no special characters in the Business Segment Description such as ampersand (&).

6. For any form that has multiple command buttons there is a risk when the browser BACK button is used or if host generates an ERROR message. Field values are retained as when the form was submitted, when the BACK or host error messages are encountered. If the user now selects some other command button, the form gets submitted as if two buttons were selected. The button originally selected and the last button selected will both have their values set. This situation gets resolve when the form is rendered (RECALLed or REFRESHed) from the host. IEG has also provided a means to solve this situation using the user template feature in IB to identify and initialize selected buttons on error messages from the host or if the browser BACK button is used.

Browser Differences

ü Code to detect which browser is being used by the end-user. Add the following on chapter 01 before the message variables. var ns4 will be true if NETSCAPE and var ie4 will be true for Internet Explorer. Adding the following will enable the ALT keys to begin functioning correctly in NS.

var Ver4

var nsFactor = 6 // pixel facter to be subtracted from IE height and width

Ver4 = parseInt(navigator.appVersion) >= 4

ns4 = ((navigator.appName == "Netscape") && Ver4)

ie4 = ((navigator.userAgent.indexOf("MSIE") != -1) && Ver4)

ü Size of painted objects. All items are larger in NS than in IE. It is suspected that the absolute positioning and sizing differs due to how the borders are added to the item. IE appears to paint the borders within the height and width. NS appears to add the borders on to the height and width.
Solution: The following would be added to each template chapter, following the <input type=…>, to make an adjustment to the height and width of the painted items. The item name might be different variables based on the chapter xxxxx would be one of the following: ^DN^, ^CI^, ieg^ID^.

if (ns4) {

document.^FO^.xxxxx.style.height = ^PH^ - nsFactor ;

document.^FO^.xxxxx.style.width = ^PW^ - nsFactor ;

// if there is a concern about making the width too small then add the following

// to test and implement a minimum.

if (document.^FO^.xxxxx.style.width < "8px") {

document.^FO^.xxxxx.style.width = 7;

}

</script>

ü The IE code to clear a cookie is [document.cookie = “IEGmsg=”; ]. This however does not clear the cookie in NS. For DHTML we found that [“IEGMsg=^”;] works but we have not tested ASP to see what happens with ASP error handling. The overall symptom is if a Function Key is used to display the last errors and no errors were received a message indicating that no errors from host have been received should be displayed. With NS it displays a session string.

ü The function key was popping the message window twice. This is resolved by changing the statement in chapter 98 “mainline for hot keys” area. The new statement should read:

if (ns4) captureEvents(Event.KEYDOWN) or if (ns4) window.captureEvents(Event.KEYDOWN)

ü Local scripts are not getting executed in NS. The following does not work for NS but is required to make IE invoke local scripts associated to the data item:

TEXTFLDArq();

</script>

In order to make NS work, the statement, onBlur=TEXTFLDArq(); needs to be added to the <input type ….> string.

<input type=text name="TEXTFLD" maxlength=10 title="An aplha required field - Enter any value." style=" background-color:#FFFFFF; left:518; top:103; width:81; height:19; text-align:left;"

value="~"

tabindex=6 language="JavaScript"

onBlur=TEXTFLDArq() // added for NS. This does not work for IE.

onFocus="document.IEGIspec.TEXTFLD.select()">

Changes to IB might be required to key in on various editing attributes and generate the correct event calls inside of the

string. Not all of the local scripts have been investigated, but it is assumed that wherever IB generates a

a change will be needed to code each event inside the input type string.

User chapter to manipulate date is different in NS. Looks like the NS routine to retrieve the year, retrieves 0100 instead of 2000. This can be resolved by conditioning code on ns4.

The IEG header SignOFF script causes NS to loop attempting to submit a form. The IEGBYEFORM.submit might need to be changed or at least conditioned with ns4.

For DHTML we might need to add 1 to the maxlength attribute for signed numeric fields. Connector is always adding a decimal point to the number and is therefore requiring an extra position. IE does not have a problem but NS takes the maxlength very literally and needs to be increased by one in order to display values correctly. On a N82 field 00000.00 is displayed as 000000.0 in NS. When maxlength is 9, NS displays 000000.00.