Connection Information

To perform the requested action, WordPress needs to access your web server. Please enter your FTP credentials to proceed. If you do not remember your credentials, you should contact your web host.

Connection Type

Planning the look of your application – PB Docs 70 – PowerBuilder Library

Planning the look of your application – PB Docs 70

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:

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:

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.

note.gif 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:

For example, to map the Times font to the Times New Roman
font, the specification is:

You can change the existing specifications or add your own.

The following sections describe how the substitute font is
chosen on each platform.

note.gif 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.

Document get from Powerbuilder help
Thank you for watching.
Was this article helpful?
Subscribe
Notify of
guest
0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x