Document-ID: 33605.1
Subject: PORTING FORMS 4.0/4.5 APPLICATIONS ACROSS PLATFORMS
Author: RDAS
Last Modified Date: 26 July 1996
PORTING FORMS 4.0/4.5 APPLICATIONS ACROSS PLATFORMS
===================================================
INTRODUCTION
------------
This document covers issues when porting Oracle Forms 4.0/4.5
applications between MS-Windows, OSF/Motif, and Macintosh platforms.
Topics covered include:
* About portability
* Setting standards
* Color palette
* Choosing fonts
* Window size
* Using icons
* Choosing a form coordinate system
* MS Windows Multiple Document Interface (MDI)
* Monitors - Physical DPI vs. Logical DPI
* HOST() built-in
* User exits
* Character-mode considerations for porting applications developed
using Forms.
* Form functionality
* Buttons
GENERAL CONSIDERATIONS
----------------------
Portability includes :
* Platform portability : the ability to develop and deploy on different
platforms.
* Device portability : the ability to develop and deploy on the same
platform but different devices.
* User Interface (UI) : the ability to deploy the same application on
portability GUI and character-mode devices.
Planning:
---------
A major goal in planning for portability is to anticipate the kind of
user interfaces on which your system will be deployed over time.
Although this information can be difficult to obtain in advance,
consider the following questions:
* On which platform do you currently develop applications?
* Are you planning to migrate to a different development platform?
* What platform do your forms operators currently use?
* Are there plans to migrate to another range of deployment interfaces?
For example, a typical development environment may include:
* Forms developers using Motif on large color monitors.
* Sales staff using small-screen MS Windows laptops in the field.
* Forms operators using MS Windows on large-screen monochrome monitors.
Porting Process:
----------------
The general process for creating portable applications includes
these stages:
1. Create standards for your application to ensure a similar look and feel
both within the application and across platforms.
2. Create the application on the base platform.
3. Copy, regenerate, and run on the target platform, testing for any areas
where adjustments are needed for optimum appearance.
When you port an application, you will able to run it directly on the
target platform. The Toolkit level that Oracle Forms is built on will
render all widgets with the native look and feel of the targeted
platform.
However, because of platform-to-platform differences, you may decide
to make some minor changes to your original source code so that it meets
your requirements on both the original and the target platforms.
4. In the Designer, fine-tune the base-platform application.
Setting Standards:
------------------
One common approach to designing cross-platform applications is to create then
refine standards based on prototyping efforts and usability testing. The
requirements best-suited for a particular company are unique as will the
standards for your company.
Consider developing three types of standards:
1. Coding standards, including naming standards for all objects and files.
2. GUI standards, including standards for screen appearance (e.g. color,
spacing and layout) as well as standards for specific GUI objects
(e.g. buttons and check boxes).
3. Usage standards, including look and feel standards that ensure that
various parts of the application react to user input in the same way.
Template Forms:
---------------
In addition to creating a standards document, you may also want to incorporate
the standards in a template form. Then, instead of starting a new form,
developers open the template form and save it under a new name. The template
form provides a starting point for developing applications according to the
standards.
Template forms include anything that can be used across all forms in an
application:
* object groups
* property classes
* tool bars
* libraries that include shareable pre-written, pre-tested subroutines,
such as calculations, validations and utility routines.
Before using any templates, be sure to test them on all platforms.
General Guidelines on Writing Portable Code Using Oracle Tools:
---------------------------------------------------------------
1. Use local_visual_attributes as often as possible.
2. Avoid using the HOST() built-in.
3. Check syntax and availability of fonts from platform to platform
(i.e., the Courier font is available on both Windows and Mac).
4. Use the RUN_PRODUCT() built-in as often as possible to integrate
Oracle Tools.
5. Know the display device (i.e., if display is using 4-bit VGA,
know to use colors in this range).
6. Limit the use of non-portable functions, such as DDE, OLE, VBX controls
and sound.
7. If using non-portable functions, isolate them in modular code
(i.e., use libraries).
8. Use real coordinates, but snap items to a character cell grid.
This allows you to do things like make buttons 150% of the height of
a text item on Motif and scroll bars 20 pixels wide on Mac.
9. Courier is a poor font for portability. It is *not* always available on
Macintosh (in fact, only Geneva is guaranteed). Helvetica is the most
widely available font. Mac and Windows users will not accept Courier;
they expect MS Sans Serif and Geneva/Chicago.
10. The only solution for monochrome and color support in a single form
is to basically use a monochromatic color scheme. For example, use a
color palette consisting of black, white, light gray and dark blue.
Note also that widgets can take on only 1 of 16 colors on MS Windows.
11. Avoid using iconic buttons so you do not need to worry about converting
icon files between platforms. An MS Windows .ico file cannot be used on
another platform.
12. Keep in mind that port-specific functionality is not easily portable.
The two main things that come to mind are DDE and OLE on the Windows
platform. Though Oracle Tools usually minimize the use of port-specific
functionality, these two were specifically added by popular customer
demand.
13. If you need to use non-portable functions, isolate them in modular code,
such as modules and libraries.
14. User exits always need to be rewritten for each platform. Oracle is not
discouraging doing this, but keep in mind that it will require significant
work.
15. Host commands are supported on the Macintosh using Apple events. However,
be careful because the application you want to launch from the Host
command must be Apple event aware! Not all applications are.
16. Host commands must be rewritten for each platform.
17. If your application references another file, there is a good chance that
you may have hardcoded the path to that file in your application. All
hardcoded paths in your applications must be rewritten for that specific
platform. Also note the difference in specifying working directories
between Mac and Windows: on the Mac, you must add
FORMS40_PATH/FORMS45_PATH, REP_PATH, and OG20_PATH to config.ora. In
Windows, you must specify them in the Program Manager.
18. It is recommended that you store any external objects (e.g. images,
sounds, etc.) in the database to avoid the path problem mentioned above.
19. Keep in mind that fonts look different on different platforms. If you
want a polished-looking application, change the fonts to look good on that
specific platform. Oracle plans to implement a user-definable font
mapping table in a future release of Forms. This will allow users to
specify the font mapping when transferring an application from one
platform to another.
20. The same goes for colors. A color that looks nice on a Mac may not
necessarily look nice on a Windows machine. This is a minor detail, but
worth keeping in mind.
21. Keep in mind the monitors that will be used to run the application.
Code to the lowest common denominator for size, resolution, and depth.
22. Sound files, as long as they are stored in the Oracle Sound format, are
portable.
23. In Forms, iconic buttons are not portable. The icon files must be created
for each platform.
24. Do not use messages with explicit references to the keyboard, such as:
"Hit the F3 key for more information.". Key mappings will changed based on
the platform the form is running on.
For additional information, see:
Oracle Support Bulletin 106690.757 "APPLE: TIPS FOR WRITING PORTABLE CODE"
COLORS:
=======
Because end-users spend a significant amount of each day using the screens
you design, you may want to consult with a human factors engineer for help
with choosing colors that are both easy to use and aesthetically pleasing.
Research shows that black text on various light-colored backgrounds provides
the most contrast for users.
You may want to choose three separate light background colors to signal
three categories of information, such as the main window, popup windows,
and small objects, such as buttons and LOVs.
To ensure cross-platform consistency, you will want to test the colors you
choose to be sure they are effective on all platforms.
Color coding of fields is only useful if the user is trained in the meaning
of the colors and uses a monitor that can render them accurately. To avoid
problems with monochrome and character mode terminals:
* Test each color and color combination to make sure that all widgets and
labels are visible on both color and monochrome monitors.
* Use color redundantly; color should never be the only cue to a specific
meaning. For example, in an accounting application, negative amounts
might be shown in red, but they should also be preceded by a minus sign.
Limiting the use of color is essential for portability. Keep in mind the
characteristics of the monitors used to run the application. Code for the
lowest common denominator for size, resolution, depth and color.
* A 4-bit VGA monitor will limit your color selection.
* MS Windows GUI objects can use only one of 16 colors, so even though Oracle
Forms provides a 256 color palette, choose the color from the MS Windows
16-color palette.
* If your application must run on both color and monochrome monitors, use
a monochromatic color scheme, with a color palette such as black, white,
light gray and dark blue.
Another approach is to start with one master template containing all the
application libraries, any standard referenced objects, and the standard
color palette. By using this template as a starting point, each form will
include the standard color palette.
Limit of 20 Colors on Windows Widgets:
--------------------------------------
Sometimes after you create and apply a visual attribute to a button on Motif
then port the application to MS-Windows, the button changes color completely
(i.e. from gray to green!). This is not an Oracle Forms bug but a problem
with the MS-Windows GUI interface. The problem lies in the fact that all
MS-Windows widgets can only take on one of twenty different colors, determined
by the windows system palette. If the color specified is not one of the
colors in this system palette, Windows will color the widget with a color that
closely matches.
The workaround to this problem is to either:
1. Make sure all items use a color which exists in the MS Windows system
palette, so the color is rendered correctly on MS Windows.
2. If your color does not exist in the MS-Windows color palette
then change one of the system palette colors so that it becomes
your desired color. This can be done by using the color editor
in the 'Control Panel'.
Colorwashing in Image Intensive Oracle Tools Applications:
----------------------------------------------------------
Colorwashing is a condition which can occur in color bitmapped
environments, such as Motif and Windows. Colorwashing occurs when
two applications want to display more colors simultaneously than
the graphics hardware is capable of. The windowing system usually
then decides that it should only display the correct colors for
the active application. The effect of this is that other applications
will not be displayed with the colors requested but take on 'other' colors.
The mechanism most systems adopt is to assign a private color map, or color
palette, to each application and switch between color maps when the
application is brought into focus.
A color map is an area of memory where GUI systems map logical color numbers
to hardware color codes.
For example:
Color 0001 to hardware RGB values Red=255, Green=0 and Blue=0.
Examples of applications which will experience colorwashing problems are
applications which display distinct high quality graphical images with many
colors. Moving the mouse between the two such images may make the active
image be displayed in its correct colors and the inactive images displayed in
incorrect colors.
The reason colorwashing becomes more apparent when you use Oracle Forms is
that when any GUI Oracle Tools application starts up, it allocates a 216 color
palette. Thus, if another application wishes to use any color not in the 216
colors allocated by the Oracle Tools product, it needs to have its own private
color palette, which then causes colorwashing.
The impact of colorwashing is more pronounced on Motif than it is on
MS-Windows. This is because on Motif the Window decorations, window borders,
bevels and menu bar colors are all part of the same, modifiable color palette.
On MS-Windows, the window decorations are created from the standard Windows
system color palette, which cannot be changed dynamically by other
applications. Therefore, colorwashing on Motif can cause the whole
application, inside the window and the window itself, to change color. On
MS-Windows, only the inside of the window actually changes color.
The workaround is to modify the color palette within the Oracle Tools
application so the palette has about a dozen unique colors
and the remainder of the palette is black. This has the effect of restricting
the number of unique colors allocated by the Oracle Tools application, which
reduces the probability of colorwashing.
Number of Colors Available on MS-Windows:
-----------------------------------------
Many MS-Windows machines sacrifice colors for screen resolution. It is common
for a video card with only 512K of video memory to allow good resolutions
(e.g. 800x600 and 1024x768) but only allow a limited number of colors on
screen simultaneously (e.g. 16 colors or even 4!). However, this is becoming
increasingly rare. Most PC's capable of running the Oracle Tools tend to have
video cards which can display at least 256 colors with resolutions of 800x600.
This problem tends not to exist on the Macintosh or OSF/Motif hardware because
the video hardware is usually either Monochrome or full 256 color.
Hence, when you develop applications to run on a range of hardware
where the number of colors can vary, you should use the lowest common
denominator for the number of colors used in the application.
Running Color Applications on a Monochrome Display:
---------------------------------------------------
When you run an application which displays items in color, note that the
colors will 'snap' themselves to either 'black' or 'white' on a Monochrome
display. Thus, ensure that two dark colors are not used as the background and
foreground respectively for any form item.
FONTS:
======
Choosing Fonts which are Available on All Ports:
------------------------------------------------
One of the most common problems in porting applications between
GUI platforms/interfaces is matching fonts. Often a developer has designed
an application on OSF/Motif and chosen a X11 font. When running that
application on Windows, the developer finds that the fonts look different,
perhaps too large or too small.
What has happened here is that the developer has chosen a font which exists on
OSF/Motif but does not exist on MS-Windows. The Oracle Toolkit then tries to
find a font which is the closest match. However, the font matching mechanism
is not foolproof and sometimes chooses a font which will not look right.
The developer then needs to edit the Forms application on the destination port
and choose fonts which fit the space allocated to them on the canvas.
However, this does mean that potentially two copies of the .fmb need to be
maintained.
The latest releases of Oracle Forms has addressed this issue by allowing
developers to assign aliases to fonts. On MS-Windows, the developer needs
only to enter various lines in the oracle.ini file, showing that any
references to font Y should be mapped to GUI font X.
For example:
Font Aliasing in the oracle.ini file
/* Replace all Arial fonts with a Courier font */
Arial = Courier
/* Replace all 10 point Arial fonts with a 15 point Courier font */
Arial.10 = Courier.15
/* Replace all 10 point bold Arial fonts with a 15 point medium
Courier font */
Arial.10..Bold = Courier.15..Medium
Adopt one or both of the following strategies to aid porting an application
from one GUI to another.
Strategy #1:
Identify which fonts are available on each of the destination ports
and only use those which are common to all ports.
Strategy #2:
Identify which fonts are close matches and then use the Oracle Forms
font aliasing mechanism to ensure the fonts are used at the correct time.
If you are porting between MS-Windows and Macintosh, remember that both
Microsoft True Type Fonts and Adobe type fonts are also available on the Mac.
The following table will help to achieve satisfactory results with a font
aliasing strategy.
------------------------------------------------------------------------
Prompts Titles Textual
and Data Buttons
------------------------------------------------------------------------
Motif Helvetica Helvetica Helvetica
10 10 10
Point Medium Point Bold Point Bold
------------------------------------------------------------------------
MS-Window MS Sans Serif MS Sans Serif MS Sans Serif
10 10 10
Point Medium Point Bold Point Bold
------------------------------------------------------------------------
Macintosh Geneva Geneva Chicago
12 Point 10 Point 12 Point
Medium Bold Medium
------------------------------------------------------------------------
Using the Default Font Mechanism:
---------------------------------
Since Oracle Forms 4.0.12, there has been a mechanism of controlling
the font used in an application called 'Default Font Scaling'. All text item
fonts are left at default, and the font used depends on a system dependent
setting. This only works when the form is in the character cell coordinate
system as it was originally intended to be used with applications upgraded
from SQL*Forms 3.0. However, it can be used to control the font displayed
by the application.
On Mac:
Set the variable 'FORMS40_DEFAULTFONT' (FORMS45_DEFAULTFONT for 4.5)
in the config.ora file to a valid font name.
On Motif:
Set the resource 'Tk2Motif*fontList : <Font>' in the Tk2Motif file where
<Font> is the font name obtained from xlsfonts.
On Windows:
Set the variable 'FORMS40_DEFAULTFONT' in the oracle.ini file to
a valid font name.
With Oracle Forms 4.0.13 and above, do not use default font scaling for this
purpose. Use the font aliasing instead.
Running the Same Form on Different X11R4 and X11R5 XServers:
------------------------------------------------------------
When creating Oracle Forms applications using the OSF/Motif environment,
remember that every vendor and every release of X11 XServer software may, or
may not, have the same set of fonts available. If so, you can usually copy
the missing font files and create a new font directory containing the common
fonts. The developer should check with the XServer vendor regarding any
copyright issues.
Another method of sharing fonts on X11R5 based Unix XServers is to set up one
of the machines as a font server. Every other client machine can then access
the font server's standard set of fonts by changing its font path to include
the designated font server machine.
Setting Up a UNIX Machine to Act as a Font Server:
--------------------------------------------------
Setting up a Unix machine to act as a font server is usually quite
straightforward because most of the configuration has been already
done by the hardware vendor.
The basic steps are:
1. Check that the configuration file exists. It is usually found in the
'/usr/lib/X11/fs' directory and called 'config'.
2. Start the font server, logging in as root, by executing the
following command:
$ fs -config /usr/lib/X11/fs/config
The -config option allows you to specify a different path for the
configuration file.
3. To enable an X11R5 XServer to use the font server,
use the following command:
$ xset +fp tcp/pegasus:7000
Where pegasus is the hostname of the font server machine and
7000 is the port allocated in the font server configuration file.
Other Issues:
-------------
* Courier, although included with the basic system software, is *not*
always available on the Mac (in fact, only Geneva and Chicago are required).
Mac and Windows users may not like Courier - they usually expect MS
Sans Serif and Geneva/Chicago. Helvetica is probably the most common
font between Mac and Windows; however, the literal name of the font
is sometimes different on Windows, so it does not get ported. In addition,
small point sizes of Helvetica can be difficult to read on the screen.
* Use real coordinates, but snap things to a character cell grid.
This allows you to do things like make buttons 150% of the height of a
text item on Motif and make scroll bars 20 pixels wide on Mac.
* Keep in mind that fonts look different on different platforms.
If you want a polished-looking application, change the fonts to look good
on that specific platform. Oracle plans to implement a user-definable
font mapping table in a future release of Forms. This will allow users to
specify the font mapping when transferring an application from one platform
to another.
* Check the syntax and availability of fonts from platform to platform
(i.e.. , Courier is on available on both Windows and Mac)
* To set fonts quickly, use visual attributes. A visual attribute allows you
to define a set of characteristics (e.g. font, size, color) for an object.
When you change the definition of the visual attribute, any object using
that assignment will be updated. Currently, you can set visual attributes
of objects like fields, but not boilerplate text. You can define visual
attributes in a particular form, or you may copy or reference visual
attributes defined in another form.
Font Aliasing:
--------------
Font aliasing lets you use the uifont.ali file to specify what cross-platform
font substitution you prefer. Each platform will have a separate
uifont.ali file to define font substitution.
For example:
1. You develop on MS Windows using the MS Sans Serif font.
To run on UNIX, add this line to the uifont.ali file:
MS Sans Serif=Helvetica
2. You develop on UNIX using the Helvetica font.
To run on MS Windows, add this line to the uifont.ali file:
Helvetica=MS Sans Serif
3. You develop on UNIX using the Helvetica font.
To run on Macintosh, add this line to the uifont.ali file:
Helvetica=Geneva
When you develop portable applications, pay particular attention to your
choice of fonts for text items and boilerplate items.
Check first for availability of the font you plan to use. Is it available
on all platforms the Forms application will be run on? Test your font choices
on each platform. Fonts with the same name can have different appearances on
different platforms. For a polished appearance, choose the font that looks
best on that platform. Use font aliasing to specify font mapping when porting
an application from one platform to another.
In the past, many portable applications used Courier, a disproportional
font. However, using Courier has several disadvantages:
* Courier is not available on all platforms (only Geneva and Chicago are
required on Macintosh).
* GUI users may expect proportional fonts and reject disproportional fonts.
To meet user expectations for a proportional font, use:
* MS Windows: MS Sans Serif
* Motif: Helvetica
* Macintosh: Geneva and Chicago
Using named Visual Attributes to set defaults like font and color so that
they change from platform to platform works only for Oracle Forms objects.
Boilerplate text visual attributes remain static. To specify cross-platform
font substitution, use font aliasing. Use named Visual Attributes to
change colors dynamically at runtime.
Installing a Font Under X-Windows/Motif:
----------------------------------------
The specific font should be available from the server. Check the font by
running "xlsfonts" at the command line and looking for the font name
in the list of returned fonts. Second, the Oracle Tools only look at fonts
from the ISO8859 registry. If the next-to-the-last component of the font
is *not* "iso8859", the font will not be used by the Oracle Tools.
Example of a font listing that will be used:
-adobe-courier-bold-o-normal--24-240-75-75-m-150-iso8859-1
Example of a font listing that will not be used:
-adobe-courier-bold-o-normal--24-240-75-75-m-150-hp-roman8
If the specific font does not have ISO8859 registry, it will not be
usable by any of the Oracle Tools. Fonts that have an ISO8859 registry
are automatically included in the font menu at the time of Oracle Tools
startup. Note also that if you add the font to the server after starting
any Oracle Tool, you must restart the Oracle Tool for the new font to appear
in the font menu.
For additional Information, refer to the following Oracle Support Bulletins:
103381.962 (V4) WINDOWS AND MOTIF ENVIRONMENT
106690.184 (V4) Tk2Motif: The Relationship Between CDE and X Windows
106937.776 SETTING X RESOURCES AND TK2MOTIF
108354.401 WIN: FONT ALIASING AND DEFAULT FONTS
WINDOW SIZE:
============
Developing portable applications requires limiting the size of windows.
For example, you may have to keep the window size small enough to
accommodate laptop users.
* Applications that must run in character mode should be designed to
support a grid of 80 x 22 cells, plus 2 lines for the console
(message and status area).
* To avoid scrolling, applications that must run on VGA and SVGA monitors
must fit within their respective window size constraints.
ICONS:
======
Icons can be used to identify windows, menu items and buttons. While
icons are essential in GUI design, they are not inherently portable.
Hence, if you are developing cross-platform applications, you may want
to limit the number of icons used for the following reasons:
* Icon files are not portable, so you will need a complete set of icon
files for each platform.
* Image size for all bitmap images must be designed to accommodate the lowest
resolution on the platform. For example, a PC with VGA resolution
will allow fewer pixels for rendering an image than a PC with SVGA
resolution. Therefore, developing in VGA and porting to SVGA works better
than developing in SVGA and porting to VGA.
* Icons will need to be tested on a platform-by-platform basis.
Unfortunately, the specific icon files are not portable across the different
GUI environments, and there are no readily available tools to convert the icon
files from one format used by one GUI to another. The actual design of the
icons, however, can be ported. It simply requires recreating the icons on the
target GUI platform.
Note also that prior to Developer/2000, Oracle Tools in the OSF/Motif
environment only support monochrome icons, whereas the Macintosh
and MS-Windows environments support color icons. This further complicates
porting icons to different environments.
The best approach is to create a separate set of icons for each environment,
but ensure that the icon file names are kept the same. This normally does not
prove to be a major problem; developers usually direct their efforts to
creating the look and feel of icons as opposed to implementing them in a
particular environment.
Icon Sizes and Colors:
----------------------
Icon sizes tend not be a problem when porting; however, the amount of color
used in icons can prove to be a problem, particularly if the icons are
initially designed as small icons. If the small icons rely heavily on color,
there is a problem in porting to a monochrome environment, such as OSF/Motif.
Often there is simply not enough space in the designated area to create a
monochrome icon identical to the original color icon. The best approach here
is to either make the icons larger in the color environment, thus leaving
space for the monochrome environment, or to create a completely separate set
of icons.
Environment Variables Associated with Icons:
--------------------------------------------
When Oracle Forms reference an icons, it searches for the icon files on the
local file system. The following list describes the different approach each
operating environment uses for locating icon files.
On OSF/Motif:
The environment variable 'TK2_ICON' needs to point to
the directory where the icons are stored.
On MS-Windows:
For Oracle Forms 4.0.X, the oracle.ini variable 'TK20_ICON' needs to point to
the directory where the icons are stored.
For Oracle Forms 4.5.X, the oracle.ini variable 'TK21_ICON' needs to point to
the directory where the icons are stored.
On Macintosh:
Store all icons in a folder called 'icons', which must be a submodel of the
folder where the Forms application was invoked.
FORM COORDINATE SYSTEM:
=======================
The coordinate system form module property controls both the size and position
of objects on the screen. Width and height of objects, as well as X and Y
coordinates, are interpreted according to the coordinate system. You could
set the coordinate system to character or real. Real coordinate units may be
set to inches, centimeters, pixels or points.
If you require GUI to character-mode portability and want to optimize for
GUI, set the coordinate system to real - either inches, centimeters or
points. These coordinate units are based on measurable distances rather
than number of physical dots, and therefore are more portable than
pixels, which change depending on screen resolution. The Real setting
provides maximum flexibility for proportional fonts but may require some
fine-tuning to avoid overlapping fields on the character-mode side.
If you want to optimize for character-mode, set the coordinate system to
character. This setting provides less flexibility for the proportional fonts
used on GUIs but lets you line up character cell boundaries exactly.
The following is a table giving the type of application and the coordinate
system that should be used:
GUI only Real: inches, centimeters or points
Character-mode only Character
Mixed character-mode and GUI:
- Optimize for GUI Real
- Optimize for character-mode Character
Logical DPI vs. Physical DPI:
-----------------------------
It is important to distinguish between logical dots per inch (DPI) and
physical dots per inch (DPI).
Logical dots per inch is known to the Oracle Tools software through the system
drivers. On a Windows machine, the driver for your video card "knows" that
the logical resolution is 96 dpi (or 120 dpi for the so-called "large-font"
mode of some super-VGSs). On a Mac, the logical resolution is usually 72 dpi,
although some special systems may offer 144 dpi.
The Oracle Tools will use this logical dpi resolution to draw objects. Thus,
this dpi value is the method by which inches/centimeters are converted to
pixels. For example: on a 72 dpi Mac, a 1-inch line will be rendered as 72
pixels.
The physical dpi resolution is the resolution of the monitor whereas the
logical resolution is the resolution of the video card. You can take the
monitor cable from a PC, unplug it, and then plug it into a larger monitor.
The software has no way to understand that. The inches are still being drawn
with the same number of pixels, which now appear larger because the number of
physical dots per inch has dropped.
To render something to its true (inch-based) size, you must arrange things so
that your physical monitor dpi and your logical driver dpi match. This is
easy to do on the Mac because the Mac specifies 72 dpi, making you set a
larger monitor to get more pixels on the display. On Windows, however, you
can switch between 640x480, 800x600 or 1024x768 all on the same multi-sync
monitor. The Windows driver continues to think that you are running 96 dpi.
If the monitor is physically 10 inches horizontally, then at 640x480, the
monitor is rendering 640/10 = 64 dpi. At 1024x768, it is rendering about 100
dpi. For Windows, getting the physical size to match the logical size is a
matter of setting the display resolution appropriate to your monitor. Thus,
use 640x480 only for laptops, 1024x768 for 12-14" screens and 1280x1024 for
larger monitors.
Pixel Coordinate Units:
-----------------------
Pixel is the LEAST portable coordinate system. The reason has to do with
fonts.
Font sizes are measured in points. A point must not be confused with a
dot or pixel. A point is a typographic unit of measure left over from the
days of manual typesetting. 1 point = 1/72 inch, as measured from the
baseline of the text to the top of the highest character in the font.
For example:
If you select a 10-point font for your textual boilerplate, then these textual
items will be 10/72" high.
On a 72 (logical) dpi Mac, this means the text will be drawn 10 pixels high.
On a 96 (logical) dpi Windows machine, this text will be 13 pixels high (10/72
* 96 = 13.3).
If you have designed the form in pixels, the font will scale with the dpi
resolution on different platforms, while the locations of your items on the
screen will not scale. This can cause graphical objects, such as boilerplate
lines, to either overlap or to have big blank areas when run at a resolution
other than the design resolution.
Fonts cannot be specified in pixels, at least, not from Oracle Forms or any
other application. The only way to ensure proper scaling is to use a
logical measure, which means points, inches or centimeters but never
pixels.
Real Units vs. Character Units:
-------------------------------
1 inch = 2.54 cm = 72 points.
Inches are more convenient to work with than points. Converting font sizes to
inches is easier than converting to centimeters.
(10 point font = 10/72 inches = .353 cm).
Here are the reasons that character cells do not work:
MS Windows standards recommend that a button height be sized 150% that of a
text item. Using character cell coordinates you cannoy do this.
Fonts are specified in points, which are related to inches
(1 point = 1/72 inch), and screen resolutions are in dots per inch. Hence, it
makes sense to work with a coordinate system that all objects understand.
On Personal Computers, character coordinates are not portable between
different screen drivers, especially with SMALL and LARGE fonts. If you
develop with SMALL fonts and run the application on a PC with LARGE fonts
installed, many forms look scrambled.
MONITORS:
=========
On the MS-Windows platform, if you draw a 1-inch line on a PC with a 14"
display and exchange the display, not the video card, with a 17" display, you
would find that the line is no longer 1 inch in length but slightly longer.
The reason is that the PC architecture has no way of knowing the screen
dimensions or the number of dots per inch(dpi) that the screen is capable of
producing. MS-Windows actually fixes the DPI setting to 96dpi.
Porting to Different Physical Screen Sizes:
-------------------------------------------
This problem is a bigger issue when porting an Oracle Forms application from a
PC running with a low resolution screen (e.g. Standard VGA 640x480 pixels) to
a high resolution screen (e.g. superVGA 1024x768) or when porting an Oracle
Forms application from PC-Windows to an OSF/Motif Workstation with large
screen.
Unfortunately, a workaround of using the real coordinate system is not really
suitable because font sizes are measured in "points". A point must not be
confused with a dot or pixel. A point is a typographic unit of measure left
over from the days of manual typesetting. 1 point = 1/72 inch, as measured
from the baseline of the text to the top of the highest character in the font.
For example:
If you select a 10-point font for your textual boilerplate, then these textual
items will be 10/72" high.
On a 72 (logical) dpi Mac, this means the text will be drawn 10 pixels high.
On a 96 (logical) dpi Windows machine, this text will be 13 pixels high
(10/72 * 96 = 13.3).
If you have designed the form in pixels, the font will scale with the dpi
resolution on different platforms, while the locations of your items on the
screen will not scale. This can cause graphical objects, such as boilerplate
lines, to either overlap or to have big blank areas when run at a resolution
other than the design resolution.
This problem does not occur on the Macintosh or OSF/Motif platform. On the
Macintosh, the DPI value is fixed at 72 DPI; if you want more pixels on the
screen you simply need to get a larger monitor. On OSF/Motif, the operating
system is closely coupled with the graphics hardware system and is able to
identify the dimensions and capabilities of the screen device.
VGS Rounding When Porting from VGA to SVGA:
-------------------------------------------
If you port an application from SVGA to VGA and have used boilerplate
graphics, you may encounter a problem known as 'VGS Rounding'. When VGS
rounding occurs, lines move slightly out of place by a matter of pixels. This
is due to the differences in which MS-Windows manages its display on different
screen resolutions. The problem often crops up when trying to emulate a
windows style bevel, i.e. two rectangles offset by a few pixels. The outcome
is that the bevel no longer looks like a bevel but two very badly offset
rectangles.
If you expect your application to be used in different MS-Windows
screen resolutions then it is wise to either:
1. Avoid lines which need to be accurately placed near each other
2. Do not use boilerplate lines at all
If you use option 1, you can still get a very nice, portable, boxing effect by
ensuring that the edges are not next to each other but are placed near each
other, leaving a gap.
Exclusive Windows MDI Club:
---------------------------
The MS Windows environment has a unique model of operation called 'Multiple
Document Interface' or MDI interface. This is a visual model where an
application has one window encompassing all other windows. Many MS Windows
applications use this model. The most common are Word Processors, where the
user wants to have many windows open, but only one menu.
One of the advantages of an application written to the MDI model is that the
application and its child windows are self contained. However, the
disadvantages, in DCE porting terms, is that MS-Windows is the only platform
which supports the model. The other most notable disadvantage of the Windows
MDI model is that each MDI Child window cannot have its own menu bar; only the
MDI frame window can have a menu bar. As the user navigates between windows,
the top MDI frame menu bar changes accordingly. This flashing menu bar can be
confusing for some users.
Oracle Forms on the MS Windows uses the MDI frame to display the status bar at
the bottom of the screen and a single menu bar at the top. The MDI frame also
contains the 'Root Window'.
Because there is no MDI feature, the Root Window is displayed as a separate
window which contains the status bar, and each subsequent window contains its
own menu bar. When porting an application from MS-Windows to OSF/Motif or
Macintosh, developers will notice that the amount of space available
vertically is reduced. The net effect of this is that some items may not
actually be visible. Often buttons are affected because many GUI design
standards dictate that buttons should be placed at the bottom of the window.
The reason for this reduction in vertical space is that space for the menu has
not been taken into account when the application was originally designed.
There are two basic workarounds available to the developer:
1. At start-up, identify the platform the form is being deployed on. Use the
get_application_property built-in then resize the windows accordingly.
The implementation strategy to enable this would is to have a table stored
in a record group. This table would contain the various values for the
window sizes and positions on canvases for the different GUI interfaces.
Table of Changes to be Made to Windows When Porting from GUI-GUI:
-----------------------------------------------------------------
Window Canvas
-----------------------------------------------------------------
Port Window Height Width Xpos Ypos
-----------------------------------------------------------------
MS-Windows Window1 10.00 3.00 2.00 2.00
OSF/Motif Window1 11.00 3.00 1.00 1.00
Macintosh Window1 11.00 3.00 1.00 1.00
-----------------------------------------------------------------
Scan this table in a When-New-Form-Instance trigger to set the window
sizes appropriately. However, this does have the disadvantage of a
performance hit at form start-up.
2. The second workaround is to simply leave enough space at the bottom of the
windows to allow for any space reductions due to the menu bar being
displayed.
However, both of the above workarounds rely on knowing the size of the menu
bar in advance. You can change the size of the menu bar in OSF/Motif by
changing the default font, so the size changes accordingly.
To summarize:
* Know your display devices (i.e. if display is using 4-bit VGA. know to use
colors in this range)
* The only solution for monochrome and color support in a single form
is to basically use a monochromatic color scheme. For example, use a
color palette consisting of black, white, light gray and dark blue.
Note also that widgets can take on only 1 of 16 colors on MS Windows.
* Keep in mind monitors that will be used to run the application.
Code to the lowest common denominator for size, resolution and depth.
* The same goes for colors. A color that looks nice on a Mac may not
necessarily look nice on a Windows machine. This is a minor detail, but
worth keeping in mind.
HOST(), USER-EXITS, FILENAMES AND OS DEPENDENT FUNCTIONS:
=========================================================
Programmatic interfaces (e.g. PL/SQL & User exits), operating system commands
and HOST() built-in calls will almost certainly need to be rewritten. Two
methods can be employed to minimize the porting effect.
Method 1:
Create and call 'script' files from the HOST() built-in instead of calling the
operating system commands themselves. By creating these script files, a black
box implementation is achieved. You only need to call the script with any
necessary arguments, and leave all the operating system dependent commands in
the script itself.
Method 2:
Within the application, create a single procedure that determines what
operating system the application is running on. The procedure then executes
the appropriate host commands. The advantage is that you can keep all the
different host commands contained within the Oracle Forms application;
however, this requires more code and extra maintenance costs.
Issuing HOST('command', NO_SCREEN):
-----------------------------------
If you attempt to issue a HOST command and supply the NO_SCREEN option on MS
Windows, Oracle Forms appears to ignore the NO_SCREEN option. This is
unfortunately a limitation of running the application in the MS Windows
environment. The effect observed on MS Windows is that the whole screen
clears itself. This problem is not an issue on the OSF/Motif or Macintosh
port of Oracle Forms.
When you call an MS-DOS application from Oracle Forms on MS-Windows, notice
that the screen will be cleared during the execution of the MS-DOS application.
For example:
To execute a batch application called 'sendmail.bat', you might be tempted to
use the following PL/SQL code in an Oracle Forms trigger:
HOST('sendmail.bat', NO_SCREEN);
If this HOST command were run, MS Windows would do the following:
- Clear the screen.
- Change to a text video mode.
- Execute the batch program.
- After 'sendmail.bat' has terminated, control returns to MS-Windows,
- Switch back to a video graphics mode.
- Redraw the screen.
The time that MS Windows takes to clear the screen, execute the MS-DOS program
and return to MS Windows could be quite considerable. In addition, Oracle
Forms seems to have ignored the NO_SCREEN parameter. Unfortunately, this
behavior is inherent to running an MS-DOS application on the MS-Windows
environment. The same behavior occurs from the MS Windows File Manager if you
try to execute the same MS-DOS application.
The effect does not occur on OSF/Motif or Macintosh platforms.
Oracle Forms Runtime ignores the NO_SCREEN parameter on the MS Windows
environment, but Oracle Forms Designer accepts it for cross-platform PL/SQL
source compatibility. Examples of cross-platform PL/SQL compatibility
include: an Oracle Forms character mode application originally for UNIX, and
upgraded SQL*Forms v3 forms where the NO_SCREEN parameter is used.
MS Windows .PIF Files:
----------------------
Fortunately, MS Windows provides a partial solution to this problem. You can
create program information files (.PIF files ), which tell MS Windows how to
execute a MS-DOS application. These files are created using the PIF Editor
which usually resides in the 'Main' program group in MS Windows.
The parameters in PIF files include: the executable filename, the executable
working directory, the memory required, and, more importantly, whether the
application needs a window. To prevent the HOST command from causing a
complete window redraw, you can create a .PIF file. The .PIF file contains
all the information required to execute the application and explicitly
specifies that the application execute in a MS-Windows 'MS-DOS' Window.
To execute an MS-DOS application for which you have created a '.PIF' file,
execute the '.PIF' file instead of the executable. For example, an Oracle
Forms trigger would contain the following HOST() call:
HOST('C:\MSDOS\apps\myprog.pif');
If this were execute the executable directly, the same original behavior will
be seen. This is useful because the programmer can vary how to execute the
MS-DOS application.
To run without any windows displayed, execute a user exit which calls the
Windows SD directly. An example of this is shipped out with the demo user
exits in Forms on MS-Windows.
Filenames and Pathnames:
------------------------
Each operating system has its own style of addressing files and filenames.
Therefore, avoid using absolute filenames when invoking other forms, using
RUN_PRODUCT, or calling operating system commands. Instead of using hardcoded
paths, set up the proper environment variables to allow Forms runtime to find
the necessary forms files.
For instructions on how to set the environment variables for your particular
operating system, please see the Installation Guide. In addition, see Oracle
Support Bulletin 107330.728 for information regarding environment variables
used by Oracle Tools.
Note that some operating systems limit the size of the filename which can be
specified and/or have a case-sensitive filename. In these circumstances,
ensure the following:
1. Filenames should conform to the operating system which has the smallest
filename limit.
2. Filenames should always be kept in one case, either uppercase or lowercase.
User Exits:
-----------
You will most likely need to modify user exits on a per platform basis. The
amount of modification required depends on what the user exit does
functionally. Make sure to write the code in a portable manner. In addition,
if a user exit takes advantage of any platform-specific feature, such as Unix
pipes or MS Windows SDK calls, then you will need to rewrite this.
Regardless of how portable the code is, you will need to be recompile and
relink it on each platform. For information regarding compiling and linking
user exits on a particular hardware, please refer to the port-specific
documentation.
A common method of maintaining one source in the C programming language is to
use the C preprocessor directives: #define, #ifdef, #endif and #elsif. Use
these directives to specify a 'definition' at compile time, which can modify
the code by hiding some segments of code from the compiler and showing others.
For example: A fragment of a sample user exit
/* Function to calculate number of users on the machine at
this present time */
#ifdef WINDOWS_PORT
/* Using MS Windows implies there is just one user on the machine;
thus, return 1 */
return(1);
#elsif MOTIF_PORT
/* Execute operating system function to determine number of users
on the machine */
...
...port-specific code
...
#elsif MAC_PORT
/* Same as windows port; return 1 */
return (1);
#endif
If you compile this code with the definition 'MOTIF_PORT', you only compile
the lines relevant to the Motif port.
For more information on the C preprocessor directives, please see the system
documentation for the C compiler used.
Multiple Oracle Tools Runtime Applications on MS-Windows:
---------------------------------------------------------
On the MS Windows port, user exits are dynamically loaded from .dll files.
The advantage is that the Oracle application does not need to be relinked.
The disadvantage is that if many distinct applications on the system require
completely different sets of user exits, all the user exits must reside in one
file. For Oracle Forms on MS Windows, this file is called 'f40xtb.dll'.
This problem does not exist on the UNIX, VMS or Macintosh platforms because
you can create a statically linked executable (an executable that does not
require any additional runtime libraries).
For additional information, refer to the following Oracle Support Bulletins:
107330.728 (V4.0,4.5/V2.0,2.5) Environment Variables
107448.325 WIN: Creating User Exits for Forms 4.0.13
107448.352 WIN: Creating User Exits for Forms 4.5
108383.695 (V4/45) UNDERSTANDING HOST PACKAGE PROCEDURE
108932.421 USER EXITS FOR ORACLE FORMS 4.0 ON UNIX PLATFORMS
CHARACTER-MODE CONSIDERATIONS:
==============================
Oracle Forms can only run in character-mode on the Motif platforms. There is
no character-mode Oracle Forms runtime on the MS Windows or Macintosh
platforms.
Porting to character-mode platforms requires attention to both font and
functionality issues:
* Work within limitations caused by differences between proportional and
disproportional fonts.
* Use widget mnemonics to substitute for using the mouse to press buttons,
check boxes and radio buttons.
Running a character-mode application in Oracle Forms does not require any
special conversion. To run an application in character mode, run the .FMX
file from the GUI Forms Designer using the character-mode Forms Runtime.
Text Issues in Character-Mode:
------------------------------
If you are designing on a GUI platform and porting to a character-mode
platform, you will need a strategy to account for the difference between
proportional and disproportional fonts.
Count the characters in a prompt then compute the difference in length based
on the size of a character cell grid. Make sure you have that number of cells
available to display the prompt.
To approximate the screen layout in character-mode, use a monospaced font,
such as Courier on your GUI platform at design time. If you use a
proportional font, the spaces between labels and fields will be too large in
the bitmapped version or the labels and fields will overlap in the
character-mode version.
Aligning Boilerplate Text in Character-Mode:
--------------------------------------------
When you create an application to run in both GUI-mode and character-mode,
boilerplate text takes up more space when you use a monospaced font on a
character-mode platform than a proportional font on a GUI-mode platform.
Example 1: Single record block with labels to the left of text items
When boilerplate text is used for text item labels, most applications
call for the boilerplate text to be right-aligned, ending just before the
next item.
To implement this behavior in a portable manner:
1) Multiple-select all boilerplate text in the window.
2) Select Format->Drawing Options->Text
Oracle Forms displays the Text drawing options dialog
3) Select horizontal origin: At right.
Oracle Forms sets a snap point at the right.
4) Select Format->Alignment->Right.
Oracle Forms starts at the snap point and allows the text to expand
to the left.
Example 2: Multi-record block with labels above text items
In a multi-record block, most applications call for labels above text items.
To implement this behavior, follow the same steps as above, except select
Horizontal Origin: At left and Format->Alignment->Left.
Properties Restricted to Character-Mode Applications:
-----------------------------------------------------
The following properties are limited to character-mode applications or have
special restrictions related to character-mode applications:
* Help
* Hint (Menu Item)
* Identification
* Size
* Visual Attribute Type: Character Mode Logical Attribute.
FORM FUNCTIONALITY AND COMMON LIBRARIES:
========================================
When you are building portable applications, you may want to use the
GET_APPLICATION_PROPERTY built-in to return the following values:
* DISPLAY_HEIGHT
* DISPLAY_WIDTH
* OPERATING_SYSTEM
* USER_INTERFACE
For example, use GET_APPLICATION_PROPERTY(OPERATING_SYSTEM) to obtain the name
of the operating system the application is run on. Next, you can use the
When-New-Form-Instance trigger to set properties appropriate for the current
platform.
To implement portable form functionality, consider the following
recommendations:
* To call Oracle Reports, Oracle Graphics and Oracle Book from Oracle Forms,
use RUN_PRODUCT. Use the HOST built-in only for calling other external
applications.
* Avoid user exits that need to be rewritten or at least recompiled
depending on the platform.
* Isolate platform-specific functionality:
- MS Windows: DDE, OLE and VBX
- Macintosh: AppleEvents
* Be aware of differences in Macintosh functionality:
- Only text items are navigable. Other items, such as buttons, are
not navigable.
- Text item beveling does not apply. Raised and lowered looks the same.
BUTTONS:
========
Buttons are affected when you port between different environments. One of
the most common problems when porting buttons from MS Windows to OSF/Motif is
that the buttons appear to shrink in size. The main reason for this is that
the OSF/Motif port specifies a moat to be drawn around the button. This moat
can be used to highlight the button as a 'default button'. On MS Windows,
this is done with a darkened border instead of a moat.
The problem becomes much more apparent if the form being ported has a
multirow block with a button on each row. When this block is drawn on
Motif, the widgets (buttons) overlap each other. This is because the
button has only been allocated a limited amount of space, and there is
another button above and below each button. The eventual result is
that the button text is unreadable.
A simple workaround for the Motif port is to tell OSF/Motif to reverse
its strategy. Instead of showing default buttons and normal buttons
the same size and drawing a moat around each button allowing space for
the default indicator, make the default buttons smaller than the
normal buttons. This is accomplished by setting the following
resource in the Tk2Motif file:
Tk2Motif*expandNonDefaultButtons : True
What happens is that all buttons are expanded to fill the space
allocated for the default indicator, but default buttons end up caving
in on themselves, making themselves smaller.
For additional information on all topics, see:
Oracle Forms 4.5 Advanced Techniques, Chapter 9, Designing for Portability.