Re: Migrating a Forms 4.5 app from Win 3.1 to Win 95/NT

Simon,

There were certain niggling problems that came too light when migrating from Win 3.11 (4.5.6) to Win 95 (4.5.7): Ê Formatted Numeric Fields
There is a potential problem with Forms that contain right-justified numeric fields. This involves loss of significant data (from sight anyway). In 4.5.6, a Right/End aligned item with a Format Mask of 99990.99 and Item Width of 7 characters displayed as:
[1234.56]
[ 531.00]
[ 0.00]

If a number was greater than the Item Width, the highest order digits were missing from view, eg. 12345.67 would display as:
[2345.67]

This may either have gone unnoticed or (somehow) considered acceptable because affected numbers were likely to be several orders of magnitude greater than normal.
Since Upgrade to 4.5.7, the display characteristics have changed significantly. Instead of loss of high order numbers, low order numbers are lost instead. If the Mask is 999999990.99, ie. 4 more digits, and the field width is unchanged, the following is displayed:
[ 123]
[ 5]
[ ] completely blank

As you can see, rigid adherence to the Format Mask is applied regardless of whether there are any high order digits. The problem is therefore only evident when the Field Width does not ensure the entire Format Mask can be displayed.
There are obvious solutions - expand the Item Width, reduce the Mask, or change the database. Reducing the Mask is easier because it doesn't change the screen format, but if there are any numbers with an order of magnitude greater than the Mask then hashes are shown instead (eg. 12345.67 would display as #######).
Perhaps a better option is to use the 'FM' mask and zero pad the decimals, ie FM999999990.00. This gives a display of:
[12345.6]
[ 531.00]
[ 0.00]

The first number, 12345.67, has lost it's least significant digit. I would recommend that the Item Width is no smaller than that required to display everything left of the decimal point. A number of 11,2 should therefore allow at least 9 characters to be displayed. Ë Returning Non-display Items from an LOV In Forms 4.5.7 you can't have a LOV return item that is a 'Display Item', because it causes a truncation error. This problem didn't occur in Developer 1.1 under Win 3.11. Changing it to 'Text Item' fixes the problem. Ì Copy Value From Item
Following the upgrade to Developer 1.3, it was found that a Form was not loading a default value into a control field. The mechanism for this was to load a control field with the default value and then let the Copy Value From Item property of item load the value into the field automatically.
This worked because Copy Value from Item worked when focus went to the item, and focus used to go to item automatically because it is the first field on the form.
This appears to be where the change has occurred - Focus no longer seems to be in the first item during the When-New-Form-Instance trigger. However, a call to the built-in Clear_Record within that trigger forces it. ¹ Keyboard functionality
Default keyboard navigation in Developer 1.3 has changed e.g. <SHIFT+Down> arrow does 'Next Record', <SHIFT+Up> arrow does 'Previous Record', <Page Up> is 'Last Record' on screen, <Page Down> is 'First Record' on-screen, <ENTER> is Next_Item.
The other thing we noticed is that icons that are "Navigable = TRUE" are now not navigable using the keyboard. On some screens under Developer 1.1, we would allow users to navigate to an icon, hit <ENTER> and perform as if the icon was pressed. We needed this functionality in case the user's mouse 'died'. Now this isn't possible (or we just haven't found a way). º Connecting to Database
When users are connecting to the database and they hit <ENTER> instead of pressing the CONNECT button, it caused the first form called to have the carriage return inserted in the first navigable field. Users weren't aware of this modification and proceeded to other forms where they got the error 'calling form has unapplied changes'. Our solution was to make the first navigable item a non-base table item which created a 5 second timer (on entry) to trigger navigation to the first base-table field. » Annoying Scroll Bar
In Forms Designer, the scroll bar can sometimes play up i.e. not allow you to scroll to the very bottom of a PL/SQL editor window and it 'bounces' up (reverses direction) when it hits the bottom. ¼ Missing Boilerplate
When upgrading one form, we lost all of its boilerplate items. The reason for this is not clear; when we tried to compile it we got a 'VGS corruption error'. Luckily another developer had taken a copy of the form, and on their machine, the boilerplate was OK. This could have been a PC-specific problem, but of all the forms we upgraded this was the only one to suffer this problem.
½ Item Width = 1 Caused GPF
We came across an instance where the width of an item was accidentally changed to 1 point. It caused the form to GPF at run-time. This could have been because the bevel is probably more than 1 point wide.

Simon Dennis <denniss_at_logica.com> wrote in article <01bcffdf$e2b47b40$6746ea9e_at_p02850.logica.co.uk>...

> I am currently working on an Oracle system in the following environment.
> Oracle RDBMS v 7.2.0.0 on a Dec Alpha running Unix.
> Forms 4.5
> Windows 3.1 (yeah I know, I know)
> 
> The client is looking at migrating to either Windows 95 or Windows NT.
> 
> I would like to hear of any experience of such a migration.  We are
> expecting to have to upgrade to the 32 bit version of forms and

> all of them.
> 
> Are there any particular migration issues that we should be aware of?
> 
> -- 
> Simon Dennis
> denniss_at_logica.com
> 
>