I. Michael Snyder

1. Oraterm topics to be discussed include editing and compiling the resource file for key mapping and display attribute settings.
2. Forms generating and implementation issues will include setting properties for the form, windows, canvases, and fields for character mode display.
3. Navigation issues will focus on the triggers and program units required to use buttons, radio groups, and menus.
4. Report settings, Forms integration, output methods and installation under UNIX will be covered.
5. Preferences for Designer/2000 will be addressed.

Techniques will include Tar & Feather, Bend & Stretch, and 3W-T&E. Shared experiences of others will be integrated into the discussion.

Character mode development is not for the faint of heart. The only thing worse than developing character mode applications in a GUI environment is building GUI applications in a character environment. Nevertheless, it’s not as bad as all that.

Once you have gone through the process the first time, it gets easier with each subsequent module. Take good notes and be sure to document what you do so that it can be repeated. If you are smart, you’ll take the work you’ve done on one form or report and build a template for use with future modules and applications. In Designer/2000, you’ll need to create a character mode template and preference set.

Just as Oracle has transitioned developers to GUI for development, they expect to do the same for end users. As is the case in the rest of the industry, I believe that Oracle's strategy is to move applications to the Web in place of the character environment.

Some advantages of character mode applications are:

I foresee all of these advantages being handled by Web-based applications without any of the drawbacks. But the Web is still young and immature. Administrators lack confidence in its security. Meanwhile, we need to continue to create and maintain this lifeblood, up-and-coming environment until all of the answers are found.

I'll caution you that it’s been six months since I wrote the original paper upon which this presentation is based, so some features I will discuss may have been removed from subsequent dot releases; but I doubt it. Also, some of your experiences may have been more pleasant than mine due to a better port to your platform, or more patience on your part. Please feel free to correct me if something I present has been changed or improved.

This topic is one that receives little coverage, since it is not glamorous or on the cutting edge. However, as I said, character mode development "is the lifeblood of some organizations," and its value can be tremendous.

Oraterm is a Catch-22 product. To use Oraterm, you need a solid understanding of Oracle’s default key-mapping. However, your purpose in using Oraterm is to change the key-mapping because the one provided does not meet your needs. Besides being unintuitive in character mode (it uses GUI objects), it is also a poor out-of-the-box-experience (OBE) because it doesn't work well from the start.

First you’ll need to identify the resource file to be edited. On Sun UNIX, the default resource file is $oracle_home/forms45/admin/terminal/US/fmrcvt220.res. You can attach to this directory to edit the file with Oraterm, or you can pass the file name on the command line. Make sure you save a copy of the resource file before editing. Also, as you make changes, save versions of the resource file because you often end up with a version that won’t compile and you will have to go back. Make your updates a small set at a time and compile. Making too many changes at once will require a lot of debugging.

1. An ASCII (readable) section which reads like a program and a binary section. When you use Oraterm, it allows you to edit the programmatic part.
1. The generate function produces the binary component. If all goes well, you could work in Oraterm and be quite content. But don't count on it.

A complete map of all the properties and keys would be useful. The documentation provides some details.

Before you get started, make sure you've mapped out your requirements for all the keys and their functions. Remember that there are over 60 different functions that Oracle forms/menus support. Your organization may never use some of these; but you can rely on menus, triggers, or alerts to do them.

There are three programs that work with Oraterm. Depending upon the stability of your version of Oraterm, you may use one or all of these sub-products:

resprint21- Produces an ASCII dump of the resource (.res) file for (unsupported

editing), documentation, and seeing what’s inside and what you've done

wrong.

Command line> resprint2x fmrcvt220.res

Command line> resparse2x -o fmrcvt220.res fmrcvt220.prn

otgen21 - To "compile" or generate the binary components for each product that

may use the resource (.res) file.

Command line> otgen2x sqlforms fmrcvt220.res

Command line> otgen2x runform fmrcvt220.res

Command line> otgen2x oraterm fmrcvt220.res

Oraterm key-mapping involves the first technique I've tempted you with in my abstract, namely "Tar & Feather." When you call Oracle Support for bugs encountered, you get a TAR and lightweight support. Finding the two people in all of Oracle that know this stuff is a challenge.

• The programmatic component has some missing information. So, before you can start customizing the resource (.res) file, you'll need to get the delivered version’s binary and programmatic components correct and synchronized.
• The command line options in the tools that use anything other than the default resource files (UNIX e.g. fmrcvt220.res) don't work. You’ll need to rename the default and use the developing one as the default. Another Catch-22. If the resource (.res) file is bad, it’s hard to use Oraterm.
• Some keys just can't be remapped. The space bar will forever be "select" for buttons and check-boxes, and the right and left arrow keys will forever be the menu navigation keys.
• Some keys won’t re-map. In VT220 on Sun-UNIX, the F4 key seems to always want to be the exit key. But, you can map other keys to the same function.
• The same key can't be mapped to two functions, even if they appear to be mutually exclusive (are never both enabled at the same time). This can be tricky when you need to swap two keys. One will have to be disabled, and then re-enabled after the other key is changed and the resource (.res) file compiled.
• Show_keys causes a core dump. We developed our own show_key form as a work-around.

The development of character mode forms in Forms 4.5 requires the second technique called "3W-T&E" - "Three Windowed Trial and Error." A lot of character mode development involves "trial and error" because your environment is no longer WYSIWYG. The three windows include a GUI development window, a terminal emulator window for testing, and a terminal emulator window for forms generation. I’ve found that this is the most productive way to do development.

Placement of objects on the canvas is a little bit tricky. Even when you use "Snap to Grid" (Oracle's algorithm) for placing objects on one of your 24 lines, the result is not always predictable. The same is true for the starting position and required length for prompts, buttons, check boxes, etc. Prompts may have to be shortened; some objects will have to be stretched; placement of other objects will bend your imagination. This all gets even trickier, if you are crazy enough to want to use the same form in both character and GUI applications.

Yes, you can still use GUI objects in character mode. Buttons, radio buttons, check boxes, and tabs are still very usable in character mode forms. The tricks are to make sure they work, to be sure you can navigate without a mouse, that these items trigger properly, and that the users understand these objects and how they work in character mode.

As with any Forms development, it is important to make navigation and triggering intuitive and easy. I think it is great if you can navigate through a form with just simple navigation keys ([tab]/[back-tab], [page-up]/[page-down], [up]/[down], [enter],[ esc].) Personally, I hate function-keys, but they are a necessary evil. If it is important to use a function key, document it on the screen.

Unfortunately, [esc] is a reserved character in most terminal emulators, so it is not an option. Therefore, you will need a key for Exit or Quit. You’ll also need to identify function-keys for Help, to get to the Menu, for LOV, and, perhaps, one for Save. Everything else can probably be run from the menu. However, this is a topic for Forms development standards. Whatever you do, (unless you are trying to make this as painful as possible in order to force the organization to switch to GUI or the Web) make the selections intuitive and easy for users.

Buttons, by default, fire with a space bar. So do check boxes. Tab-dialogues and radio buttons must be programmed. Nothing that I can find in Forms fires them by default (in some implementations, the left/right button loops through radio buttons). Tab dialogues aren’t built-in; but they are coming.

Be sure that you can tab to all of the objects on a screen. Some programmers, Forms 4.5, and Designer/2000, by default, make many GUI objects mouse navigable only. Warning: In query mode, tabbing to a check box, radio button or drop list automatically selects the first option for use in the query. The user then can't get back to the null state without requerying. However, this problem is corrected in Form Builder 5.0.

I have outlined the 20 steps I use for building a character mode form from its GUI sibling. Building a character mode form from scratch or using a template should be a little easier:

1. Generate and run the form in character mode to get a feel for the work that needs to be done.
2. Command Line> genf formname (genform45)
3. Set coordinate system to character (form property).
4. Change the Horizontal-MDI Toolbar property to "null."
5. Change the Console Window to whatever is the first window in the form (form property).
6. Set window to 80x24 (window property)
7. Set button_canvas display and view to 80x2 at 0,19 and set bevel to "none" for bottom display or to 80x2 at 0,0 for top display.
8. Set main canvas display and view to 80x19 at 0,0 or 0,3 (canvas property)
9. Set View:Settings:Ruler to Units=CharCells, CellSize=5.25x13.5, Grid=2, Snap=2
10. Set View:Show Canvas Off to see grids
11. Set fonts to "fixedsys" and snap to grid (select all, set the font, arrange to grid).
12. Put Display Titles on blocks as required, since window titles don’t display.
13. Delete, disable, or replace toolbar with a character based Button_block.
14. Edit, delete, or replace button_block and navigation triggers, program units and key-triggers (show-keys, init_buttons, key-f1, etc) and remove when-timer-expired trigger.
15. Add init_buttons and show menu to init_form.
16. Set all module references to lower case. UNIX unlike, PC microcomputers are case sensitive.
17. Add "redisplay" after any "runproduct" statement. Terminal emulators tend to lose display characteristics on return to the forms.
18. Compile all and genf.
19. 3W-T&E to adjust fields, prompts, buttons, and objects. (radio=3char, chkbox=3char, etc)
20. Look for over-written or mis-sized objects, and test navigation, including radio groups (up/down), check boxes, and buttons.
21. Go to back to step 18 and repeat until correct.

To migrate a form from the Windows environment to UNIX, you’ll have to store the form in the database. Neither the fmb, nor the fmx are platform independent. The fmt should be portable, but using the database is pretty easy, and you won’t have to fool around with ftp. Be aware that once saved to the database, for any modifications, you should open from the database. If you open from the file system, you can’t over-write the database form. You’ll have to delete from the database and then save.

The issues in building character mode reports are not as difficult as with forms. Most reports translate very easily to character mode. Since many people are still building reports for line printers, report listings are still very popular.

Migration of reports to UNIX is accomplished by copying the .rdf file. This can be achieved with ftp or any other binary file transfer tool. The .rdf file is usable as is.

For displaying output reports, I found it best to set the DESTYPE parameter to FILE, and use UNIX utilities to browse, print, and/or download the output file. Be sure to set a unique path so that users don't overwrite each other’s reports. Add desname=$home||system.current_form||.lis and destype=file in forms calling reports. For managing output ¾ display, print, download, add an output menu to the forms application. Program units or a library will need to be added to each form to provide this functionality. Each program unit will call a UNIX script to be accessed by the host command.

There is one tremendous advantage of character mode reports over GUI mode. The output is ASCII and can therefore be downloaded, edited, and/or modified for inclusion in presentations and other reports. GUI mode only produces bitmap, pdf, or printer language like HP and Postscript (ASCII drivers yield poor output).

Like any development (generation) from Designer/2000, the strength and value of the end product depend upon the amount of effort put into the template. A good template requires good Forms 4.5 skills.

Like the previous two products, some trial and error will be required. But since the value of Designer/2000 is in its ability to reuse templates, it will take less effort with each new application.

Character mode form generation takes most of its properties from the template used. If the template does not specifically deal with all issues you may have to work with some of the preferences. The ideal approach is to use the template. However, some of the preferences that may be important to the Designer/2000 experience for character mode development are:

Taking the character mode development path should be avoided whenever possible. The level of support, the stability of the available tools, and the acceptability of the end product will put the developer into a no-win situation. Users will demand a GUI environment. The simulated GUI objects in character mode will be less than graceful to work with and the functionality will likely be less productive than simple block mode style forms of the past. The developers will be frustrated by the difficulty of doing character mode development and will be less than satisfied with the end results. However, if you desire a challenge, get rewards from accomplishing a project that gives you personal satisfaction, and you don’t mind the fact that your work will be gone within two years, go for it!!

About the Author:

I. Michael Snyder is a Principal at Dulcian, Inc. He, previously, was the Branch Chief and Team Leader for Software Development at the Federal Trade Commission. His 17 years of systems development and consulting experience includes Oracle Forms and terminal key mapping going back to version 2.3. He also has extensive experience with Reports, Web Server, PL/SQL and Database Administration. I. Michael Snyder is a Scout Master for Boy Scout Troop 772, has taught Database Concepts at the George Washington University, and has a Masters Degree in Information Technology.