Theme Best Practices

Before undertaking a project to convert numerous green screen DDS members to Rich Display files, some effort should be made to create a custom conversion theme. The How to Guide gives an overview of Theme creation but there are some best practices that should be followed in order to make the Rich display files as extensible as possible allowing for possible future style changes.  This becomes especially important when you plan to convert a large number of display files. To give you an idea, when Profound Logic Software is contracted to perform a mass conversion service consisting of hundreds or thousands of display files, we allow a number of weeks to create a custom conversion theme before any serious conversion run is attempted.

If you are planning to use Genie with converted Screens

It is often the case that an ERP system will contain 5250 programs that cannot be converted. These could be:

• Non-display file menu panels

• CL or COBOL programs with display files

• Programs which have no source code

• Interactive OS commands (i.e. WRKSPLF WRKMSG)

To solve this problem, converted rich display files program can be run within Genie. Genie is able to use web-facing to render any 5250 content but when a rich display file program is called, Genie will render the native GUI. 

When creating a conversion theme for this situation, some thought should be given to make sure there is a cohesive look and feel between the Genie Skin and the Rich display files. You may consider using the Genie Hybrid Skin and the Hybrid conversion theme as a starting point. These already have the same look and feel and the Hybrid skin moves all the function key labels to the left of the screen so they appear similar to a rich display file. Details of customizing a Genie skin can be found here.

Use Custom Widgets

Apart from the usual input and output fields, the conversion theme adds a number of different widgets to the converted display file. These could include:

• Grid widget for a subfile

• Button or Link widgets for function keys

• Panel widgets

• Dialog widget for popup window

Some shipped widgets are constructed using images for background gradient color or rounded corners, and these images are replaced with every product update. For this reason, you should never modify a shipped widget; instead you should create a custom widget. Even if you find a shipped widget that suits your purpose, we recommend that you create a custom widget so that down the track you are able to re-theme your application with different colors simply by changing these images and the style sheets without the need to alter or re-compile any display files. If you are planning to convert a large number of display files, this becomes more important.

See Custom Widget Development for details.

Use CSS Classes

Where possible use CSS classes to define styling of the widgets in your converted display files. If you follow the recommendation above and create custom widgets you are also able to define a css class for each widget type.

There are also a number of properties that control css classes in the theme itself. These are:

• input css class

• input css class 2

• constant css class

• output field css class

• css class prefix

These classes should  be used as much as possible. For example if you decide to use a dark blue font color throughout your application, specify (input, constant and output) class names and then specify the dark blue font in a style sheet under those classes.  This is a better approach than hard coding dark blue in each converted display file. If you later want to change the color scheme of your application, this would be a simple task if you used class names. If the display files have hard coded colors, a re-style could be a major undertaking.

Screen Width

When converting display files, consider the width and height of the converted screen. The width should be set so the user with the lowest supported screen resolution can see the full width of the screen without the need to scroll sideways. Users with a higher resolution screen would typically have the screen centered with blank sections on the left and right side of the page. Two properties, top offset and left offset are used to define how far down from the top and in from the left of the screen the widgets will be placed during conversion.

Of more importance are two other properties column width and row height. These define the number of pixel that will used to space the row and column of the converted display file. These will have significant effect on the width and height of the screen and should be used in conjunction with the choice of font family and font size. More information can be found here.

Choosing a font

The font used for converted display files is an important choice.  In many cases a mono-space (sometimes called fixed pitch) font needs to be used. This is a font where each character has the same width and is used on all 5250 screens. Often a green screen display file has been built so certain data will line up in columns. If a proportional font is used these columns will no longer line up.

Proportional font - Each character can have a different width. For example " WWWiii"

The choice of font needs to be used in conjunction with the column width and row height as explained in the Screen Width section above and should be defined in the style sheets.