Re: HELP UPGRADING TO SQL FORMS 4.5

In article <3t55q2$o3q_at_gulfa.kuwait.net> abukhadra <edina_at_kuwait.net> writes:

>At persent we have a pretty large application running under SQL FORMS 3.0 and ORacle Server 77.
>We are in the process of designing an upgrade to CDE.  However as an interim solution someone told 
>that we could simply regenrate teh current forms under SQLL FORMS 4.5 and teh forms would then 
>function in a client serve envroment, however, without tehe GUI lookok.  Does anyone know anything 
>about this.  I would greatly appreciat all the help you could give.
>

Here is some info on moving to Developer/2000, which includes Forms 4.5. This information mostly applies to Forms 4.0 as well, with the exception of the widen_fields option. Good luck!

• Dennis Moore, Oracle Corp. dbmoore_at_oracle.com <- Office (preferred for e-mail) dbmoore_at_netcom.com <- Home (preferred for living ;-)

[Note: Set mouse navigate limit to field to get exactly the same behavior on GUI forms as in character mode forms.]

Moving from Character Mode to GUI

Making the transition from a character-mode environment to a GUI environment can be a challenge, both because of the inherent differences between the two environments, and because of the expectations that users bring to GUI applications.

To obtain the advantages of a GUI environment requires detailed planning and execution. Once the planning phase is complete, Oracle Forms 4.5 provides the tools you'll need to implement your migration plan. Your choice of a migration strategy depends on factors unique to your organization, and defines how much of the potential of Oracle Forms 4.5 your organization can currently employ.

Oracle Forms developers can choose between two basic migration strategies:

• Minimal upgrade
• Complete conversion to GUI

The following table summarizes some differences you may want to consider when choosing your strategy. (Both approaches use Oracle Forms Version 4.5: the difference lies in the degree of change you want to implement at conversion time.)

Note: Your choices may be affected by platform-specific capabilities. For example, a minimal upgrade on a UNIX or VMS platform produces an application with same look and feel as a Version 3.0 character mode application, while a minimal upgrade on a DOS platform must be run as a Windows application since a character-mode runtime is not available.

User Expectations

Oracle Forms customers who have completed the upgrade process report that their clients have specific expectations of GUI applications:

• Visually pleasing window appearance, specifically color
• Less crowded screens (which means designing more windows)
• GUI "widgets," including scrollbars, which take up room on the canvas
• Proportional fonts (which may not be portable)
• Mouse navigation
• More types of help than in character-mode applications

There are advantages and disadvantages to each approach, and every organization will make a choice based on specific and local needs. Still, it may be useful to review the strategies chosen by some Oracle Forms customers who have completed the upgrade process.

Migration Strategies

It may be useful to review the strategies chosen by some Oracle Forms customers who have completed the migration process.

Minimal Upgrade: At Company A, the goal was to move to Forms 4.5 as quickly as possible. They wanted to get something familiar running on Windows while they evaluated how the company could best take advantage of GUI features in the future. So they upgraded all their current character-mode forms to run on Oracle Forms 4.5, deployed the application on Windows, and restricted mouse usage to menu choices only. Operators use the forms exactly the way they used Version 3.0 forms.

Full GUI Conversion: At Company B, the goal was to utilize the increased productivity of a true GUI application. Company B used a two-stage process:

• They re-designed all forms for a GUI interface (including re-designing both the appearance of all forms, and the navigation methods).
• They implemented the re-design using Oracle Forms 4.5.

At Company B, they knew conversion would be a big project, but they wanted the ease-of-use provided by a true GUI application. To make the redesign easier, they adopted standards for the applications' appearance. They were able to keep all of their previous validation and transactional logic in place.

A Mixed Approach: At Company C, the goal was two-fold:

• Select the simplest applications, quickly upgrade them, disable the mouse and run them with character mode behavior.
• Select the major applications that would benefit most from GUI conversion and invest the time to redesign them.

They focused on two main areas in their redesign:

• They adopted standards for GUI appearance, and redesigned their forms to use the GUI items, such as check boxes and radio buttons.
• They also redesigned the process by which the operator moves through the form. They redesigned some poorly-written key triggers to make use of mouse navigation.

They did, however, keep almost all of their logic: they re-used the PL/SQL code, moving it from key triggers to mouse-oriented triggers.

Conversion Sequence

Whichever migration strategy you choose, your conversion will include three main stages: pre-conversion planning (including creating UI standards), upgrading, and post-conversion fine tuning.

The following table summarizes some differences in the effort required at each stage.

If you choose an intermediate migration strategy, you might start with the sequence for the minimal strategy, and add to the planning stage:

• A review of your application for those forms that would benefit most from minimal GUI changes.
• A review of your data for fields you might want to represent using new GUI functionality: buttons, checkboxes, radio groups, and alerts.
• A plan for adding, for example, a tool bar to certain forms and changing the triggers to allow using the mouse on those forms only.

Adding GUI Functionality

When you plan your migration, you may want to consider adding GUI features to represent specific data values:

Converting Key Triggers

In a GUI environment, the operator navigates primarily using the mouse, rather than keys. When the operator uses mouse navigation, any code based on firing key triggers may not be executed, particularly because with key triggers you can predict a navigation sequence, while with mouse navigation the operator can enter any field at any time. So in the conversion process, the goal is to move functionality that was previously This creates a conversion requirement, because most applications written for character-mode environments make extensive use of key triggers.

Here is one possible approach for converting key triggers:

1. Analyze the application:
   • Print out all triggers (using File->Print).
   • Print out all screens in the application.
   • Create a diagram representing the form by drawing in the triggers on the screen layouts.
2. Analyze the triggers, dividing them into two categories:
   • Navigation-sequence triggers, such as KEY-NXTBLK, that make assumptions about the target for input focus, should be replaced with When-New-Instance triggers. In this way, the functionality will occur when input focus arrives in the target item, rather than when it leaves the previous item.
   • Keyboard-function triggers, such as KEY-HELP, whose function cannot be invoked by simple use of the mouse.
3. Plan how to deal with each category of triggers:
   • Navigation-sequence triggers: The application must determine which navigation event has been performed, where the input focus originated and where it now lies, and which procedure to perform.
   • Keyboard-function triggers: Place this functionality in either the menu or a button, as well as in the key trigger. The menu item or button can fire the relevant DO_KEY operation.

When the operator uses the mouse to navigate from item to item, this freedom of movement can cause a number of problems:

• The operator may navigate into an item that would not normally be available.
• Pre- and post- triggers may fire when they would not be expected.
• Unpredictable routing: no way to be sure how the operator reached this item.

These problems can be lessened by enabling or displaying only items that are currently available for use, using the SET_ITEM_PROPERTY built-in and setting the Enabled and Displayed properties.

Widening Fields

The GUI "look and feel" includes field beveling to produce a three-dimensional look. However, the field bevel can take up to 1/2 character per field on some platforms, with the result that some fields may no longer display their full values.

To resolve this problem, use the widen_fields option when you generate your applications in Version 4.5.

The effects of the widen_fields option will depend on your interface design, and should be tested carefully. Effects can include:

• Text may be cut short.
• If two fields are currently flush against each other, the widen_fields option will cause the fields to overlap.
• If two fields currently have one space between them, the widen_fields option will cause them to have no space between them.

For more information about the widen_fields option, see the Oracle Forms Reference Manual, Vol. 1, Ch. 1, "Components and Options."

Creating a Checkbox from a Version 3.0 Checkbox Field

If you have Version 3.0 applications which simulate checkboxes with single character fields, you will need to convert them to Version 4.5 checkbox items, using the process described below.

Converting Pop-Up Pages

The upgrading process converts pages to content canvases:

• A full-screen page becomes a content canvas-view in a default document window.
• A pop-up page also becomes a content canvas-view in a separate window.

To preserve the character-mode functionality, you may want to render the pop-up pages as stacked canvas-views, instead.

To convert pop-up pages to stacked canvas-views:

1. Convert the form to Version 4.5 and open it in the Designer.
2. In the Navigator, select the window you want to render as a stacked canvas-view.
3. In the Properties window, set the Canvas-view Type property to Stacked.
4. Set the Window property to the name of the window where you want the canvas-view to be displayed.
5. In the Navigator, delete the window the stacked canvas-view was assigned to previously.
6. If you want the stacked canvas-view to disappear when the operator navigates out of it, call the HIDE_VIEW built-in from within a trigger, such as a Post-Block trigger.

Mouse Navigation Limit

Determines how far outside the current item an operator can navigate with the mouse. Mouse Navigation Limit can be set to the following settings:

Form 	(The default.) Allows operators to navigate to any item in
	the current form.

Block 	Allows operators to navigate only to items that are within
	the current block.

Record 	Allows operators to navigate only to items that are within
	the current record.

Item 	Prevents operators from navigating out of the current item.
	This setting prevents operators from navigating with the mouse
	at all.

Applies To: form

Set: Designer

Default: Form

-- 
-- Dennis Moore, Oracle Corp.
dbmoore_at_oracle.com	<- Office (preferred for e-mail)
dbmoore_at_netcom.com	<- Home (preferred for living ;-)