Planning the look of your application
Each platform PowerBuilder runs on has an identifiable look
that marks its native applications as belonging to that system.
To a large extent, PowerBuilder adjusts the appearance of controls,
menus, and windows so that they look right on each platform.
However, you do have to be careful how you place controls
and how you handle fonts and text so that after PowerBuilder makes
these adjustments, the resulting windows and controls look correct
with nothing cut off or overlapping.
This section explains how differences between platforms affect
your choices when you are planning your application’s look.
These differences affect:
- How you place controls
in windows - Whether you choose a 3D look for controls
- How you use fonts
Placing controls inwindows
Layout
When you are laying out controls on a window, leave room around
the default button so that there is room for the thicker borders
used on UNIX systems. On Windows, the border is a slightly darkened
line and doesn’t take up extra room.
For more on window design, see “Window behavior “.
Text
Text on your controls is also an important consideration in
cross-platform design. Since the relative space used by a specific
font and size varies on different platforms, you have to take the
changes into account when you lay out controls.
For more on font size, see “Font size”.
Choosing a 3D lookfor controls
If you want to display a 3D look when your application runs
on one platform and a flatter look on another, you can use conditional
code to change the BorderStyle property and window’s background
color (BackColor property).
Controls and their borders
BorderStyle property For many controls, you specify whether they appear 3D with
the BorderStyle property. These controls include CheckBox, EditMask,
GroupBox, and RadioButton.
Border and BorderStyle properties Some controls have
both properties. The Border property lets you turn the border off
completely, letting the control blend with the background. You can
specify the 3D look by setting the BorderStyle property, but your
setting is ignored if the border is turned off. These controls include
DataWindow, DropDownListBox, Graph, ListBox, MultiLineEdit, OLE
2.0, Picture, SingleLineEdit, StaticText, and UserObject.
Changing the border style
There are two approaches for changing the 3D appearance of
controls:
- You can set their
BorderStyle property in the script that opens the window. - You can design an ancestor window and inherit a
window for each platform. In each of the descendent windows, you
can set the BorderStyle property appropriately.
Setting the BorderStyle property You
can use the GetEnvironment function to get the current platform
and make appropriate settings. In the following example, the border
style specified in the Window painter is StyleLowered!. The sample
code changes the border style of several controls if the platform
is Windows NT. You can use code like this in a window’s
Open event:
|
1 |
Environment lenv_env |
|
1 |
/* Change borders of controls based on platform */ |
|
1 |
GetEnvironment(lenv_env) |
|
1 |
IF lenv_env.OSType = WindowsNT! THEN |
|
1 |
sle_name.BorderStyle = StyleBox! |
|
1 |
cbx_status.BorderStyle = StyleBox! |
|
1 |
lb_select.BorderStyle = StyleBox! |
|
1 |
END IF |
Inheriting a window for each platform After you design
a window with the appropriate controls and event scripts, you can
create a descendent window for each platform that needs a different
design. Then in the event that opens the window (for example, the
application’s Open event or a menu’s Clicked event), you
can find out the current platform with the GetEnvironment function
and open the appropriate window.
Depending on the complexity of your application, you can have
a descendent window for each platform or use the ancestor window
for some platforms and a descendant for platforms that differ. For
example, if a window has buttons that typically have different labels
on Windows and UNIX, you might want to use the ancestor window on
Windows and create a descendent window for UNIX with different labels.
In this example, there are two descendent windows of the window
w_main. The sample code determines which window to open
based on the platform:
|
1 |
Environment lenv_env |
|
1 |
/* Open a different window based on platform */ |
|
1 |
GetEnvironment(lenv_env) |
|
1 |
IF lenv_env.OSType = Windows! or & |
|
1 |
lenv_env.OSType = WindowsNT! THEN |
|
1 |
Open(w_main_windows) |
|
1 |
ELSEIF lenv_env.OSType = Sol2! or & |
|
1 |
lenv_env.OSType = hpux! or & |
|
1 |
lenv_env.OSType = aix! THEN |
|
1 |
Open(w_main_unix) |
|
1 |
END IF |
Using fonts
Both the choice of fonts and the size of fonts can cause problems
in a cross-platform application. It is up to you to choose fonts
that look good in your window designs and to verify that on each
platform the corresponding fonts look good too.
The best approach is to select fonts that are available on
all platforms and make the fonts available to each user.
What font technology to use
You may or may not be able to control the font technology
your users use. This table compares the availability of the major
font technologies, TrueType and PostScript:
| Technology | Windows | UNIX |
|---|---|---|
| TrueType | Supported by operating system | May or may not be available |
| PostScript | Users need Adobe Type Manager | Non-PostScript fonts are substituted for display |
Migrating from Windows to UNIX On UNIX, users can choose whether to use scalable fonts. You
may be able to select point sizes carefully so the fonts will look
acceptable even if they do not use scalable fonts.
Testing is important No matter what fonts you choose, it is important to do cross-platform
testing early in the development process to make sure your choices
will work on all the target platforms.
When the specified fontis not available
When your application uses a font that does not exist on a
platform, PowerBuilder or the operating system tries to find a substitute.
Font mapping file
PowerBuilder provides a font mapping file on each platform that
maps commonly-used fonts to fonts that are usually available on
that platform. When an application uses a screen or printer font
that is unavailable, PowerBuilder looks in the [FontSubstitutes] section
of this file for a mapping. Each line in the file has the following
syntax:
|
1 |
<i>original_font</i>=<i>mapped_font</i> |
For example, to map the Times font to the Times New Roman
font, the specification is:
|
1 |
Times=Times New Roman |
You can change the existing specifications or add your own.
The following sections describe how the substitute font is
chosen on each platform.
The font name saved with the object When you move an object to another platform, the font name
stored as the value of an object’s property does not change
when PowerBuilder makes the substitution. The substitution is made
on the fly, and the saved font name stays the same unless you explicitly
change the font.
Fonts on Windows
On Windows, the font mapping file is called PBFNT70.INI
and is stored in the SybaseSharedPowerBuilder directory.
If a font is not available and there is no mapping for it in PBFNT70.INI,
Windows itself tries to find a font that matches the characteristics
of the missing font. The result may not be satisfactory.
Fonts on UNIX
On UNIX, the font mapping file is called .pbfnt70.ini
and is installed in the PowerBuilder installation directory. When
you or your system administrator install PowerBuilder, initialization
files should be copied from the PowerBuilder installation directory
to each user’s home directory.
Font mappings are also defined in the .WindU configuration
file and are usually the same in both files. The .WindU file has
separate sections for screen display and for PostScript and PCL
printers. You can change the default mappings and add your own mappings.
These are some of the default mappings:
| When the application uses this font and it is not available on UNIX |
PowerBuilder substitutes this font on UNIX |
|---|---|
| Arial | helvetica |
| MS Sans Serif | helvetica |
| Courier New | courier |
| Times New Roman | times |
If .pbfnt70.ini and .WindU have different mappings
for the same missing font, the mapping in .pbfnt70.ini
is used. For example, if .WindU maps Arial to Helvetica but .pbfnt70.ini
maps Arial to Geneva, Geneva will be substituted for Arial.
If .pbfnt70.ini maps a missing font to a font that
is mapped to another font in .WindU, the value in .WindU is substituted
for the missing font. For example, if .WindU maps Helv to Helvetica
and .pbfnt70.ini maps Haettenschweiler to Helv, Helvetica
will be substituted for Haettenschweiler.
Font size
Each of the platforms PowerBuilder supports has its own font
rendering engine. You will notice differences in the sizes of fonts
in relation to the controls when you move your application to another
platform. On UNIX, the same font
and point size appears slightly smaller than on Windows.
This means if you are developing your application on UNIX
and plan to port to Windows, you will want to leave extra room for
text in controls and DataWindows, both horizontally and vertically.
You will also want to avoid putting controls too close to the bottom
or right side of a window. If you do your development on Windows,
you might make your text a little larger if you plan to port to
UNIX.
Font settings in the database
When you specify a font in your database as an extended attribute
of a table, this font becomes the default for all columns of that
table in a DataWindow. Suppose you choose a font that exists on
only one platform and then move the database to another platform.
If you define more DataWindows on the second platform, you will
see the name of the font from the database in the DataWindow painter,
but a definition for that font won’t exist. To address
this issue, you can:
- Choose another font
in the DataWindow painter each time you define a DataWindow object. - Change the extended attributes for each column when
you move the database to another platform. The extended attributes
affect new DataWindows and DataWindows for which you run the DataWindow Extended
Attribute Synchronizer utility (DWEAS). - Select a font that exists on all your target platforms
when you initially set up extended attributes.