OraTransplant

Function key not allowed bug?

Ever since we migrated from Forms 6i to Forms 10g (9.0.4) we had user complaining about getting sporadic errors “FRM-41009 Function key not allowed. Press Ctrl+F1 for list of valid keys”. Once they’re in this situation every key pressed will raise this error. The only key that Forms responds to is Ctrl-Q to close the Form. When the form is closed, the application functions normally and all keys can be used again.

I already logged a TAR a couple of weeks ago but without a reproducable testcase there wasn’t much support could do for us. I was hoping they could find some known bug, but they couldn’t. The only thing we could do is inform our users of the issue and asking them if they could come up with the steps to reproduce.

Today we got a break. One of our users called she could reproduce the problem at will. I joined here and she was right. I wrote down the (quite a few) steps to reproduce and tried it at my own test-setup. Fortunately the problem also reproduced there.

I then figured out which forms, menus and libraries were needed to reproduce the case. It turned out I need 26 forms, libraries and menus for the smallest testcase. I doubt Oracle Support would be happy with such a testcase

I also did some searching on Google and Metalink and could find other users with the same problems, but none with a fix. I’ll try to trim down the testcase to a reasonable size in the coming days and will then open a TAR and have Support look at it. Let’s hope they can come up with a fix. I’ll update this blog entry when I have a solution.

Update 30-aug-2005: As it turns out, the error is caused by juggling around with the menus. First to give some more information on the testcase I provided to Oracle:

1. User starts the application with a form that has the menu property set.
2. User clicks a menu entry that does a CALL_FORM('form1', hide, do_replace);
   This form has the menu property set and so the menu is replaced. In our case this was the same menu so you cannot actually see this.
3. User clicks a menu entry that does a NEW_FORM('form2');
   This form does not have the menu property set
4. User clicks a menu entry that does a NEW_FORM('form1');
   This call causes the “FRM-41009 Function key not allowed”

Oracle and I found three workarounds:

1. Setting the menu property of form2 to the same menu
2. Use OPEN_FORM in stead of NEW_FORM when opening form2 (the one without the menu)
3. Do not use DO_REPLACE when calling the first form, but just use CALL_FORM(’form1′)

All of these workaround might change your application works, so please check which one suits your needs.

For anyone who wants to take this up with Oracle support. The original TAR is logged under number 4648156.992 and the support engineer promised to file a bug. As soon as I have the bug number, I’ll update this entry.

Update 10-oct-2005: Oracle found out what the issue was. It’s having a window with the name ROOT_WINDOW in one of your Forms. The Forms that started out in SQL*Forms 3.0 all have windows with this name. Windows named ROOT_WINDOW get a special treatment in Oracle Forms and that’s what’s causing the problem. Oracle published note 334210.1 on Metalink about the issue. The easy fix is to rename the windows to a different name.

Background of textitems black or pink

We’ve been strugling with a Forms issue for quite a while now. We’ve converted about 300 forms from version 6i to 10g and found out that some of them use a very dark gray (almost black) or pink color as background for some textitems. It occurs for textitems that have no background color set. This shows as “Unspecified” in Forms Builder. When you initially start the Form all looks ok, but after opening and closing some other forms in the application the items suddenly change to this darkgray or pink color.

Quite a number of our Forms originated in SQL*Forms 3.0 and were converted to 4.5, 6i and now to 10g. As it turns out these have a different color pallete than the ones that were created in 6i straight away. It looks like Oracle changed their default color palette along the way. The old forms have exactly the same palette as is now available in the CDE1.PAL file still in the Developer Suite distribution.

I filed a TAR at MetaLink and that resulted in a new bug (4383847). As it turns out, Forms deployed over the web cannot cope with different color palettes in the same session. Oracle says it has something to do with Java restriction. The answer is that you should not use custom palettes. I tried to argue that my palettes aren’t custom but just the default ones of 10 years ago, but that didn’t help.

The steps to reproduce the issue are:

• Start Forms Builder v9.0.4.1.0
• Edit > Preferences
• Set Color Mode to Editable
• Restart Forms Builder
• Save the new form (module1) under the name DEFAULT.FMB
• In the Forms Object Navigator create a new Canvas
• Also from the navigator, create a new Block (do not use wizard)
• Set block property “Database Data Block” to No
• Navigate to the Items node and press the green plus three times
• Select all three new items and set the Canvas property to the created canvas
• Set the Item Type of the second item to “Display Item”
• Set the Item Type of the third item to “Push button”
• Add a When-Button-Pressed trigger to the Push Button with the code call_form('cde1');
• Open the layout editor
• Shift the three items around to fix the overlap
• Save the Form
• Copy the DEFAULT.FMB to CDE1.FMB
• Open the CDE1.FMB in Forms Builder
• Change the Name property of the form to CDE1
• Open the layout editor for this Form
• Select Edit > Import > Color Palette
• Browse to ORACLE_HOME\tools\common90 and import CDE1.PAL
• Change the When-Button-Pressed trigger to call_form('default');
• Save the Form
• Compile both forms using Forms Builder
• Start DEFAULT from Forms Builder
• Notice the correct colors for the text item and display item
• Press the button to start the CDE1 form
• Notice the CDE1 form to open with pink items
• Press the button to start the DEFAULT form
• Notice the DEFAULT form now also opens with the pink items
• Close your webbrowser and go back to Forms Builder
• Now start the CDE1 form first
• Again notice that the first form shows with the correct colors
• Press the button to start the DEFAULT form
• Notice the DEFAULT form opens with very dark gray (almost black) items
• Press the button to start the CDE1 form
• Notice the CDE1 form now also opens with the dark gray items

I already mentioned this problem in a previous blog posting about our Forms conversion. That raised some questions with people, so I decided to document it in this separate blog entry. Also in my quest for a solution to this problem I found several forum questions with the same behaviour of items changing to dark gray, black or pink. Hopefully this blog entry can be helpful to these people.

The only solution provided by Oracle was to manually import the default palette into each and every form. To us, that was not a workable solution. We’re planning on running Forms 6i client/server and WebForms 10g in parallel for a couple of months. Developers continue to work in 6i only and the Forms are converted to 10g when deploying. This means our conversion process has to be repeatable and manually importing a palette is not an option. Unfortunately the JDAPI does not support changing the palette, so we couldn’t automate it that way. The solution we choose was to use the JDAPI to set the background color property of all items where it is not set. I’m setting the background color to “r100g100b100″. In effect, this is just white but with a different name. This makes it possible to recognize the items that were changed by the JDAPI. Whenever Oracle fixes the palette-bug, I might decide to change these items back to Unspecified to get really transparent items. Now I’m having white items on a non-white canvas, which isn’t what the users ask for.

If you’re struggling with white background of readonly items (both textitems without modification rights and display items), please read note 305563.1 on MetaLink. It describes a applet parameter readOnlyBackground. You can set this to TRUE to force all read-only items to use the canvas color as background. A more usefull setting is AUTO which uses the canvas color as background for readonly items that do not have a specific background set. If a readonly item does have a background color set (e.g. a current record visual attribute) then that color is used when using AUTO.

Update 29-jul-2005: Also see this blog entry of Duncan Mills which describes changing the color palette of Forms and in his introduction mentions the issue with black-on-black items.

Conversion to webforms 10g completed

Today we started production on our new webforms 10g environment. This completes our migration from client-server Forms/Reports 6i running on Citrix MetaFrame to Forms and Reports 10g (v9.0.4.1) running on two Linux application servers. In total we’ve migrated 601 files (299 forms, 23 menus, 76 pl/sql libraries, 4 object libraries and 199 reports).

We also integrated Forms with Single Sign On. We’re building a number of J2EE web-applications and we didn’t want users to have to logon to each application separately. Our existing extranet has also been integrated with SSO and now functions as a portal to the user.

We’ll be running the new Forms 10g environment and the old 6i (on Citrix) environment in parallel for two months. This gives our 400 external users some time to switch to Internet Explorer/Java/Acrobat. It also means we’ll have to support both environments for a while. This is why development is still on 6i and the files are converted to 10g during deployment to test/production environments. This means our conversion process has to be repeatable. That’s why I’ve created a java program based on the JDAPI to do this conversion. You can read more details about this program in a past blog entry.

When we shutdown the Citrix environment, developers will start using Developer Suite 10g. By then, the JDAPI based conversion tool will no longer be needed. However, it has been a very valuable experience. I think we’ll continue to use JDAPI based tools for several things. One of the first things on my list is an automated tool for QA checks.

Custom built Forms Migration Assistant

We’re currently migrating from Oracle Forms 6i (deployed using Citrix MetaFrame) to Forms 10g running over the web. For that, we have to migrate about 350 forms, libraries, menus and object libraries. In this blog entry I’ll try to explain why I ended up creating my own Forms Migration Assistant and what changes I’m making to all files during migration.

I started of with the Forms Migration Assistant that comes with Oracle Forms. It’s quite easy to run and it mainly focuses on all the PL/SQL code in your files. It makes some changes to replace obsolete built-ins and it issues some warnings for PL/SQL code that might need changes. In testing the forms, we found that we needed a lot more changes.

I tried to find the source code of the Migration Assistant or a way to extend its classes. Unfortunately that did not work. I then decided to create our own Migration Assistant to run after the one Oracle supplies. With the JDAPI that comes with Oracle Forms it’s not even that difficult. With the JDAPI you can open each module (Forms, Menu, Object Library or PL/SQL library) and get/set each property and add/remove objects.

Over a couple of weeks we tested the migrated application and kept adding more code to my own Migration Assistant to make even more changes to the files. In the end I concluded that there wasn’t much that the Oracle Migration Assistant was changing for me, so I even incorporated those fixes in my own Migration Assistant.

I’m just posting all automated changes I’m making in this blog. Perhaps they are useful to others in the same situation.

Forms, Menus and Object Libraries

• If an object is sub classed from another file, change the filename of this file to lowercase as we’re also moving to a case-sensitive platform (Linux)
• Change the filename of all attached libraries to lowercase
• When a canvas has a background color of “unspecified”, set it to white to keep the old look-and-feel
• When a window has a background color of “unspecified”, set it to white to keep the old look-and-feel
• Set the filename of the Menu property to lowercase
• Add date initialization code (plsql-date-format, builtin-date-format) to the pre-form triggers of older Forms (they originated in SQL*Forms 3.0)
• Set the filename of the icon of a MenuItem to lowercase and remove ICO extension if it is there
• Convert the PL/SQL code of a MenuItem (see below for PL/SQL conversion)
• Set the fill pattern of boilerplate items from transparent to none
• Set the edge fill pattern of boilerplate items from transparent to none
• Set the edge fill pattern of boilerplate items from solid to none
• Decrease the font-size of buttons by 1 to make the text fit in the new rounded Oracle look-and-feel buttons
• Set the filename of the icon of a button to lowercase and remove ICO extension if it is there
• When items have a background color of “unspecified”, set it to white to workaround (non-published) bug 4383847
• Some items had the Required property set to True and the Visible property set to False. Forms 6i did not enforce the required property for such an item, but Forms 10g does. As a dirty fix I clear the Canvas property of these items. That way, Forms 10g also doesn’t enforce the Required property. Do check all these changes carefully. We found some cases were the properties were changed at runtime and the change of the Migration Assistant was undesirable. I hard coded these exceptions in the Migration Assistant.
• Some items had Required=true, Visible=true and Enabled=false. Again, Forms10g enforces this required property whereas our old Forms environment didn’t. For these items I set the Required property to false. Again, check each change. I again made some hard coded exceptions to this rule.
• Forms 10g raises compilation warnings when some properties are set for subordinate (mirror) items. These properties are not uses for subordinate items, hence the warnings. So we cleared all MaximumLength, CopyValueFrom and InitialValue properties of subordinate items.
• Convert the PL/SQL code of all program units (see below for PL/SQL conversion)
• Convert the PL/SQL code of form, block and item level triggers (see below for PL/SQL conversion).

PL/SQL libraries

• Convert the PL/SQL code of all program units (see below for PL/SQL conversion)
• Set the filename of attached libraries to lowercase, because of our move to the case-sensitive Linux.
• Add two new custom build PL/SQL libraries to the core PL/SQL libraries of our application. That way the new custom build libraries are effectively attached to every form in our application. See below for the details of these libraries.

PL/SQL conversion

• Change the use of : PW to get_application_property(password)
• Change the use of BREAK to DEBUG.SUSPEND
• Change the use of CHANGE_ALERT_MESSAGE to Change_Alert_Message.Obsolete from our new custom build library (see below for details)
• Surround the first argument of open_form, call_form, new_form and replace_menu with lower() to handle the new case-sensitive Linux filesystem.

I created a new PL/SQL library to handle all sorts of obsolete calls. In stead of changing all the old PL/SQL code, I just left that code as it was and added some program units to a shared PL/SQL library that is attached to each and every form.

• Change_Alert_Message package. Has two procedures to handle the overloading of both an alert_id and alert_name as first argument.
• Disable_Item, Enable_Item: try to find menu item by the supplied name. If found, enable/disable it
• Exit_Menu, Menu_Help, Previous_Menu, Set_Input_Focus, Show_Menu: completely obsolete built-ins that have just been replace with a null statement.
• Menu_Show_Keys: Just call the built-in show_keys.

I hope this blog entry can be useful for others who are also migrating a Forms application. If your just starting, this might be a helpful pointer of things to consider.

You can download the source code at your own risk. It was my very first Java coding, so looking back at it I’m not too proud of the product. But it might get you started.