Conceptos PDF

R
Unify VISION:
Concepts
E 1995, 1996, 1998, 2000, 2002 Unify Corporation. All rights reserved.
No part of this document may be reproduced, transmitted, transcribed, stored in a retrieval system,
or translated into any language or computer language, in any form or by any means, electronic,
mechanical, magnetic, optical, chemical, manual or otherwise without the prior written consent of
Unify Corporation.
Unify Corporation makes no representations or warranties with respect to the contents of this
document and specifically disclaims any implied warranties of merchantability or fitness for any
particular purpose. Further, Unify Corporation reserves the right to revise this document and to
make changes from time to time in its content without being obligated to notify any person of such
revisions or changes.
The Software described in this document is furnished under a Software License Agreement. The
Software may be used or copied only in accordance with the terms of the license agreement. It is
against the law to copy the Software on tape, disk, or any other medium for any purpose other than
that described in the license agreement.
The Unify Corporation Publications Department values and appreciates any comments you may
have concerning our products or this document. Please address comments to:
Unify VISION Product Manager

Unify Corporation
2101 Arena Blvd. Suite 100
Sacramento, CA 958341922
(800) 4686439
(916) 9286400
FAX (916) 9286406
UNIFY, ACCELL, VISION, and the Unify Logo are registered trademarks of Unify Corporation.
DataServer is a trademark of Unify Corporation. UNIX is a registered trademark of The Open
Group in the United States and other countries. The X Window System is a product of the
Massachusetts Institute of Technology. Motif, OSF, and OSF/Motif are trademarks of Open
Software Foundation, Inc. SYBASE is a registered trademark, and SQL Server, DB_Library, and
Open Server are trademarks of Sybase, Inc. INFORMIX is a registered trademark of a subsidiary of
IBM. INGRES is a trademark of Computer Associates INternational, Inc. ORACLE is a registered
trademark of Oracle Corporation. Sun is a registered trademark, and SunView, Sun_3, Sun_4,
X11/NeWS, SunOS, PC_NFS, and Open Windows are trademarks of Sun Microsystems. All
SPARC trademarks are trademarks or registered trademarks of SPARC International, Inc.
SPARCstation is licensed exclusively to Sun Microsystems, Inc. Novell is a registered trademark of
Novell, Inc. Macintosh is a trademark of Apple Computer, Inc. Microsoft, MS, and Windows are
registered trademarksoff Microsoft. All other products or services mentioned herein may be
registered trademarks, trademarks, or service marks of their respective manufacturers, companies, or
organizations.
Part Number: 7365-06
2
Contents
About this manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1 Unify VISION feature overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Client/server architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Easy-to-use graphical rapid application development . . . . . . . . . . . . . . 15
Flexible transition to full object-oriented development . . . . . . . . . . . . . 16
Multi-tier, dynamic application partitioning . . . . . . . . . . . . . . . . . . . . . 17
ActiveX support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
VISION/Studio Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 Unify VISION objects, classes, and methods . . . . . . . . . . . . . . . . . . 21
Unify VISION objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Attributes and methods of an object . . . . . . . . . . . . . . . . . . . . . . . . . 22
Graphical and non-graphical objects . . . . . . . . . . . . . . . . . . . . . . . . 23
Using the terms object and class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Class definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
The foundation classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Class hierarchies and inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Base class and subclass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Overriding inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Types of methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Class libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
External references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
What to put in a class library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Shadow libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
The Unify VISION foundation classes . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 The application model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A simple and small application: what the user sees . . . . . . . . . . . . . . . . 36
Components of the simple application . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Physical appearance of a form . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Behavior of a form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Location of a form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3
Tool bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Menu bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Database Connection Map file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Help system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Form relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Accessing a database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
The basics of a partitioned application . . . . . . . . . . . . . . . . . . . . . . . . . 50
Application partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Partition groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Unify Object Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Benefits of partitioned applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
System services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Application services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Services and databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Services and transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Services and threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Replicated services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Replication groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Replication registries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Business events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Name services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
System management classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Communication within a partitioned application . . . . . . . . . . . . . . . . . . 65
Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Object references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Synchronous and asynchronous modes . . . . . . . . . . . . . . . . . . . . . . 65
4 Unify VISION: Concepts

ActiveX automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Architecture of a partitioned application environment . . . . . . . . . . . . . 68
VISION Console overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4 VISION Development Environment architecture . . . . . . . . . . . . . . 71
VISION Development Environment overview . . . . . . . . . . . . . . . . . . . 72
VISION Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
VISION Class Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
VISION Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
VISION Script Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
VISION Image Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
VISION compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
VISION Runtime Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
VISION Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Third-party tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Help system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5 Version control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
What is version control? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Version control systems and Unify VISION . . . . . . . . . . . . . . . . . . . . . 95
Benefits of version control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Which objects can be placed under version control? . . . . . . . . . . . . . . . 97
Version control methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6 Managing the application environment . . . . . . . . . . . . . . . . . . . . . . . 101
Organizing an application within VISION Development Environment 102
Viewing your application from the operating system level . . . . . . . . . . 108
Lock files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Setting attributes and preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Personal and shared preferences . . . . . . . . . . . . . . . . . . . . . . . . . 112
Contents 5
7 Application execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
VISION Runtime Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Database connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Displaying the forms of an application . . . . . . . . . . . . . . . . . . . . . . . . . 121
Form location at runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Form operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Field operations and field order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Field execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
The first field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Next fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Previous fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Form modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Selected sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Providing Unify VISION with row identification information . . . . . . . 137
Why row IDs are important . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Specifying row ID columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Using rules or triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
System information fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Drag and drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Contents 7
About this manual
This manual is one of a set that describes the Unify VISION application
development system. This manual, Unify VISION: Concepts, provides an
overview of Unify VISION components, applications, and environments
and describes basic application runtime execution.
Use this manual in conjunction with Unify VISION: 4GL Reference, which
provides detailed syntax for all features.
Using this manual
This manual is intended primarily for the application developer.

Throughout this manual, the word you refers to the application developer.
The word user refers to any person who will be using your completed
Unify VISION application.
Prerequisite experience
The Unify VISION application development software is a programming

tool intended for professional software developers. As a basis for
understanding and using Unify VISION, you must already be familiar
with the following subjects or technologies:
Fundamental data-processing concepts
One of the supported relational database management systems,
such as dBASE, Access, Watcom SQL, DB2, INFORMIX, UNIFY
DataServer, ORACLE, or SYBASE SQL Server
SQL (standard query language) concepts and syntax
Operating system interface and file structures

The C programming language (optional)
Object-oriented programming
9
Before you start
Before getting started with this manual, read and follow the instructions
given for installing and configuring Unify VISION, as described in the
following documents:
Windows installation instructions
Unify VISION: Installation Guide for UNIX
Conventions
This manual uses the following typographical conventions to differentiate
Unify VISION features:
Syntax
boldface Boldface words are literal strings that you must type
exactly as shown.
italic words Italic words indicate arguments, variables, numbers, or

expressions that you must provide. Examples are table
names, column names, and constants. Titles of manuals
are shown in italics, for example, Unify VISION:
Concepts.
UPPERCASE Boldface UPPERCASE words are Unify VISION reserved

words, such as attribute names, statements, and
preferences.
UPPERCASE Other UPPERCASE words represent Unify VISION data

types, such as FLOAT and TEXT.
! A right-pointing arrow represents the path to a command

on a cascading menu. For example, from the File menu,
New ! Form Class specifies that you can execute the
Form Class command by selecting it from the list of
menu options displayed for New.
variable The name of a developer-defined variable can be

enclosed by a pair of quotation marks. Variable names
are case sensitive: uppercase and lowercase letters are
not equivalent. For example, company_address and
Company_Address are two different variables.

$variable A dollar sign ($) prefix identifies a variable name.
function$ All Unify VISION system functions are suffixed by a

dollar sign ($). The dollar sign distinguishes a system
function from a developer-defined function. Do not
include a dollar sign when you call your own functions.
Windows The term Windows indicates Windows 95, Windows 98,

and Windows NT operating systems. Information that is
identified as specific to Windows 95 also applies to
Windows 98.
Narrative text
Manual Title Titles of manuals are shown in italics, for example, Unify
VISION: Concepts.
Title Chapter and section titles are enclosed by a pair of

quotation marks.
Special paragraphs
This manual contains specially marked paragraphs containing noteworthy

information:
Tip A tip contains a suggested action or other helpful information.
Warning A warning cautions against an action that could cause data loss or
damage to the database.
OO Principle An OO principle is a reference identified as [Taylor], and is quoted with

permission from Object-Oriented Technology: A Managers Guide by
David A. Taylor.
Related information Related Information tells you where to find more information about the
described topics.
About this manual 11

1
Unify VISION feature overview

Unify VISION is a powerful client/server development environment that
teams of application developers use to develop, deploy, and manage
high-end, scalable applications that can be run across multiple platforms.
This chapter describes the general features of Unify VISION:

Client/server architecture
Easy-to-use graphical rapid application development technology
Flexible transition to full object-oriented development
Multi-tier, dynamic application partitioning
ActiveX support
13
Client/server architecture
Unify VISION client/server architecture provides an advanced

development environment for the rapid development, deployment, and
management of complex, enterprise-wide applications.
Unify VISION client/server architecture has several characteristics:

Third-party tools can be integrated into Unify VISION. The
integrated tool appears as a component of the standard Unify
VISION tool set while you are developing your application. You
can also include the third-party tool when you deliver your
application.
Unify VISION is portable across different types of graphical user
interfaces (GUIs): Windows NT, Windows 95, and Motif/Common
Desktop Environment (CDE). Each developer working on a team
development project can work in a different GUI.
Database-dependent applications can be written to conform to
ANSI SQL and thereby retain a high level of portability across
various vendors databases.
An application created with Unify VISION can be run as a
partitioned application among multiple hosts on a network.

Easy-to-use graphical rapid application development
Unify VISION couples its powerful client/server architecture with a

flexible and easy-to-use graphical rapid application development
technology.
VISION Development Environment gives you easy access to everything

that you need to create, debug, and test applications. Applications consist
of components, represented as icons. In the environment, you can view
multiple application components, access development tools, and create an
application that is customized for the needs of the user.
Additionally, Unify VISION combines an event-driven, object-oriented

4GL, with highly automated functions for GUI programming and
database access. Using graphical dialogs and panels, you can specify the
visual components and properties of forms, as well as automatically
generating much of an applications underlying functionality, including:
Locking
Transaction management
Query-by-form
Form navigation
Form relationships
Chapter 1: Unify VISION feature overview 15

Flexible transition to full object-oriented development
The Unify VISION graphical class browser and tightly integrated script
editor (with outlining, error marking, and built-in class tree traversal)
provide a flexible transition to object-oriented development from a more
traditional programming approach.
Some of the advantages of this flexibility include:

Short learning curve, ensuring that both novices and seasoned
object practitioners alike are quickly productive and can realize the
promises and benefits of fully object-oriented development in an
automated, visual development environment.
Encourages reuse by making it easy to find previously built objects
in its team-based class library.
Maximizes the benefits of encapsulation, inheritance, and
polymorphism.
Related information For more information about the object-oriented development of

applications, see Unify VISION objects, classes, and methods on
page 21.

Multi-tier, dynamic application partitioning
The advanced application partitioning of Unify VISION allows you to

distribute application processing across clients and servers, optimizing
the performance of your desktop machines and network resources.
Some of the features of multi-tier, dynamic application partitioning

include:
Through the graphical VISION Console, managing and
dynamically redistributing partitions without halting the
application.
A global naming service that tracks object location enabling
automatic management of shared services.
Proactive event notification, allowing client-to-client and
server-to-client messaging without costly polling.
Replicated partition services, providing for failover, greater
scalability, and automatic load balancing.
Related information For information about partitioned applications, see The application
model on page 35.

ActiveX support
Unify VISION supports ActiveX containers on forms. These containers

can link to or embed compatible ActiveX objects, such as a Microsoft
Excel worksheet. In a partitioned application, Unify VISION provides full
ActiveX automation controller support, giving your applications the
ability to access the methods and attributes of local or remote ActiveX
servers through VISION 4GL.
Related information For information about ActiveX container classes, see Working with
other graphical classes in Unify VISION: Designer
For information about ActiveX automation, see ActiveX automation on

page 67.

VISION/Studio Integration
Studio was created specifically for web builders and application

developers who need to speed the deployment of departmentallevel,
databasedriven web applications. Unify VISION brings a powerful
client/server development environment that can be run across multiple
platforms. Together, they offer a comprehensive extranet development
environment.
Server-side components deployed as VISION AppServer services are

accessible within a web site built in VISION Studio. This mechanism is
based on the ActiveX component integration Unify VISION. You can
access Unify VISION services via a standard COM interface. Studio
provides a component registration process that retrieves all of the
properties, methods, and events from the TLB file (Type Library file).
Related information For more information about Unify VISION/Studio integration, see the
Unify VISION: Studio Users Guide under VISION Integration

2
Unify VISION objects, classes, and

methods
This chapter describes Unify VISION objects, classes, and methods.
Some information in this chapter is from Object-Oriented Technology:

A Managers Guide by David Taylor, and is cited as such. The complete
bibliography appears in About this manual.
21
Unify VISION objects
As it executes, a Unify VISION application is composed of a series of

objects. Some objects are visible in the user interface component of the
application, such as the forms, their tool bars, and menu bars. Some
objects are not visible, such as services or profiles.
Some of the visible objects, in turn, are built from other objects. For
instance, a form object usually contains one or more text field objects,
labels, buttons, and so forth.
Attributes and methods of an object
Most Unify VISION objects have a series of attributes and methods. The
attributes define the appearance of the object while the methods define
the behavior of the object. For example, a button object has:
A foreground and background color attribute
A button is an object with A label attribute, that specifies the characters on the button
attributes and methods
An ON CLICK method that is executed when a user presses the
button
Some Unify VISION objects have attributes and no methods, such as

partition profiles. A partition profile defines the runtime environment
settings for an application, such as which tool bar to provide.
OO principle An object is a software packet containing a collection of related data (in

the form of variables) and methods (procedures) for operating on that
data. [Taylor]
In Unify VISION, the variables of an object are the attributes. All objects
have attributes. Most objects have a set of predefined methods. Service
and form classes can also have developer-defined methods.

Graphical and non-graphical objects
Unify VISION objects can be divided into two categories: graphical

objects and non-graphical objects.
Graphical objects are entities that are visible when a user runs the
application: the menu bar, the tool bar, the forms, the fields, and trim
(boxes, lines, and images) on the form. Fields on a Unify VISION form
can be represented as check boxes, combo boxes, dropdown boxes, list
boxes, and others.
There are three types of non-graphical objects: services, global functions,

and profiles. Services are objects that are used to distribute application
A Unify VISION form object processing across a network. A service is comparable to a procedure. For
is a graphical object.
example, a print service might handle printing on behalf of several
clients; an airline reservations service might handle reservations for a
group of reservations clerks. A global function also performs a task,
however it is used by a particular class only.
Profiles are objects that specify environment information including how

to find other objects needed by the application. For example, a partition
profile specifies:
The name of the first form in the application
The name of the tool bar associated with the application
A partition group profile, used in partitioned applications only, specifies

information about partition group configuration.
Using the terms object and class
A Unify VISION object is technically an instance of a class. So, from a

single form class, multiple instances can be created at runtime. At design
time, it is classes that are designed. At runtime, it is objects that are
displayed.
In this manual set, the words instance or object are omitted when not
necessary to the information being presented. For example, a form object
or form instance is simply referred to as a form.
Chapter 2: Unify VISION objects, classes, and methods 23

Class definitions
A class definition is a template that is used at runtime to build Unify

VISION objects. The template lists each attribute of the object and the
methods defined for the object.
Every type of object in Unify VISION has a predefined class definition

that lists the attributes and methods for that class. For instance, the class
definition for a button object includes over 25 attributes that control
things like the button color, label, and location on the form. This class
definition also contains several predefined methods, which comprise the
behavior of the button at runtime. The methods are executed at runtime in
response to user actions such as clicking on the button. By default the
predefined methods perform no action; you add VISION 4GL statements
to define the actions for each method.
The following illustration shows how you can visualize the class
definition as a template for the button object. The light grey boxes
represent the parts of the template that are filled in at runtime to create
an instance of a button class, or more simply, a button object:
Attributes Methods
ACTION_NAME = some attribute setting ON CLICK
AUTO_ZOOM =
BACKGROUND = 4GL statements

DRAG_ALLOWED =
DRAG_DROP_ALLOWED =

ON CURRENT
DRAG_INVALID_ICON_NAME
4GL statements
=
FONT_FACE =
FONT_FAMILY = ON DOUBLE CLICK
FONT_SIZE =
4GL statements
FOREGROUND =
FYI_MESSAGE =
ON DRAG DROP
HEIGHT =
HELP_TAG = 4GL statements
LABEL_STRING =
OBJECT_ID =
... ...
VISIBLE =
WIDTH = ON NOT CURRENT
X= 4GL statements
Y=
OO principle A class is a template that defines the methods and variables to be

included in a particular type of object.[Taylor]
Unify VISION provides foundation classes that serve as master templates

for every type of Unify VISION object. The master template lists all

attributes for the class and all predefined methods. From that template,
you create a template that defines the attributes and methods for a
particular class definition.
The foundation classes
The classes available to you are initially defined by the Unify VISION
foundation classes. From any foundation class, you create a subclass in
which you can customize the default attributes and methods per your
requirements.
Related information For a list of the foundation classes, see Unify VISION foundation
classes on page 33.

Class hierarchies and inheritance
The purpose, and power, of classes in object-oriented programming is to

define classes in terms of other classes. This mechanism supports the
reuse of code, allowing you to use code (attribute settings and methods)
that has already been developed and tested.
Base class and subclass
To support code reuse, classes are defined in a tree-like structure called a

class hierarchy. In a class hierarchy, each class is defined as a specialized
version of a more general class. The specialized version is called the
subclass of the more general class, called the base class.
foundation In a class hierarchy drawing like the one on the left, the subclasses appear
class below the base classes. At the top of the tree is the foundation class,
which is the most general base class. The foundation class is sometimes
base called the root class.
class
Everything in a base class definition is made available to, or inherited by,

the subclass definitions. The subclass definitions typically modify the
subclass
base class in some way, either by changing the graphical appearance (in
VISION Designer), attribute settings, or methods. There is no practical
limit to the levels in a Unify VISION class hierarchy.
An example of a class hierarchy is a button class definition that contains

the corporate logo, corporate colors, and font style that matches the
company standard. The other buttons in the application would be special
cases of this button and would use the logo, colors, and fonts from the
corporate button:
Base class
general to specific
Subclasses

Overriding inheritance
By default, a class inherits all of the attribute settings and methods from
its base class. Each subclass can choose to accept the inheritance or
override it. To override the inheritance of an attribute, you specify a new
value for the attribute of the subclass either through the class properties
dialog in VISION Designer or through a VISION 4GL script for the class.
To override the inheritance of a method, you define a method of the same

name and include the new behavior, via VISION 4GL. To override the
method name and specify no behavior for an inherited method, you
define an empty method of the same name for the subclass.
For example, the following illustration names the methods of the button
class template in a base class and two of its subclasses. Each subclass
inherits only those methods that it does not define. The first subclass
overrides the base class methods ON CLICK and ON NOT CURRENT.
The next level subclass, however, inherits these two methods and
overrides the ON CURRENT method with a new definition:
Base class ON CLICK ON CURRENT ON DOUBLE CLICK ON DRAG DROP ON NOT CURRENT
4GL statements 4GL statements 4GL statements 4GL statements 4GL statements
First subclass Overrides Inherits Inherits Inherits Overrides

ON CLICK ON NOT CURRENT
4GL statements 4GL statements
Next level subclass Inherits Overrides Inherits Inherits Inherits

ON CURRENT
4GL statements
When a method or attribute is inherited, the subclass forms a permanent

link with the base class. Any time that the base class modifies the
method, the inherited method is also modified. If the base class itself
inherits the method from its base class, and that class changes the
method, the changes are passed down to every subclass that inherits the
method.

OO principle The invention of the class hierarchy is the true genius of object-oriented
technology. Human knowledge is structured in just this manner, relying
on generic concepts and their refinement into increasingly specialized
cases.[Taylor]
Unify VISION supports class hierarchies of any level for all foundation
classes except Image and GlobalFunction.

Types of methods
As described earlier, a method is a procedure that a class knows how to

perform. Unify VISION has two types of methods: predefined methods
and developer-defined methods. Both types of methods are defined by
writing VISION 4GL statements in the script associated with a class.
Predefined methods are called by VISION Runtime Manager at

predefined points during execution. For example, every Unify VISION
object has an ON CREATE method. This method is called when the
object is created at runtime. The previous section described the ON
CLICK method which is called when the button is clicked on. Most
predefined methods cannot be called explicitly from a script. VISION
Runtime Manager controls when the method is called; you specify what
happens when the method is called by defining the method in the VISION
4GL script.
Developer-defined methods are methods that you create, associate with a

class, and eventually call from a script. This can be done by using the
C++-like notation: objref>method(), which executes the indicated
method associated with the object references of the class definition that
contains it. You can also use the SEND MESSAGE statement to issue
synchronous or asynchronous method invocations.
There are only two types of classes that can have developer-defined
methods: forms and services. In partitioned applications, these classes are
network enabled, thus allowing their methods and attributes to be
accessed and invoked from any application in the network.
OO principle The data within an object can be accessed only by the objects
methods[Taylor].
By defining and storing the methods of a class in the class script, the
method definitions are protected.
Related information Some predefined methods are callable from a script by using the
EXECUTE command. For information about the EXECUTE command,
see Unify VISION: 4GL Reference.

Class libraries
A class library is a collection of class definitions and any class

hierarchies that exist for the class definitions.
By initial default, a Unify VISION class library contains the Unify

VISION foundation classes. From any foundation class, you create any
number of subclasses to be used in your application. Regardless of the
name of the subclass you create, or how many you create, they are
always subclasses of the associated foundation class.
Unify VISION provides access to a class library in VISION Class

Browser. In the browser, you can view the class hierarchy for each class.
Each subclass is indented and connected to its base class by a line:
The Button foundation

class
The Button2 subclass
A subclass of Button2; the

Button24 subclass
Images and global functions are also stored in class libraries, although
they are not true classes because they cannot be subclassed beyond one
level. However, it is helpful with the organization of an application to
store images and global functions in class libraries.
External references
The class browser can show a class definition that resides in another class
library. For instance, perhaps a form class uses a tool bar class that

resides in a separate class library. When a class definition resides in
another class library, it is known as an external reference.
In VISION Class Browser, you can display the locations of all external
references of a class library. For example, the Button1, Button2, and
Button4 classes in the following illustration reside in the lib0 class
library; all other button classes are in the current class library (lib1):
Displays the path of the

current class library
Displays the path of the

external reference to the
Button1 class
The Button1 class from

this class library
You can access and modify a class definition that appears as an external
reference just as you can any other class definition in the library. An
external reference is like a link, or pointer, to the actual class definition in
another class library. When you double-click on the
Home+lib0.ucl:Button1 name above, for example, you are starting a
design session with the Button1 class in its source location in the lib0
class library, not in the current library (in this case, lib1).
When you create a subclass from a external reference, however, the

newly-created subclass is a member of the current class library, not the
class library that contains the external reference.
You can choose whether to view the external references of a class library
in VISION Class Browser.
What to put in a class library

You use a class library to logically group class definitions that are related
for the purposes of your application design. By allowing external

references, you can maintain a logical structure of a class library that
includes class definitions that are shared among two or more class
libraries.
For example, in a large corporation, one department may be responsible

for developing specialized field classes. Another department may be
responsible for developing applications, or the forms that use the field
classes. Each department has its own set of class libraries. The class
libraries for applications need to refer to the class definitions in the class
libraries developed by the field classes group.
The field class references would be external references in the application

class libraries. Whenever the field class definitions are updated, the
updates are automatically available in any class library in the application
group that contains the external references.
Thus, the classes that comprise your application do not necessarily

coincide with the classes in a single class library. Rather, the classes that
are used at runtime to create the forms and other objects of the
application are determined by a collection of class libraries. The
collection is known as the class library list and is specified on the
partition profile.
From class libraries with external references, you can create shadow
libraries.
Shadow libraries
A shadow library is an identical copy of the class library from which it

was created. Unlike a class library, however, a shadow library is
completely self-contained, because all external references are included.
When the shadow library is created, copies of all external references are
made and placed in the current class library.
A shadow library represents a single file of a partition, and can be used to

simplify the distribution of a class library, for example, to another
department, or to copy a class library to a laptop.
Related information For more information about VISION Class Browser, see VISION Class
Browser on page 78.

The Unify VISION foundation classes
The Unify VISION foundation class contains a master template for every
type of class that can be used in a Unify VISION application. The
foundation classes can be grouped based on how they are used as
follows:
Form Classes for objects that

MenuBar comprise the user interface
ToolBar portion of an application
ActiveX
ActiveXControl
Box
Button
Canvas
CheckBox
ComboBox
Custom
DropdownCombo
DropdownList
GroupBox
Classes for objects that can
HotSpot
appear on a form
Label
Line
List
Notebook
Page
Picture
Radio
Scrollbar
Slider
Spinner
Text
Class for object that can

ToolbarButton
appear on a tool bar
GlobalFunction Class for global functions
Service Class for application services
Partition Profile Classes that define the

PartitionGroup- environment for the partition or
Profile partition group
Data that can appear on a canvas

Image
or button object on a form

Related information For information about working with graphical classes, see Unify VISION:
Designer.
For descriptions of the attributes and methods associated with a class, see
Unify VISION: Class Reference.

3
The application model

This chapter describes the Unify VISION application model from two
illustrative levels: a simple and small application and then a larger
partitioned application.
35
A simple and small application: what the user sees
To a user who is running your application, the application appears as a

series of forms. Data and images are displayed on fields of the form.
Multiple forms are visible on the screen at the same time.
Usually, a form has a tool bar and a menu bar associated with it.
Commands on the tool bar and menu bar interact with the objects on the
form to create the desired behavior of the application. For example, to
perform a query of an underlying database from the form, a user can
enter an account number in a field and then select Find from the Database
menu. The fields of the form are then populated by the data in the first
record.
The user begins running the application with a given form and then
traverses through the other forms of the application. How the user travels
through the forms depends on the commands that are invoked by the user
and the behavior that you have specified for each form. Perhaps you have
associated a button with a command that zooms to (displays) another
form; then, when the user clicks on the button, the form that you have
designated as the zoom form appears. For example, the Order Detail

button in the previous illustration displays another form that displays
detailed order information for the current account.
Chapter 3: The application model 37

Components of the simple application
As an application developer, you also generally view the application as a

series of forms. Each form contains fields that allow the form to receive
and display data. The forms work with other Unify VISION items to
present a complete application.
A Unify VISION application consists of the following items:

forms (at least one)
tool bar (optional)
menu bar (optional)
profile (at least one)
database connection map file (optional)
help system (optional)
Forms
The form is the way that a user interacts with your application. This
central application component has three aspects:
physical appearance
behavior
location
Physical appearance of a form
The physical appearance of a form is how it looks; which field and trim
classes are placed on the form and how they are arranged. There are
many classes that can be placed on a form, including other forms.
You design a forms appearance in VISION Designer. There, you can

create new classes to appear on the form or use existing classes and place
them on the form. You enhance the forms appearance with background
and foreground colors and trim classeslabels, boxes, lines, and
graphics.

The following diagram shows the ORDERS form.
labels
numeric and
character text
field
subform
button
Behavior of a form
The behavior of a form specifies how it treats data and how it interacts
with other forms as your application executes. Form behavior is
controlled by two factors:
the settings on the property dialog associated with the form
an optional VISION 4GL script associated with the form
The form properties dialog specifies the default behavior of the form.
The optional VISION 4GL script is used to override and enhance the
default behavior whenever necessary. The form properties dialog settings
and the optional script are stored with the form as part of its class
definition.
Location of a form
The location of the form refers to the class library that contains the form.
The forms that comprise your application are usually a combination of
application-specific forms and forms that are shared among a
development team.
When your application uses forms that are not within the immediate class
library, you specify to Unify VISION where the other classes are located.

To do this, include the location and name of all class libraries on the class
libraries list of the partition. The class libraries list is specified in the
partition profile.
Tool bar
A tool bar is a panel of buttons that execute commands while a user

works with a form. The tool bar is a way for users of your application to
quickly perform an operation during application execution. A user can
also use the menu bar to perform operations.
Unify VISION provides a default tool bar with common user commands
such as those that display the next or previous record. You can design a
custom tool bar for the form to execute commands that you define in a
VISION 4GL script. You can also choose to omit the tool bar.
The following illustration shows the default tool bar provided by Unify
VISION:
Next Find Add/ Clear Set Previous Next Last

Form Update to Add Null Set Record Record
Dismiss Zoom Clear Delete Recall First Previous Next
Form to Find Record Field Record Record Set
You design custom tool bars in VISION Designer. You specify to Unify
VISION which tool bar is associated with the forms of an application
partition in the partition profile.
Menu bar
A menu bar is a bar with pulldown menus that execute commands for a
form. Users execute these commands on selected objects when they run
your application.
Unify VISION provides a default menu bar with common user

commands. You can design a custom menu bar or you can choose to omit
the menu bar.

The following illustration shows the default menu bar provided by Unify
VISION. One of the pulldown menus, Database, is selected.
You can design custom menu bars in VISION Designer. You specify to
Unify VISION which menu bar is associated with the forms of an
application partition in the partition profile.
Related information For more information about designing form, menu bar, and tool bar
classes, see Unify VISION: Designer.
Profile
The profile specifies the application development and runtime

environments. The settings that you indicate in the profile are critical to
the correct execution of your application. A current profile is always in
effect for each VISION Development Environment session. You can
either explicitly set the current profile, or set a default profile.
The profile is accessed through the Partition Profile Editor only. The
profile has several categories of settings, each of which correspond to a
panel in the editor:
Database How the application locates the associated databases; this

can be through individual external preference settings or
through a Database Connection Map file.
Runtime The first form of the partition, where the help documents
are located, and the icon that represents the application
when it is minimized.
Components The default menu and tool bar associated with the
application.

Service The initial set of service objects to be created when the
partition executes.
Distributed The settings for applications running as partitions

through the Unify Object Broker.
Class Libraries
The names of the class libraries to be associated with an
application. Each class in the class libraries list is
available to the classes of the current class library (both
at development time and at runtime).
Projects The names of the projects to be associated with an

application.
While only one profile can be current at a given time, you can create
different profiles for the same application. For example, you might have
one profile that prepares the application environment for development
and another profile that prepares the application environment for
execution.
Related information For more information about partition profiles, see Getting started in
Unify VISION: Developing an Application.
Database Connection Map file
Your application can access one or more databases. The easiest way to
facilitate this access is to set up all possible connections that your
application uses in the Database Connection Map (DCM) file. Then you
specify the DCM file path in the profile.
The DCM file maps a logical connection name to an actual database

connection. You specify the logical name in the Database panel of the
partition profile. Although the DCM file is an ASCII file, you create and
maintain the DCM file through a specialized DCM File Editor.
To define a connection, you name the connection and then set the
required external preferences for the database. The information is written
to the DCM file:

Lists Underlying DCM file
connections in [TOUR2]
DCM file DBTYPE = UNIFY DataServer
DBHOST = .
DBUSER = mis
Database DBPASSWORD = $DBPASSWORD
connection DBPATH = "/usr/mis/prsnl"
preference fields DBNAME = prsnl.db
[TOUR]
DBTYPE = ODBC
Status displays
results of Test
Connection
Related information For more information about database connections and the DCM File
Editor, see Getting started in Unify VISION: Developing an Application.
Help system
You can provide the users of your application with a help system. The
help system can provide both indexed help and context-sensitive help,
depending on the method you choose to create your help files.
With indexed help, users browse through help topics from a list of
contents. In context-sensitive help, each object within a form can be
associated with help information. For example, help on the Account #
field of the ORDERS form might appear as follows:
Enter the customer

account number in this
field. The account num-
ber a is 4 digit number.
Related information For more information about including a help system in your application,
see the help system documentation appropriate for your platform.

Form relationships
All of the forms in your application are logically connected to one

another in some way. When a user traverses through the forms of your
application at runtime, the path that the user can take is determined by the
form relationships that you have defined.
This section describes five areas of form relationships (a form

relationship can exist in more than one category at the same time):
parent and child forms
next form and auto form
subform
zoom form
master-detail
Parent form and child form

When thinking of form relationships, you can think of any given form as
a parent form. Any other form that you can access from that form is a
child form.
Parent form
Accounts Orders
Child forms

A parent form can have more than one child form. However, a child form
can have only one parent form at a given time. The parent form is the
form that created the child form at a particular instance. An actual
parent/child relationship is defined at runtime.
Next form and auto form relationships
A next form is a child form that is accessed when a user running your
application chooses the Next Form command. A user can execute this
command numerous ways: by selecting the command from a menu or
toolbar, or by clicking on a button that you have defined with the
command, for example.
You can specify more than one next form for a form. When more than
one next form is defined, the user chooses the form that they want by
selecting the form name from a Next Form list.
A next form can also be an auto form, which means that the form appears
automatically when its parent form appears.
A next form relationship is established through the Relationships panel of

the Form Properties dialog in VISION Designer. On this panel, you
specify the next form for the associated parent form.
Subform relationships
A subform is an auto form, that is, a next form that appears automatically
with the parent form. A subform can have a different target table from the
parent form.
The subform relationship is created while designing the parent form in

VISION Designer. The subform is an object that is placed on the form.
The subform and parent form appear within the same window and appear
as one class in VISION Class Browser.

Zoom form relationships
A zoom form is a child form that is accessed from an object on the parent
form. To access the zoom form, the user can click on a button that you
have associated with the uv_zoom command, for example.
A zoom form can be defined for a list box, radio group, slider, checkbox,
or text field object. For example, a zoom form for a text field can be used
to display inventory items and prices when a retail clerk is typing in a
customer order.
A zoom form is usually used to display a list of values from which the
user can choose a value to be copied to the current field.
Master-detail relationships
A master-detail relationship is a relationship between any parent and

child form in your application. Usually, the two forms have different
target tables. A target table is the database table that is associated with
the form.
The master-detail relationship is specified in the VISION Designer

Relationships panel (in the Form Properties dialog) for the master form.
The detail form that you specify must be a child form of the master
(parent). When the detail form is activated, the master-detail relationship
is established.
The master-detail relationship enforces a primary key/foreign key

relationship between the two forms. One or more columns in the master
forms target table constitute the primary key. The same number of
columns (with matching data types) in the detail forms target table are
designated as the foreign key.
The primary key columns do not need to appear as fields on the form.
They are used merely to create the selected set of the detail form.
Operations on the master form (and associated target table) are

propagated to the child form as necessary to keep the forms properly
synchronized. For example, if a field on a master (parent) form is
updated with a new value, the target table is updated and the
corresponding field on the detail (child) form is also updated.

Examples The following three examples illustrate the usefulness of master-detail
relationships.
A master form contains invoice information. The detail form (a
subform) provides the line items for the invoice. The key is the
invoice number and is listed on the master form but not the detail
form.
A master form displays all of the telephone number prefixes in an
area code. The detail form displays the last four digits of telephone
numbers for the prefixes. A user enters the search criteria, 928 as a
prefix. Then the user executes the find command.
First, VISION Runtime Manager finds all records that contain the
928 prefix on the master form. Then VISION Runtime Manager
finds all records on the detail form that contain the last four digits
of the phone number. Since a master-detail relationship exists, the
key (the prefix) is not repeated on the detail form.
A master form contains a list box that lists all childrens books
available in a local library. The detail form (a subform) contains a
list box with the childrens books written in 1993. During a find,
the subform lists all childrens books written in 1993.
Related information For information about setting up a master-detail relationship between two
forms, see Working with form classes in Unify VISION: Designer.
For more information about the effect of form operations on master-detail

form relationships, see Runtime operations in Unify VISION: Class
Reference.

Accessing a database
Database access is the purpose of most Unify VISION applications.

Through the forms of an application, the user of the application can query
and update data in one or more underlying databases. The data that
displays on a field of the form corresponds to a column in a database
table.
1001
Tofft Hardware
Mr. Elmer Jones
(916)5556451
1001|Tofft Hardware|Mr. Elmer Jones|(916)5556451|

1002|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Choosing a connection
Each form in your application is associated either with no database or a

single database connection. A subform, even though it appears within a
parent form, can have a database connection that is different from the
parent form.

On the partition level, you specify all of the connections that your
application uses through the partition profile. If the partition accesses a
single database, you can choose to use external preference set in a
preference file to facilitate the connection. If the partition accesses
multiple databases, you must define all of the connections in the
Database Connection Map (DCM) file. The DCM file specifies external
preference settings.
On the form level, in the Designer, you choose which connection is used
for that form. Objects on the form are associated with a column in a table
of the associated database. Through this object, data is updated or
displayed.
Related information For information about preference files and external preferences, see
Managing the application environment on page 101.
For information about database connections, see Getting Started in

Developing an Application.
Selected set
When Unify VISION queries a database, the rows that match the search
criteria are returned to become the records in the selected set.
Unify VISION identifies each row of the selected set by using a unique
identifier to access the row when moving from record to record in the
selected set.
If the ROWID pseudocolumn is supported by the underlying database,

Unify VISION uses the pseudocolumn as the unique identifier. Otherwise,
you can specify a primary key column to identify the rows in the selected
set.
Related information For more information about selected sets, see Selected sets on
page 133.

The basics of a partitioned application
Just like a non-partitioned application, a partitioned application contains

a user interface component: the forms, menu bars, and tool bars that
allow a user to interact with an application. Additionally, a partitioned
application contains at least one service component, which is basically a
collection of services. Services are non-graphical classes that perform
tasks (written in VISION 4GL) on behalf of clients. A service, for
example, can be asked to perform a database update.
In a partitioned application, the user interface component and the services

components are grouped into a number of partitions. The partitions, in
turn, are grouped into partition groups. Finally, a group of partition
groups is loosely associated together and managed by a network host.
At runtime, the application partitions work together to perform the tasks

required of the complete application. At a high level, this involves a user
running the client portion of the application and it requesting a task to be
performed by a service of another partition.
After the service completes the task, the result is returned to the client
application partition where execution resumes. The existence of
application partitions is transparent to the users of a partitioned
application. The users execute the application from a single desktop as if
it were entirely present on that desktop.
Application partitions
An application partition is composed of one or more services or
user-interface components. Typically, there are many services or user

interface components contained in a partition. A partition corresponds to
a class library and all class libraries on the class library list. At runtime, a
partition corresponds to a VISION Runtime Manager process.
Each application partition is designed for a particular task and for a host
that best performs the task. For example, the user-interface components
would be placed in a partition on the host that supports the display of
these objects along with any desktop application logic it is practical to
run locally.
The partitions that contain the application services are also designed for a
particular type of host. If a service is to perform intensive
number-crunching calculations, it would be placed in a partition on a host
with a powerful CPU. A partition with a service that performs
database-related operations would be placed on a host that can access the
appropriate DBMS locally.
An application partition is typically created based on one of the following

design principles:
to provide the client interface, and therefore contain the forms,
toolbars, and menu bar classes of the application
to provide access to a DBMS or other data source, and therefore
contain the service classes that interact with the DBMS or other
data source
to provide some capability tied to a type of host, such as number
crunching, and therefore contain the service classes that perform
that operation
An application composed of all three types of partition is known as a

3-tier application.
For example, assume that an application is composed of four partitions:

one for the client interface, named client, two for intensive calculations,

named compute1 and compute2, and one for database access, called
data. The following illustration shows the partitions:
data partition
client partition
compute1 partition
compute2 partition
Each application partition is executed individually by a single instance of

VISION Runtime Manager. In the example, each partition (client,
compute1, compute2, and data) is being executed as a separate VISION
Runtime Manager process on each host.
Partitions are grouped into units called partition groups.
Partition groups
A partition group is a collection of one or more partitions that run on the
same host. A group of one or more partition groups is loosely associated
and managed by their host.
Partition groups are an aid to the logical design of a large application. By

dividing an application into many partitions, you create multiple modules
of host-specific functionality. However, every application partition (even
in small applications) must reside in a partition group.
You decide which application partitions reside in the same partition group
based on these partition group characteristics:
Communication between partitions within the same partition group
is faster than between partitions outside of the partition group.
Partitions that reside within a single partition group have a single
communication point-of-entry. This provides a single security
control point. For instance, if all Internet-accessible partitions were
grouped into a single partition group then this would be the only
partition in the application that was accessible from outside the
firewall.

With the addition of the partition groups, the conceptual configuration of
the example application becomes:
DATA Partition
Group
data partition
CLIENT Partition
Group
COMP Partition
client partition Group
compute1 partition
compute2 partition
While the illustration shows one partition group per host, there can be
multiple partition groups associated with a single host in a large
application. Also, there are typically many partitions contained within a
partition group, rather than the one and two shown above.
Unify Object Broker
The components of a partitioned application communicate by using the

Unify Object Broker. The Unify Object Broker is an object-based
communication product similar in functionality to the CORBA standard
proposed by the Object Management Group.
Using the Unify Object Broker, application components transmit

information and submit requests using:
messages
business events
The combination of Unify VISION and the Unify Object Broker provide
high-powered, distributed functionality for most sophisticated 3-tier
information systems.
Related information For more information about messages, see Communication within a
partitioned application on page 65.
For more information about business events, see Business events on

page 60.

Benefits of partitioned applications
The partitioning of an application into a 3-tier system can provide many

benefits including:
centralization of business-critical application services easing
revision updates and on-going management; you can design
services to contain all business-critical processing
increased information system security through the separation of
direct data access from information access; you can control which
services are allowed to manipulate data
more effective use of computing resources; for any host that is not
being utilized you can create a partition of an application to run on
that host
decreased network traffic by placing processing logic close to the
data, for example, you can move the database processing portion
of an application to the host that contains the database

Services
A service is a non-graphical class that is designed to be used for

application-level, large-grained operations on information. Services are
publicized as a collection of methods, callable in VISION 4GL, that can be
used by other components to perform a task.
Services at the application level are analogous to stored procedures for

database management systems.
In Unify VISION, services are provided both by the application and the
underlying system components themselves. Services provided by the
system are called system services. Services provided by the application
are called application services.
The design and usage of services must be given careful consideration.

Application services represent the core of a 3-tier, partitioned application.
Poor design of services most likely results in poor application
performance and manageability. Well-designed services normally results
in predictable, stable, well-performing information systems.
System services
Unify VISION and Unify Object Broker provide several system services
useful in the on-going operation and management of a partitioned
application.
The system services provided are:
Name services
Registers and locates objects.
Replication registry services

Manages replicated services .
System management services

Manages the components of a partitioned application:
hosts, partitions, and partition groups.

Application services
An application service is a service class that you create. You create a

subclass of an existing service class, or the foundation class, and then
define the methods via VISION 4GL in the service script.
When a partitioned application executes, forms or other services use the

methods of a service to perform a desired task. Typically a method
requires an input parameter and returns a value.
The types of methods that the application service offers are designed for
the partition that contains the service: a client partition could contain
services to print a report, for example. Or, a partition designed for
numerical processing would contain services that calculates some
numerical value.
Services and databases
Services are database-aware objects. Each instance of a service object can

encapsulate its access to every database used by that service. In doing so,
the service can ensure that its operations are not affected by other service
objects within the same partition, and that its operations are not affecting
others.
For ease of use, a service object can also share its database connections
with other objects within the same partition.
Services and transactions
Since services can encapsulate their database operations, service

operations can ensure transactional consistency.
Services which share database connections with other objects within the
same partition may have their operations co-mingled in the same
transaction with operations performed by those objects.
Some database management systems provide the ability to perform

distributed transactions, typically coordinated by a 2-phase commit
protocol. Services performing operations on such database systems
adhere to distributed transaction protocols and will thus result in correct
distributed transaction semantics.

Services and threads
Unify VISION uses threads to perform the various operations of an

application. Threads are divided into two categories: user threads and
event threads.
An application that contains at least one form has one user thread. The
user thread is the thread of execution that performs all of the user
interface operations of the form as well as the 4GL operations associated
with the user interface.
Not all applications contain event threads. Only those applications that
use the Unify Object Broker contain event threads. Event threads are
spawned to process incoming messages and business events which have
arrived through the Unify Object Broker. They are also spawned to
perform the constructor and destructor methods for services.
When an application has multiple active threads, Unify VISION context

switches between the threads at well-defined points in order to allow
each thread to proceed through its processing. The context switch points
are:
When the user thread is waiting for user input
When any thread executes a WAIT FOR operation
When any thread executes a synchronous SEND MESSAGE
operation (thus executing a implicit WAIT FOR operation).
If your partition application contains services, you must be aware of the

thread switching model and its implications on concurrent execution of
services.
While each event thread will have a private data storage stack for local
variables, global variables are shared between all threads. You must
ensure that when a thread operates on shared global variables, the state
represented by the global variables remains consistent.

Replicated services
Most applications contain performance-critical components that must

meet particular throughput and response time measurements in order to
meet overall application responsiveness.
In addition, many information systems require a high degree of reliability

and availability. The information system must be available throughout
many cases of hardware failures, power outages, and other untimely
events.
For these cases, Unify VISION and Unify Object Broker provide the
ability to operate two or more copies of a service across one or more
hosts. These types of services are called replicated services.
Replicated services provide for:

increased throughput through the execution of multiple service
operations in parallel
high availability through transparent failover
predictable response times through automatic load balancing both
within and across computing platforms
Replication groups
The collection of service objects providing a particular service are

grouped together into a unit called a replication group. A replication
group acts as a virtual object for the replicated service.
In most ways, a replication group can be treated just as any other object
is treated. Thus, applications utilizing a replication group can be
developed without the knowledge that the underlying service is being
provided by a replication group rather than by a single service object.

Replication registries
In order to manage replication groups, Unify Object Broker provides the

replication registry service. The replication registry tracks the existence
of replication groups, the members of the group, and provides
inter-machine load balancing.
Related information For more information about partitioned applications, see Building and
managing a partitioned application in Unify VISION: Developing an
Application.

Business events
Many information systems are logically event-driven. The system does

not take action until a particular event occurs. In simple systems, the
events are triggered by a user performing a particular command or
entering particular information with their application.
In more complex systems, events are triggered by business processes. An

example of a business process is order fulfillment. The business process
begins with the taking of an order and ends with the shipping of the
requested items. There are several steps along the way including the
taking of the initial order, the delivery of the order to the order processing
department, the back order of items not in stock, the initial shipping of
in-stock items, and subsequent delivery and shipping of back-ordered
items.
Each of these steps involves some important step in the order fulfillment
process and will also involve changes to the information associated with
the order. Thus, the information system needs to react to these steps in
the process and modify the information accordingly.
Unify VISION allows these types of systems to be designed and

implemented in a straight-forward, high performance manner using a
feature called a business event.
A business event is a named object that can be used to asynchronously

notify other interested application objects of an event occurrence. For
example, a stock value reaching a certain value could be defined as an
event.
Unify VISION uses a publish and subscribe protocol for utilizing business
events.
Application objects (forms and services) wishing to be notified of a

particular event register their interest by subscribing to the event. When
an event occurs, the event is published, resulting in the delivery of an
asynchronous one-way message to each of the subscribers. Those
applications not interested in the event will not receive the message. So,
for all objects that subscribe to the stock value event, when the event
occurs, they will be notified and their event handling code is executed.

Business events can also specify information to be delivered with each
event notification. Thus, an application can be notified of an event and
take immediate action without sending additional requests for
information regarding the event back to the originator. This both
increases responsiveness and lowers overall network traffic.
Related information For more information about business events in partitioned applications,
see Building and managing a partitioned application in Unify VISION:

Name services
Unify Object Broker provides a name service which can be used to locate
services and other application objects throughout the network.
All partitioned applications have a global name service that exists in a

well-known location. All objects that you want to be accessible
throughout the network are registered with the global name service.
You can also choose to use a local name service. All objects that you
want to be accessible throughout a partition only are registered with the
local name service. However, you are not limited to this. Name services
simply provide a well-known location to perform registration and lookup.
The object references registered in the name services can be references to
any object whether it is local to the partition or within another partition.
When a partition begins execution, it automatically registers its services

based on the local or global setting for the service as specified on Service
panel on the partition profile. Other services are registered at runtime
through the CREATE SERVICE statement.
Global name services reside in the system partition of a partition group.

The system partition is accessible by all components of the partition
group.
For messaging purposes, name services themselves are identified by

object references. To obtain the object reference of a name service, Unify
VISION provides system functions that acquire each type of name service
object reference.
Related information For more information about name services in partitioned applications, see
Building and managing a partitioned application in Unify VISION:

System management classes
Unify VISION uses system management classes to create objects at

runtime that manage the components of a partitioned application. The
system objects are accessible at runtime, either to VISION Console or
through a VISION 4GL script, and can be used to obtain status
information about the related component, or invoke one of its methods.
UOHost Manages the host. You can access this object to obtain
the host name, port number, and operating system
process ID, and search path. You can also use this object
to start a partition or partition group. The UOHost object
is created when the uohostd utility executes.
UOPartitionGroup
Manages a Unify Object Broker partition group. You can
access this object to obtain the profile name related to the
partition group, the host associated with the partition
group, and other information. The UOPartitionGroup
object is created when the uorouter utility executes.
UVApplPartition
Manages a Unify VISION application partition. You can
access this object to obtain the profile associated with the
partition, information about the services of the partition,
and other information. The UVApplPartition object is
created when the vision utility is used to execute the
application partition.
UOPartition Manages the Unify Object Broker partition. The

UOPartition object is also created when the vision utility
is used to execute the application partition and by the
uospd daemon.
UOReplicationRegistry
Manages a Unify Object Broker replication registry. You
can use the methods supplied by this object to get the
names of the services in a replication group. The
UOReplicationRegistry object is created by the uospd
daemon. The uospd daemon is automatically started by
Unify VISION when a replication registry is needed
(provided the uorouter utility has been executed).

UONameService
Manages a Unify Object Broker name service. You can
access this object to obtain trace file information and to
use methods to provide name service tasks. Each local
UONameService object is created when the vision utility
executes the application partition. A global
UONameService is automatically created when it is
needed by the uospd daemon.
Related information For more information about the system management classes, see Unify
VISION: Class Reference
For more information about communicating with the system management

objects of a partitioned applications, see Building and managing a
partitioned application and Using VISION Console in Unify VISION:

Communication within a partitioned application
When the partitions of an application communicate with one another,

they do it by sending messages. Messages flow between forms, services,
and name services.
Messages
A message to a service or a form is simply a request to perform one of its

public methods. The message includes any necessary input parameters.
After the method executes, a response message is sent to the message
sender and any return values are set.
Object references
Before a message can be sent to an object, the sender must first acquire
the location of the object. The location is identified by a unique object
reference.
Object references can be obtained in several ways. The most common

way is to use the local or global name service to locate the object. The
name services return the object reference for any object registered within
its particular name domain.
To communicate with the local or global name service, the application

sends messages to the name service based on the name services object
reference. Once an object reference is acquired, it can be passed from one
application object to another.
Synchronous and asynchronous modes
When an object sends a message to a service or form, it can send the

message in synchronous mode or asynchronous mode.
In synchronous mode, the execution of the requester waits until the

specified method is executed before continuing.

In asynchronous mode, the execution of the application partition that
sends the message does not wait for the method to complete. It continues
execution in parallel and receives the result of the method (if any) at a
later time.
Additionally, a one-way asynchronous message can be sent. A one-way

message is one that does not generate any acknowledgement from the
destination object that the message was successfully delivered.
Related information For more information about messages in partitioned applications, see
Building and managing a partitioned application in Unify VISION:

ActiveX automation
ActiveX automation objects are objects supported by a set of certain

Windows-based applications. For example, a Microsoft Excel worksheet
can be represented as an ActiveX automation object. These non-Unify
VISION objects can be accessed and updated at runtime, similar to the
way a service is accessed, in a partitioned application.
With ActiveX automation object capabilities, a Unify VISION application

can communicate directly with popular applications such as Microsoft
Word and Microsoft Excel, requesting it to generate a document or a
graph. While the ActiveX automation object must reside on a Windows
host, it can be accessed from either a UNIX or Windows host in the
network, going through Unify Object Broker.
Each ActiveX automation object consists of a set of methods and

properties (attributes) that are defined by the vendor that provides the
application. To invoke these methods, use the SEND MESSAGE VISION
4GL statement with the vendor-suppled method name. As with any
messaging between application partitions, the object reference to the
ActiveX automation object must first be obtained. ActiveX automation
objects are not automatically registered with a name service, so you use
the CREATE SERVICE VISION 4GL statement to acquire the object
reference.
A Unify VISION application can also access ActiveX objects, such as

Microsoft Excel spreadsheets, by using the ActiveX container class. This
class appears on a form and either contains a link to or embeds the
ActiveX object. The access to the object is controlled by the user
interface of the application. With the automation described above, the
spreadsheet can be on a server anywhere in the network, with or without
a user interface component.
Related information For more information about ActiveX automation, see Building and
managing a partitioned application in Unify VISION: Developing an
Application.
For more information about the ActiveX container class, see Unify
VISION: Designer.

Architecture of a partitioned application environment
To help understand how to configure a partitioned application, and to

specify the attributes when defining a partition and partition group
profile, some areas of the host system need to be identified:
Host A host is a machine in the network. Unify VISION

applications can run on various types of hosts, including
UNIX, Windows NT, and Windows 95. A host is
managed by a uohostd daemon.
Partition group A partition group is a collection of partitions on the same

host. A partition group is managed by a uorouter
daemon. The communication area of a partition group
is used to manage the input and output of messages to the
partitions in the group from the network.
Application partition
An application partition is an instance of a VISION
Runtime Manager process. An application partition is
managed by a UVApplPartition object and
UOPartition object.
System partition
A system partition is created automatically in each
partition group. A system partition is managed by the
uospd daemon and a UOPartition object.
Name services A name service object running within an application

partition or a system partition. Each name service is
managed by a UONameService system object.
Replication registry
A replication registry manages the location of replication
groups and their members. A replication registry is
managed by a UOReplicationRegistry system object.

The following illustration shows the key components of one host in a
partitioned application. The names to the left of the diagram show the
system management objects or processes that manage the indicated
portions of the application. The partition group has three partitions.
A host machine
A partition group
managed by UOHost
A partition
servicea
managed by UOPartitionGroup serviceb
servicec
managed by UVApplPartition, serviced
UOPartition servicee
(local)
managed by UONameService
Name Service
Communication area, managed by

UOPartitionGroup
A partition
servicea
form1
form2
form3
managed by UVApplPartition,
form4
UOPartition
...
(local)
managed by UONameService Name Service
system partition
managed by uospd daemon,

UOPartition
Replication (global)
managed by
Registry Name Service
UOReplicationRegistry
managed by UONameService
A partition group

VISION Console overview
VISION Console provides a graphical interface that allows you to manage

the execution of a partitioned application from a central location. From
VISION Console, you can start, stop, and restart application partitions
located on various hosts. You can display information about a partition,
including the name of the host on which the partition is running, the
services provided by the partition, and name service and replication
registry details.
VISION Console consists of several panels, each providing information

about a particular object. The main window of VISION Console gives a
snapshot view of all partitions running on all hosts. From the main
window, you access the other panels that provide more detailed
information.
The host that contains

the global name
service
A host and the

application partitions
running on it
Status area updated

throughout execution
VISION Console works by interacting with the system management

objects, described earlier in this chapter.
Related information For information about VISION Console, see Using VISION Console in

4
VISION Development Environment

architecture
This chapter describes the architecture of VISION Development
Environment. VISION Development Environment provides an integrated
set of tools. Each tool is designed to accomplish a specific task in the
application development process.
71
VISION Development Environment overview
Help Third-party
System VISION Development Environment Tools
Script Image Profile Runtime

Designer Compiler Debugger
Editor Editor Editors Manager
As illustrated by the above diagram, VISION Development Environment

provides access to a set of Unify VISION tools. As you develop an
application, you move through this toolset as necessary.
For graphical classes, you design the classes in VISION Designer and
specify their default behavior by setting attributes on the class properties
dialog.
If a class requires code to customize the behavior, you edit class-specific

templates in VISION Script Editor. Non-graphical classes are defined
entirely in VISION Script Editor.
You use VISION Image Editor to design images and icons for your
application. You use the Partition Profile Editor to define the partition
profile and you use the Partition Group Profile Editor to define the
partition group profile.
After compiling the classes by using the compiler, you use VISION
Runtime Manager to run your application. You can also use VISION
Debugger to debug your application.
Throughout VISION Development Environment tools, you have access to

the Help system. The Help system provides useful information specific to
the tool from which it is called.
You can access any third-party tools that have been integrated into
VISION Development Environment.

VISION Development Environment
In VISION Development Environment, you view your application

graphically. You perform most operations by using standard GUI
techniques, such as selecting, dragging, copying, pasting, and so forth.
Throughout the environment and among all Unify VISION tools, there is
a consistent method of presenting information and of allowing you to
specify your choices of application behavior. This section describes these
general features of VISION Development Environment:
icons in containers
menu and tool bars
dialogs
Icons in containers
In VISION Development Environment, high-level application

components are represented as icons. Each type of component has a
specific icon.
To organize these components, you use two types of containers: projects

and folders. Projects are the top-level container, and contain folders,
among other things. Folders contain class libraries, among other things.
Folders can themselves contain folders.
Chapter 4: VISION Development Environment architecture 73

The following diagram show the Unify VISION Development
Environment top-level window, a folder window, and a class library
window: The Home project container contains items related to a project.
One of these objects is the lib1 class library container. The lib1 class
library container contains the classes directly related to an application
partition.
Class library
Project
containers
Related information For information about the required objects in an application, see The
application model on page 35.
For more information about the containers of VISION Development

Environment, see Organizing an application in VISION Development
Environment on page 102.

Menus and tool bars
You operate on the objects in VISION Development Environment through

mouse and menu or tool bar actions. With the mouse, you select one or
more objects. You then select menu or tool bar commands that act upon
the selected objects.
A menu is a list of commands that you can access from the menu bar or
from a popup menu by clicking on a mouse button or by using keyboard
mnemonics or accelerators. A tool bar is a panel of buttons that execute
common commands.
The following illustration shows a selected class library icon

(COMMON), the menu bar, tool bar, and one of the pulldown menus in a
Folder window of VISION Development Environment.
Menu bar
Tool bar
Pulldown menu
Selected item
Double-clicking on an icon opens it, if it is a container, or executes the

default command for the icon otherwise. For example, double-clicking on
a preference file opens the file in VISION Script Editor and
double-clicking on a graphical class starts a design session with VISION
Designer.
Related information The commands on menu and tool bars of VISION Development
Environment are described in VISION Development Environment
commands in Unify VISION: Developing an Application.

Dialogs
Unify VISION uses dialogs to present choices to you as you develop your
application. You enter values on a dialog by filling in blanks or by
choosing from a list of options.
Many dialogs contain more than one panel. The panels are presented
notebook style, with the panel name appearing on a tab at the top of the
panel. If you select a panel, the panel moves to the front of the dialog.
The following screen shows one of the dialog panels that allows you to
customize your working environment. On this panel, for example, you
can choose the level of informational messages that you receive from
Unify VISION. As an initial user, you can receive detailed messages
(Novice). As an experienced user, you can choose to receive only
essential information (Expert). The tabs of the other panels of the dialog
are visible. Use the arrow buttons to scroll the available panels to the left
or right.
Available panels
Environment
preferences
Standard dialog
controls

Many dialogs have a set of standard dialog controls at the bottom of the
dialog:
OK Saves the dialog option settings on the dialog and closes

the dialog.
Apply Saves the settings. In Windows and Motif, the dialog

remains on the screen. In OPEN LOOK, the dialog is
dismissed. To keep the dialog on the screen, first click on
the pushpin so that the pushpin is no longer laying flat.
Reset Changes all modified dialog options to the values that

appeared on the dialog initially.
Defaults Changes all values on the dialog options to default values

set by Unify VISION.
Cancel Discards unapplied changes and dismisses the dialog.
Help Displays online help for this dialog.
Unify VISION dialogs look different on each type of host. Under UNIX,
the panels have a three-dimensional look. Under Windows, the panels
have a two-dimensional look. The tab scroll buttons are both at the upper
right corner of the panel under Windows. The left and right tab scroll
buttons are at opposite sides of the upper portion of the panel under
UNIX.
Related information Specific VISION Development Environment dialogs and panels are
described in various chapters of Unify VISION: Developing an
Application.

VISION Class Browser
VISION Class Browser allows you to build and modify a set of class
definitions in a class library. From VISION Class Browser, you perform
all tasks relevant to a class definition: choosing its base class and which
attributes or methods are inherited from it, customizing the class
definition by modifying the inherited attributes and methods, designing
and modifying the graphical component of the class definition (if
relevant), and removing a class definition.
In VISION Class Browser, you can use various filtering commands to

change which classes are displayed, or how they are sorted.
Related information For more information about VISION Class Browser, see Defining a class
in VISION Class Browser in Unify VISION: Developing an Application.

VISION Designer
You use VISION Designer to define a graphical class. This task has three
aspects:
For container classes, you design the layout of the class
Optionally, you can specify attribute settings on the class
properties dialog
Optionally, you can add VISION 4GL to the class script
This section describes the layout of container classes and setting

attributes through the property dialogs. VISION Script Editor is described
on page 84.
Designing the layout of container classes
VISION Designer looks different depending on the type of class being

designed. To design the layout of a container class (a form, for example),
VISION Designer presents the Designer Palette along with the container
itself.
You use standard GUI techniques, such as clicking on a mouse and sizing
to design the layout. To place existing classes on the container class, you
select and drag the class name from a VISION Class Browser window to
the container. To place a new subclass of a foundation class on the
container class, use the Designer Palette.

The following illustration shows how both the Designer Palette and
existing classes in a class library can contribute to the design of a form.
Form being designed in VISION Designer

Designer palette
Class browser
window
VISION Designer provides several classes of objects that are used to build
graphical classes which ultimately appear on a form class. The following
table groups the classes based on how they are used:
Class name Description

Box, Button, Canvas, Hot Sometimes referred to as trim objects
Spot, Label, Line or non-field classes, these items are
used to separate elements or display
graphics. These items cannot be
associated with a target field in a
database table.
CheckBox, ComboBox, Sometimes referred to as field classes,
Custom, DropdownCombo, these items are typically associated
DropdownList, List, Radio, with a target field in a database table.
Picture, Slider, Text
ActiveX A field class that can be a link to a
local or remote ActiveX object.
ActiveX objects are supplied by
applications on Windows hosts, for
example, a Microsoft Excel worksheet
is an ActiveX object.
(continued on next page)

Class name Description
Groupbox, Page1 These container classes contain
groupings of field, non-field, and
ActiveX classes.
Notebook A container class that can contain page
classes only.
1 Page classes must be placed in a Notebook container before being
placed on a form
Tip When you first begin to build a class library, you can choose to generate
classes automatically based on a database connection. The default format
includes a field for every column in the target table and its associated
label (column name). You can specify the type of object to represent each
column of data.
You use the Designer Palette and property dialogs to refine the default
appearance of the form. The following illustration shows the default and
finished versions of the same form.
Default form
generated by Unify
VISION
Finished form with

your enhancements

Related information The Generate command is described in Defining a class in VISION Class
Browser in Unify VISION: Developing an Application.
Creating default fields in VISION Designer is described in Working with

other graphical classes in Unify VISION: Designer.
Class properties dialog

In VISION Designer, you specify the default behavior of every class that
you design by making choices on the class properties dialog. Each dialog
contains a set of panels with groups of dialog options.
The Form Properties dialog, for example, contains the following panels:
Connection Lets you specify the database connection associated with

the form.
Database Lets you control the database operations that the user can
perform on the database through the form. Database
access is also specified at the application level, as part of
the application profile.
Relationships Lets you specify the processing sequence of the

application (previous and next forms) and a master-detail
relationship between forms.
Components Lets you specify a runtime menu and tool bar for the
form. If you do not specify a menu bar, the system
default bar is used. If you do not specify a tool bar, no
tool bar appears.
Visual Lets you specify several characteristics of the forms

appearance: width and height of the form, the x and y
coordinates of the forms placement on the screen (from
the bottom left corner), and the color and font inherited
by objects on the form.
Field Order Lets you specify the default order in which the user
traverses the fields on the form. You can specify the
fields that are allowed to receive values from the user.
Interactive Lets you control how the user interacts with the form at
runtime. For example, you can specify which fields
require input from the user at runtime.

Repeating Area Lets you display multiple records from the selected set.
You can specify how many times one or more objects are
displayed on a form.
Sort Order Lets you specify the sort order for a selected set. Unify
VISION supplies the names of the columns in the
associated table; you indicate which columns of the
column list should be included in the sort.
Transaction Lets you specify how Unify VISION is to handle the

current transaction when a particular event occurs.
Not only are standard database operation events

recognized, such as adding a record, but GUI events are
also supported. For example, you can specify that the
current transaction is committed when the user moves
the pointer off the form. By implicitly committing the
transactions at this point, the records held by a query are
immediately released (unlocked). This is important in a
multi-user environment; other users can access the
records immediately.
Class Lets you specify comments that pertain to the class

description. The comments appear in the VISION Class
Browser window.
Each Unify VISION graphical class has a corresponding class properties

dialog.
Related information The class properties dialogs are described in Panel reference in Unify
VISION: Designer.

VISION Script Editor
VISION Script Editor is a tool that lets you edit a VISION 4GL script or
other file. VISION 4GL is an event-driven language that customizes the
behavior of a class. For graphical classes, the script customizes the
behavior as defined previously by the property panels. Each class is
associated with its own script file.
Class name and

location
Method list
Script text
Status line
In VISION Script Editor, you add templates for allowable methods and
then supply VISION 4GL statements and functions to complete the
method. You can access VISION Script Editor from within VISION
Designer or VISION Class Browser.
VISION 4GL consists of approximately 200 statements and functions in

these four categories:
Methods Sections in a script file that are similar to an if...then construct. When an
event occurs, the statements in the event section are executed. Events can
include accessing a child form, zooming to a form, and clicking on a
field, for example.

Statements that can be executed for a given event include statements for
assignment, command execution, debugging, decision, deletion, input
and output, loop control, screen control, selection, transaction control,
update, and form sequence control.
Script statements Statements that set up and manage VISION 4GL variables and other
constructs.
Database (SQL) statements ANSI-compliant or vendor-specific SQL statements that are executed by
the underlying DBMS. These statements can be any data definition
language (DDL) statements or data manipulation language (DML)
statements that are recognized by the DBMS.
Even DBMS SQL extensions can be used in scripts and functions. VISION
4GL has a statement block structure in which any SQL statements that are
delimited by BEGIN_SQL and END_SQL are passed to the DBMS to be
executed.
System functions A variety of functions for process control, binary data manipulation,
input and output, string data manipulation, text data manipulation, data
type conversion, and status checking.
Related information The syntax for script and database statements and system functions is
described in Unify VISION: 4GL Reference.
The syntax for methods is described in Unify VISION: Class Reference.

VISION Image Editor
You use VISION Image Editor to create and modify Unify VISION
images. Images are used on form classes and as icons for objects in
VISION Development Environment.
You access VISION Image Editor through VISION Development

Environment. Once in the editor, you create images by using a Tool
Palette and drawing colors determined by a color palette.
Image editing area
Tool palette
Color palette
Related information For information about VISION Image Editor, see Creating and editing
images in Unify VISION: Developing an Application.

VISION compiler
VISION compiler transforms a VISION 4GL script from a text file into
pseudocode that is interpreted by the VISION Runtime Manager.
Because a script is associated (and stored) with a class, you compile the
script by compiling the class. You need to compile a class only if it has
4GL script or functions associated with it.
The Make command also compiles scripts. The Make command can
distinguish which classes have changed since they were last compiled,
and compile only those classes.
When you choose the Compile or Make command from the Tools menu
in VISION Development Environment, VISION compiler is called. You
can specify options to the utility on the Tool and Compiler panels in the
Development Environment Preference dialog.
Related information The Development Environment Preference dialog is described in

VISION Development Environment preferences in Unify VISION:

VISION Runtime Manager
VISION Runtime Manager is the runtime component from which you

execute applications. VISION Runtime Manager monitors the events that
occur when the user runs the application and executes the appropriate
sections of the 4GL script.
The Runtime Manager also contains a query-by-form processor. This

processor allows the user of the application to enter a query at runtime by
filling in fields with search criteria.
When you choose the Run command from the Tools menu in VISION
Development Environment, the vision utility is called. You can specify
options to the utility on a Development Environment Preference dialog
panel.
Related information The vision utility is described in Unify VISION: Application Reference.
Setting preferences in the Development Environment is described in

VISION Development Environment preferences in Unify VISION:

VISION Debugger
VISION Debugger is a debugging tool for Unify VISION applications.

Because it works with VISION Runtime Manager, VISION Debugger
allows you to monitor and control your application while it is running.
If your application has produced unexpected results, you can use VISION
Debugger to interactively suspend execution of the application at selected
points. While the application is suspended, you can use the VISION
Debugger window to browse through your application forms and scripts
or to view the values of variables. The following illustration shows a
section of a form script during a Debugger session.
Line of the script or function

that is about to be executed
Related information For more information about VISION Debugger, see Unify VISION:

Third-party tools
In an open development environment, it is important to select the best

tools for each aspect of your project. For example, project management,
CASE, technical writing, quality assurance, and configuration
management tools are typically necessary to support medium to large
application efforts.
VISION Development Environment supports the integration of such tools.

You define a new kind, or class, of objects to VISION Development
Environment. The third-party tools implement the commands, or
methods, that operate on those objects.
For example, if a Microsoft Excel spreadsheet contained pertinent

information to your application development, you could integrate the
Microsoft Excel spreadsheet tool. In VISION Development Environment,
you create a custom class of objects that are processed by Microsoft
Excel.
When you create a new class, you specify the icon that represents an
instance of the class to Unify VISION and you also specify the allowable
operations on one of the objects. The allowable operations are called
methods. Examples of these methods for the spreadsheet object are edit
and print. By filling in values on a property sheet, you associate the
command that is executed when the method is chosen from a runtime
menu. For example, when you select the edit method on a spreadsheet
object, the associated command line to start an edit session on a
spreadsheet is executed.
Related information Integrating third-party tools is described in Creating custom classes in


Help system
Unify VISION provides an extensible, customizable help system that

serves two purposes:
Allows you instant access to detailed help as you develop your
application. Help information is accessible from any VISION
Development Environment tool. You can choose indexed help,
which lets you browse through the help topics before selecting
help information, or context-sensitive help, which lets you select
an object and then access the help information associated with the
object.
Allows you to display a help system for the users of your
application. You create the help text using a text editor appropriate
for your platform and associate your help files with your
application using VISION Designer.
To access help information throughout Unify VISION, choose Help from

the Help menu on any window.
Related information For more information about creating a help system for an application, see
the Help system documentation for your platform.
For information about using VISION Development Environment help

while developing your application, see Getting started in Unify VISION:

5
Version control
This chapter describes Unify VISION version control. Version control is a
method of managing changes to objects in an application. This chapter
provides the basic methodology of version control, lists which Unify
VISION objects are eligible for version control, and describes the role that
version archives have in version control.
93
What is version control?
Version control is a method of managing changes to the classes of an

application, such as forms, and associated files, such as DCM files.
The class or file that is controlled by version control is stored in a version

archive. Every time you modify a class or file and check it into the
version archive, it becomes a new revision in the archive. Each revision
is identified by a unique revision number within its version archive.
Each version archive contains the latest version of the class or file, as
well as history information leading back to the original version. The
history information in an archive includes the changes made to an item,
descriptions of the changes, information about who made the changes,
and the dates and times that the changes were made.
Through version control you can retrieve and build any version of an
application in a consistent, repeatable manner. You simply retrieve the
revisions of each item that you want from the version archives.

Version control systems and Unify VISION
Unify VISION provides a direct interface to PVCS Version Manager from

INTERSOLV. You can perform version control tasks through VISION
Development Environment in a manner consistent with other Unify
VISION application-development tasks.
In addition to PVCS Version Manager, you can use another third-party

version control system. With another system, however, only the check in
and check out operations are supported.
Most of the functionality of the underlying version control system is

supported through VISION Development Environment. For fine tuning
some aspects of version control, you access the version control system
directly. For instance, a particular version control system may provide a
different set of locking levels than another version control system.
Related information For more information about PVCS Version Manager, see the PVCS
Version Manager documentation.
For more information about using another version control system, see
Using VISION Version Control in Unify VISION: Developing an
Application.
Chapter 5: Version control 95

Benefits of version control
Version control lets a development team efficiently manage the creation,

testing, and deployment of large applications.
A Unify VISION application consists of various types of objects. Version

control manages each type of object in a consistent manner. For instance,
the way that you retrieve a form class from a version archive is the same
way that you would retrieve a DCM file.
A significant reason for using version control, however, is the

concurrence control that it provides. In a team development environment,
all developers must be able to share objects safely. The key to providing
safe sharing in any system is locking. In version control, an object is
locked when it is being modified. When an object is locked by one
developer, no one else can modify the object.
Another benefit of version control is that it allows you to access various

versions of application components. Because each version of an object in
an archive is uniquely identified, you can retrieve a specific version of an
object at any time.
For instance, assume a coding bug appears in the current version only of
a global function that is under version control. You can quickly locate the
lines of code that introduced the bug by comparing the current version of
the function to the prior version.
For applications to be deployed across multiple platforms, you can use

version control to maintain platform-specific versions of files, such as
DCM or help files. You can then build different versions of an application
by adding different versions of files to a group of generic application
components.

Which objects can be placed under version control?
You can place any class definition into version control; the foundation
classes cannot be placed into version control.
A Unify VISION application also uses other objects that manage

environment settings, help files, and preferences. You can also place the
following objects under version control:
include files preference files
RTF help files application profiles
DCM files Text file
ActiveX component description file

Version control methodology
The tasks that you perform to achieve version control in your application
vary as your application development process evolves. Basically, you
check in a class or file to version control, and then check out the item to
view or edit it. After editing the object, you check it in again.
Related to the check-in/check-out cycle are other tasks that you perform
as necessary. You can view the differences between object versions to
learn what is changing in an application. At times, you may need to reset
the lock on an item.
This section describes the basic version control tasks.
Checking in and checking out
You begin using version control by checking in a new class or file to

version control. A copy of the item is placed in a newly-created version
archive. The checked-in copy becomes the latest version in the version
archive for the item. You can think of the version archive as containing
every version of the item that has ever been checked in. In actuality, the
version archive stores only the information needed to reconstruct any
revision of the item.
Each version of an item in a version archive has a revision number

associated with it. The revision number is assigned when you check in an
object. Unify VISION uses the revision number to manage the different
versions of an object in a version archive.
After an item is checked in to a version archive, you, or any other

developer on your team, must check out the object to view or change it.
To view an item without making changes, you check out a read-only

copy.
To make changes to an item, you check out a write-locked copy.

Typically, this ensures that other developers cannot retrieve a
write-locked copy of the item revision while you have it checked out with

a write lock. However, the way that locked objects are handled depends
on settings in the underlying version control system.
When you check out a copy of an item from a version archive, the copy
of the object appears as the standard object icon. To help distinguish
checked-out copies from non-version control objects, use the Detailed
Listing view.
Checked-out copies are typically placed in a work project. The work

project is a project container that you create and manage through VISION
Development Environment. It allows you to separate the objects of your
work area from other objects.
After you edit the object, you check in the changes to the object. The
changed version becomes the latest revision of the object and is available
for other developers to check out.
Viewing changes
You can compare two revisions of an object that is under version control.
This is useful to verify what has changed between revisions.
Viewing the set of differences between object revision is most practical

with ASCII-based objects, such as DCM files or functions. For other
classes, such as forms, viewing the set of differences can be unwieldy
because of the large amount of text needed to represent the graphical
objects that appear on a form. For these kinds of objects, you should
compare the versions visually.
Resetting locks
A class or file from a version archive is write-locked when you check it
out for editing. When you check the item back into version control, the
lock is released.
You can explicitly remove a write-lock on an item without checking the

item back in. For instance, if you check out a write-locked copy of the
item then decide against making changes, you can reset the lock.
The link allows Unify VISION to access the appropriate version archive
when you check the item in after editing or when you view the
differences between revisions of the item.

Related information You can view some items in VISION Development Environment in
Detailed Listing format, which indicates whether an item is under version
control. For information about Detailed Listing format, see VISION
Development Environment preferences in Unify VISION: Developing an
Application.
For information about using the version control commands in VISION

Development Environment, see Using VISION Version Control in

6
Managing the application

environment
As you manage your application environment in Unify VISION, you work
with your application from two different perspectives. First, as you
develop your application, you manage the application through the
graphical development environment. Then, when you deploy your
application, you manage it from the operating system level.
This chapter describes the basics of organizing your application from

both viewpoints.
Unify VISION has many attributes and external preferences that work
together to create a flexible application development and runtime
environment. This section also describes the general functions of the
attributes and preferences and where they can be set.
101
Organizing an application within VISION Development
Environment
To make your application easier to maintain, you group class libraries in

folders with other items, and then group the folders with other items into
projects.
This section briefly describes the relationship among the containers and
windows of VISION Development Environment.
VISION Development Environment window
In VISION Development Environment, projects organize all of the items

that are typically related to a project: class libraries, help project files,
DCM files, include files, and preference files. Projects can also contain
folders, which are containers used to organize the items within a project.
Projects are located in the top-level window only, and can be thought of
as the largest container in the environment.
A project can be personal or shared. A shared project allows a team of

developers to access the same set of objects contained within the project.
Personal and shared projects have different icons as shown below. The
following illustration shows the top-level window and five project
containers.
Shared project Personal project
From the operating system level, a project corresponds to a directory.

You specify the directory path name when you create the project.

Project Folder window
When you double-click on the project icon (in this example, Home), the
Project Folder window appears. The Project Folder window displays the
objects of a particular project. The following illustration shows the
contents of the Home personal project.
project name
class
library
DCM file folder help file Include file ini file

preference file pgp file
Some frequently-used items are as follows:
DCM file defines the database connection mappings that your

application uses.
Folders help organize and separate applications and objects.

Folders can be nested one within the other to build a
hierarchical organization.
Include files contain declarations or other code for inclusion in any

scripts.
Preference files contain settings for external preferences that are specific
to your application.
Class libraries contain the classes from which an application is

composed and at least one profile and one partition
group profile class.
Help RTF files are documents that contain help topics.
Chapter 6: Managing the application environment 103

Text files are ASCII text files, such as a log file or the ActiveX
Component results file.
.ini files A uohostd.ini file.
.pgp files A generated partition group profile file.
Class Library window: the Class Browser
When you double-click on the class library icon, the VISION Class
Browser window appears. This window is titled Class Library.
The following illustration shows the contents of a newly-created class

library, in this case lib2.

project folder class library
container name container name
The class library can reference other classes, that are not within the class
library container. For instance, if a form in the container above specifies a
next form named form5, Unify VISION first searches the current class
library for the form. If the form is not found, Unify VISION begins
searching other containers for the form. The containers it searches are
specified in order in the class library list of the partition. This list is
specified on the Class Libraries panel of the partition profile.

Tip As you develop an application, use the Library ! Add to Library List
command in a Folder window to add a selected class library to the class
library list. The Current Application Profile Information window lists the
libraries included in the class library list for the current partition. To
display this window, select Window ! Current Profile Info from the
top-level window in VISION Development Environment.
Related information For more information about the Class Libraries panel, see Partition
profile and partition group profile editors in Unify VISION: Developing
an Application.
For more information about creating a project and the other objects
described in this section, see Defining a class in VISION Class Browser
in Unify VISION: Developing an Application.
Rescan command
The Rescan command updates the containers with all new items and
removes items that have been deleted. This is important in a shared
environment where other team members are creating and removing
objects that your application accesses.
When you select the Rescan command from the Project menu on the
top-level window, Unify VISION scans again for new objects throughout
all of the open folders and class libraries. When you select the Rescan
command from within a VISION Class Browser or Folder window, only
that container is scanned again.
By default, the Development Environment rescans the set of open

projects every 15 minutes. You can rescan the desktop more often or less
by changing the value on the Environment panel of the Development
Environment Preference Editor, or you can rescan the desktop manually
by selecting the Rescan command from the Project menu.
Related information The Environment panel is described in VISION Development

Environment preferences in Unify VISION: Developing an Application.

View command
The View command allows you to change how items are displayed in
VISION Development Environment. By default, items are displayed by
icon as shown throughout this chapter.
Related information For more information about the View command, see VISION
Development Environment preferences in Unify VISION: Developing an
Application.

Viewing your application from the operating system level
When you work with your application in VISION Development

Environment, the items related to your application are represented as
icons in containers. The containers relate to directories at the operating
system level. Libraries and files are represented as files at the operating
system level.
It is sometimes necessary to manage your application at the operating

system level. For instance, when deploying your application or when
moving an application from one platform to another.
Projects
The top-level window of VISION Development Environment shows the

project folder containers. The View menu on the top level window allows
you to view the directory paths of your projects instead of the project
names.
The directory of each project folder determines the parent directory of the
class libraries and all items within the project container. If the project
folder contains any folders, these folders each represent a subdirectory
within the project folder directory.

Class libraries
The class library container is represented as a single file. The file name is
the name of the application container with a .ucl extension. The file
resides in the directory specified for the project container. In this
example, the lib1.ucl file is located in the Home project folder directory:
$HOME/lib1.ucl (UNIX) and C:\HOME\lib1.ucl (Windows).
Class library
$HOME/lib1.ucl
Other files that contain information related to your application, for

example, a preference file, or a DCM file, correspond to files with
identifying file suffixes.
Related information For more information about the VISION Development Environment files,
see File formats in Unify VISION: Application Reference.

Lock files
Some files that are accessed by more than one user in VISION
Development Environment require access management by Unify VISION.
The access management is performed by a lock file in each directory that
contains one of the following files:
preference files (.uvp files)
class library files (.ucl files)
The lock file does not appear in VISION Development Environment.
The lock file is named uvlock.uvk. In general, you do not need to create,
access, or move this file. It is created and maintained by Unify VISION.
However, any directory that contains a lock file must have read and write
permission for all users. Use the lock file only during application
development.
To disable lock files for runtime execution of the application, use the
nolock argument of the vision utility for each partition.
Warning Do not delete a lock file. Because this file manages the shared access to
some Unify VISION files, deleting it can lead to corruption of files (the
.uvp or .ucl file).

Setting attributes and preferences
You can customize your working environment and the runtime
environment of your application by setting attributes and preferences.
(There are two kinds of preferences: preferences set through VISION
Development Environment, and preferences set in an ASCII file, called
external preferences.)
Attributes
Attributes define properties of classes that are defined in a Unify VISION
application.
Properties that are controlled by attributes include array dimensions, form
title and background color, field data display format, variable data type,
object name and parent ID, and target column name. Many more
attributes can be set to control the appearance and behavior of an
application.
VISION Designer and VISION Development Environment provide a
default attribute for every graphical class. You modify the defaults by
specifying settings on the dialogs of VISION Designer and VISION
Development Environment. You can override these defaults by setting the
attributes in VISION 4GL through a script.
For example, when you create a field on a form in VISION Designer, you
set the default state of the field to VISIBLE. This means that the field is
visible when the form runs. By using the STIPPLED attribute in a 4GL
script, you can override this default behavior in certain cases. For
example, you could set the field to become disabled (field has a
greyed-out appearance) when a certain variable becomes negative.
Related information Attributes are described in Unify VISION: Class Reference.
VISION Development Environment preferences

When you are working with Unify VISION tools, you choose options on
dialogs to control many aspects of your working environment.
For example, you can use VISION Development Environment Preference
Editor to set command line syntax for executing VISION Runtime
Manager and VISION compiler.

The choices you make are written to a file named vision1.vr in Windows
and .vision1.vr in UNIX in your home directory. You cannot edit this file;
it is changed only when you change the preference settings on a dialog.
vision1.vr
(Windows)
.vision1.vr
(UNIX)
Personal and shared preferences
As you select options on the dialogs throughout Unify VISION, you can
choose to apply the preferences as a personal or shared preference.
Shared preferences are settings for your group. A group depends on your
network setup.
In UNIX, groups are determined by your system administrator. The

permissions given to a group determine who can access the shared
resource file.
In Windows, a group is dependent upon whether your personal computer

is on a network drive. If you are using a personal computer that is not on
the network drive, you are the only one in your group. In this case,
choosing Shared or Personal makes no difference. If you are using a PC
on a network drive, group members must have the same value in the
VISION_HOME external preference.
Personal preferences are for your personal environment only and take
precedence over shared preferences.

Personal and shared preferences are each written to separate files in
separate directories:
The vision1.vr (or .vision1.vr) file for personal preferences is
written to the directory defined by the HOME external preference.
The vision1.vr (or .vision1.vr) file for shared preferences is
written to the custom directory in the lib directory within the
directory defined by the VISION_HOME external preference.
Preference hierarchy When a preference value is needed, Unify VISION first checks for
summary personal preferences then checks for shared preferences. If neither
personal nor shared preferences are defined, Unify VISION uses the
release-wide default value for the preference.
More specifically, preferences are searched by Unify VISION in the

following order:
1. Your personal preferences located in these directories:
Windows: $HOME\vision1.vr
UNIX: $HOME/.vision1.vr
2. Your shared preferences in these directories:
Windows: $VISION_HOME\lib\custom\vision1.vr
UNIX: $VISION_HOME/lib/custom/.vision1.vr
3. Release-wide default preferences stored in these directories:
Windows: $VISION_HOME\lib\config\tool_name
UNIX: $VISION_HOME/lib/config/tool_name
External preferences
External preferences let you customize the Unify VISION tools and the
execution environment for a partition. External preferences are similar to
environment variables.
Some external preferences can be set within VISION Development

Environment dialogs and saved in a partition profile. These include the
preferences that control database specifications such as database type,
password, user name, and path name.
Most external preferences can be set in an ASCII file called an application

preference file. This file has a predefined format that is determined by
Unify VISION.

Typically, you will have a local application preference file and a global
application preference file. The local application file contains external
preference settings relevant to your application. The global file contains
external preference settings relevant to your site.
Preference hierarchy At runtime, VISION Runtime Manager searches first for a local
summary application preference file and then for a site preference file. If neither is
found, the preset release defaults set by Unify VISION are used.
VISION Runtime Manager searches for a local application preference file

in the following locations:
1. A preference file specified as a command line option to the vision
utility
2. A preference file called appname.uvp located in the application
directory
3. A preference file called vision.uvp in the directory specified by
the $HOME external preference
Then, VISION Runtime Manager searches the following locations for

application-specific and global preference settings:
4. Partition Profile for the partition (only DBNAME, DBPATH,
DBUSER, DBTYPE, DBPASSWORD can be set there)
5. Global preferences located in:
Windows: $VISION_HOME\lib\custom\vision.uvp
UNIX: $VISION_HOME/lib/custom/vision.uvp
6. Release-wide default preferences located in:
Windows: $VISION_HOME\lib\config\vision
UNIX: $VISION_HOME/lib/config/vision
You cannot change the release-wide default preferences.
Many external preferences can be set at the operating system command

level as well as in a preference file. If you want the value of an external
preference to be picked up from the operating system level, specify a $
before the preference name in the preference file.
For example, for the DBNAME external preference, you can specify
$DBNAME in a preference file. Then the value $DBNAME as set at the
operating system command level (the environment) at the time the file is
read is used.

Related information Setting preferences and the format of the preference file is described in
File formats in Unify VISION: Application Reference.
The names and default settings of all external preferences are described
in Unify VISION: Application Reference.

7
Application execution
This chapter describes general aspects of the runtime execution of a
Unify VISION application.
117
VISION Runtime Manager
VISION Runtime Manager is the component of Unify VISION that

executes an application. After you deploy an application partition, you
use VISION Runtime Manager to start the partition on its host.
VISION Runtime Manager is accessed by calling the vision utility. You

specify the name of a class library to be executed; all of the class libraries
listed on the class library list for that class library are also executed.
In a partitioned application, each partition is executed by its own instance

of VISION Runtime Manager. You use VISION Console to manage the
execution of large partitioned applications.
Related information For a description of the vision utility, see Utilities in Unify VISION:
Application Reference.
For a description of VISION Console, see Using VISION Console in


Database connection
Unify VISION is designed to access any of several database management

systems.
A single application partition can access multiple databases. For

example, the application can be connected to a Unify DataServer
database and to an ORACLE database at the same time. Or the application
can be connected to two different ORACLE databases, from the same or
different versions.
Note that multiple database connections under the same DBMS are
possible only if the DBMS allows multiple open databases; Unify
DataServer and INFORMIX do not.
A database connection name is a string that specifies the database to

which requests are to be directed. You define a connection name and map
it to the physical database in a simple ASCII file, the database connection
map (DCM) file. The DCM file contains mappings for one or more
database connections.
For any form, to indicate the database connection that is to be used, you
use one of these (in order of precedence):
a connection specification clause in a VISION 4GL script or
function script
the forms connection as specified on the Connection panel of the
Form Properties dialog in VISION Designer
the application partition connection as specified on the Database
panel of the Partition Profile Editor.
You must set the external preferences that are used by the DBMS to find
the database, for example, SYBASE and DSQUERY for SYBASE SQL
Server, or ORACLE_HOME and ORACLE_SID for ORACLE. These are
the external preferences that identify the DBMS software location and the
database location.
The easiest way to set the required Unify VISION external preferences is
in the Database Connection Map (DCM) file.
Chapter 7: Application execution 119

You may also need to set additional DBMS external preferences and
Unify VISION external preferences that can affect application
performance when running on a specific DBMS. These external
preferences control these types of features:
data I/O handling
database login name
database password
database type
lock management
message handling
transaction management
Related information For a list of the optional external preferences used by Unify VISION with
your DBMS and their syntax and usage descriptions, see External
preferences syntax descriptions in Unify VISION: Application Reference.
For information about using DBMS external preferences, see your DBMS
manuals.
For more information about the DCM file, see File formats in Unify
VISION: Application Reference.

Displaying the forms of an application
VISION Runtime Manager begins execution of an application by

displaying the first form of the application and executing its associated
VISION 4GL script. After the first form, execution progresses to other
forms depending on user actions.
Unify VISION can display multiple forms at the same time. When several
forms are displayed, they all are form instances, or unique occurrences of
a form class. The user determines which form instance is the current form
by mouse actions.
Three form instances
The current form

has focus
If you would like the forms to cascade, you can set the CASCADE
external preference to TRUE, and the forms will be cascaded when the
application is initially opened. The default value for the CASCADE
external preference is FALSE.
The first form
By default, the first form of an application is determined by the form

name that is specified as the Entry Point on the Runtime Properties panel
of the application profile for the application. You can override the default
by specifying a first form class name as an argument to the vision utility.

Form instances
When a form is executed, an instance of the form class is created. The

following events occur:
1. The form instance name, object reference, and other elements are
initialized. The form instance name can be used to reference the
form in VISION 4GL statements. The object reference is a unique
identifier of the form instance.
2. The ON CREATE section of the script is executed.
3. The form mode is set to find mode or add/update/delete mode
depending on several factors.
Related information For more information about form modes, see Form modes on page 131.
Current form
A current form is the form that has focus on the desktop. Only one form
of the application can be current at any given time. By default, when the
user selects a displayed form or executes a form command, the form
becomes current. On UNIX, you can allow a user to make a form current
simply by moving the cursor over the form. To enable this behavior, you
must modify the Unify VISION preferences file and the .Xdefaults file on
your host machine.
When you change which displayed form is current, the following events
occur:
On the current form:

1. The INPUT statement and ON FIELD subsection of the script are
executed for the current field.
2. Input focus is removed from the current form.
3. The actions specified by the TX_MODE_NOT_CURRENT attribute
are performed.
4. The ON NOT CURRENT method is executed.

On the form about to become current:
5. The ON CURRENT method is executed.
6. The actions specified by the TX_MODE_BECOME_CURRENT
attribute are performed.
7. The ON FIELD method is executed for the field that was last
current on this form and input focus is assigned to that field.
Related information Only when a form is current may the user perform operations on it. See
the description of form operations on page 126.
For more information about changing how a user makes a form current,
see Working with form classes in Unify VISION: Designer.
Refreshing the display
Although you can use VISION 4GL statements to update forms, the screen
is not refreshed with the changes until after all the statements in the
user-defined method have been executed. Use the REFRESH DISPLAY
statement in your methods to immediately redraw the display with the
changes.
Related information For more information about the REFRESH DISPLAY statement, see
Unify VISION: 4GL Reference.

Form location at runtime
At runtime, Unify VISION uses the Cartesian coordinate system to place

forms on a screen. The origin (0,0) is located at the lower left corner of
the screen. VISION Runtime Manager reads the Screen X and Screen Y
coordinates in the Visual Properties panel to determine where to place the
lower left corner of the window containing the form on the screen.
The actual location of the form depends on the window manager for the
graphical user interface:
Motif (UNIX) Form placement is determined by two variables,

clientAutoPlace and interactivePlacement, in the
.Xdefaults file.
To ensure proper placement of a Unify VISION form, set

these Motif Window Manager variables as shown below:
Mwm*clientAutoPlace: False
Mwm*interactivePlacement: False
These values allow VISION Runtime Manager to

acknowledge the Screen X and Screen Y values.
If interactivePlacement is set to True, then Unify

VISION ignores the Screen X, Screen Y values that you
set in the Visual Properties panel. At runtime, each form
is only a border until the user positions the form on the
screen. If you set maximumClientSize to a value larger
than the screen, Motif Window Manager sizes the form
to fit the entire screen. If you specify
maximumClientSize to a value smaller than the screen,
then Motif Window Manager does not display any forms
larger than the value stored in maximumClientSize.
OPEN LOOK (UNIX)

When a form class is defined to be at the origin (0,0), the
form is positioned in the lower left corner of the screen.
Windows
When a form class is defined to be at the origin (0,0), the
form is positioned in the lower left corner of the screen.

To control form location at runtime, Unify VISION provides the
following attributes and statement options:
CASCADE external preference
SCREEN_H attribute
SCREEN_W attribute
SCREEN_X attribute
SCREEN_Y attribute
POSITION clause
To position the current form relative to its parent form, use the form
identifiers FIRST_INSTANCE, PREV_INSTANCE, and
THIS_INSTANCE.
Related information For information about form identifiers, see Identifiers in Unify VISION:
Application Reference.
See also the descriptions for the X, Y, SCREEN_H, SCREEN_W,

SCREEN_X, SCREEN_Y, and POSITION attributes given in Unify
VISION: Class Reference.

Form operations
When a form is current, VISION Runtime Manager can execute any of

several operations. Typically, the operations are performed by a user
choosing buttons on the system tool bar or on a custom tool bar.
Some of the most common operations are described below.
clear-to-find Places the form in find mode. This mode allows a user to
search the database table associated with the form. A
user can perform this operation by choosing the Clear to
Find button on the system tool bar.
clear-to-add Places the form in add/update/delete mode. This mode

allows a user to modify the database table associated
with the form. A user can perform this operation by
choosing the Clear to Add button on the system tool bar.
zoom, recall field, and cancel form

Zoom displays the zoom form defined for the current
field. A user can select a value on a zoom form and have
the value returned to the original form by performing a
return values operation. The cancel form operation
dismisses the current zoom form without returning a
value. A user can perform a zoom operation by choosing
the Zoom button on the system tool bar and a recall field
operation by choosing the Recall Field button on the
system tool bar. A user can perform a cancel form
operation by choosing Form ! Cancel from the system
menu bar.
A user can also perform a cancel form operation by

selecting Close using window manager controls if the
CLOSE_IS_CANCEL external preference is set to TRUE.

dismiss form Removes the current form and makes the parent form
current. A user can perform this operation by choosing
the Dismiss Form button on the system tool bar.
A user can also perform a dismiss form operation by

selecting Close, using window manager controls, if the
CLOSE_IS_CANCEL external preference is set to
FALSE. If the form being dismissed is a zoom form, this
operation returns the current value to the parent form.
exit Terminates execution of the application that contains the

current form.
next form Displays the next form of the current form. A user can
perform this operation by choosing the Next Form button
on the system tool bar.
help index Displays the help dialog for online help. A user can
access the help dialog by choosing the Help button on
the system tool bar.
Related information For more information about form modes, see Form modes on page 131.
For more information about form operations, see Runtime operations in

Unify VISION: Class Reference.
For more information about the CLOSE_IS_CANCEL external

preference, see Unify VISION: Application Reference.

Field operations and field order
As a user interacts with the current form, the user can perform field
operations relative to a field on the current form. Field operations are
affected by the field order.
Field operations
The most common field operations are:
next tab Moves the cursor to the next tab-stopped field. Use the
Tab Stop dialog option on the Interactive Behavior panel
to specify whether a field can be tab-stopped. A user can
typically use the tab key to perform the next tab
operation.
previous tab Moves the cursor to the previous tab-stopped field. A

user can typically use the shift and tab key combination
to perform the previous tab operation.
context help Displays the help text associated with the field. Use the
Help Tag dialog option on the Interactive Behavior panel
to assign a help tag to the field. A user can access the
help information by choosing the help button on the
system tool bar.
clear field Clears a field so that a value can be entered. A user can
use Field ! Clear on the system menu bar to perform the
clear field operation.

Field execution
For most classes, you control whether the associated VISION 4GL of a
field object is executed when the user clicks on the object at runtime. To
specify that the VISION 4GL is executed, specify the Focusable attribute
in the class properties dialog for the class at design time.
Button and hot spot objects, however, will execute their associated
VISION 4GL regardless of the Focusable attribute setting.
Field order
As a user traverses a form, the field order that the cursor follows is
determined by the settings that you specify in VISION Designer and by
any attribute settings.
The first field
To select the first field to execute on a current form, VISION Runtime

Manager checks the order specified on the Field Order panel, in VISION
Designer, for the form class. It also checks the value of the
FIRST_FIELD_NAME form attribute, if specified in the class script. Any
attributes specified in the script override values set through VISION
Designer.
Next fields
After processing the first field on a form, VISION Runtime Manager

selects the next field to be executed. It checks the order specified on the
Field Order panel, in VISION Designer, for the form class. It also checks
the setting of the three form attributes, if specified in the script, to
determine the next field:
CURRENT_NEXT_FIELD_NAME form attribute
NEXT_FIELD_NAME attribute
FIRST_FIELD_NAME form attribute
To prevent a user from accessing a field, do not specify the Focusable

option on the Field Order panel, or set the STOP_FOR_INPUT field
attribute to FALSE in the script.

Previous fields
While traversing the fields on a form, the user can execute the previous
field operation. The previous field is determined by the field order list
specified on the Field Order panel in VISION Designer; the field name
listed prior to the current field is the previous field. The
PREVIOUS_FIELD_NAME form attribute, if specified in the script,
specifies the name of the preceding field in the field order list. Any
attributes specified in the script override values set through VISION
Designer.
Related information For more information about the Interactive panel, see Panel reference
in Unify VISION: Designer.
For more information about form and field attributes, see Unify VISION:
Class Reference.

Form modes
At runtime, a current form is either in find mode or add/update/delete
mode.
In find mode, the user can enter search criteria on the form and then
choose the find operation. The find operation translates to a SELECT
statement and queries the associated database. The find command is
available on the system menu and tool bar.
In add/update/delete mode, the user can insert, update, or delete a record
of the associated database. The add/update and delete commands are
available separately on the system menu and tool bar.
Tip You can display the form mode by including the form_mode system
information field on the form. This field automatically displays the form
mode as the form mode changes. See the description of system
information fields on page 141.
Determining the initial mode of a form

When a form is first executed, the form mode is determined by whether
the form class has a target table.
If the form class does not have a target table, the form mode is set to
add/update/delete mode by default.
If the form class does have a target table, the form mode is set to find
mode by default. The form mode can be set to add/update/delete mode by
choosing the clear-to-add operation. Or, you can change the initial mode
of a form by setting the AUD_ON_ENTRY attribute to TRUE in the class
script.
Find mode
A form enters find mode at creation or after execution of a clear-to-find
operation. In find mode, an interactive find operation can be executed to
search for database rows that match specific search criteria. Rows that
match the search criteria are placed as records in a selected set.
Each record of the selected set is displayed on the form from which the
find operation occurred. A user can scroll through the selected set by
choosing the record commands on the system tool bar or system menu.

Related information For more information about selected sets, see Selected sets on
page 133.
Add/update/delete mode
After finding records and creating a selected set, VISION Runtime

Manager changes the form mode to add/update/delete mode. Also, after a
user executes a clear-to-add operation, the form mode changes to
add/update/delete.
When a form is in add/update/delete mode, the user or script can perform

these operations:
add new rows to the database
update existing database rows
delete existing database rows
When a selected set is displayed, the user can also perform operations
that manipulate the display of records. For example, the next record
command displays the next record in the selected set.

Selected sets
A selected set is a set of records that satisfy a set of search criteria. In

find mode, the information that the user enters on the form is interpreted
as search criteria. Search criteria are conditions that must be matched
when the database is searched. Search criteria can also be initialized or
set by changing form and field attributes.
Creating the selected set

Unify VISION uses search criteria to create an SQL SELECT statement
similar to the following construction:
SELECT db_column_list FROM table_name
WHERE sql_column_condition AND sql_column_condition
AND sql_optional_condition
ORDER BY sql_order_by_clause ;
The SQL SELECT statement is constructed from the values of attributes

at runtime and is prepared by Unify VISION according to the
requirements of the particular DBMS.
The SELECT statement is then processed by the DBMS. The row values
returned by the DBMS are copied into records and displayed in the
selected set.
Specifying search criteria

Search criteria can be set in VISION Designer, in a class script, or by the
user at runtime. When a user enters search criteria on a form, it is called
query by form.
To specify value ranges and string expressions, the user enters a

combination of characters and metacharacters. The metacharacters
(sometimes called wild cards ) that can be used are dependent on the
DBMS. See your DBMS documentation for metacharacter specifications.
Using the browse feature

The browse feature enables you to specify the number of records VISION
Runtime Manager places in the selected set before returning control to

the user. The standard record search method puts all selected records into
the selected set. Using the browse feature, VISION Runtime Manager
adds only a specified number of records to the selected set at one time.
After it adds each subset of records to the selected set, VISION Runtime
Manager suspends the target table search. The search is resumed when
the user moves to the end of the current selected set with the
uv_next_record or uv_next_set user commands. This select and add
process occurs each time the user passes the selected sets end boundary
until there are no more records that satisfy the search criteria. If the user
executes the uv_last_record command, all remaining records are found
and added to the selected set.
The FIND_COUNT attribute specifies the number of records to be added

to the selected set at one time. If the find count is zero (0), then VISION
Runtime Manager does not use the browse feature. If the find count is a
positive integer, then VISION Runtime Manager uses the browse feature.
Related information For information about setting the find count through the Database panel
of VISION Designer, see Panel reference in Unify VISION: Designer.
For more information about the FIND_COUNT attribute, see Unify

VISION: Class Reference.
Working with selected sets in VISION 4GL
In addition to the browse feature, Unify VISION provides the following

features that affect the records in a selected set:
CLEAR_AFTER_AU
uv_add_update (target table required)

uv_clear_to_add
uv_clear_to_find (target table required)
uv_delete
CLEAR TO ADD
DELETE CURRENT RECORD
NEXT ACTION IS CLEAR_TO_ADD

NEXT ACTION IS CLEAR_TO_FIND (target table required)
NEXT ACTION IS FIND (target table required)
QUEUE COMMAND CLEAR_TO_ADD
QUEUE COMMAND CLEAR_TO_FIND (target table required)
QUEUE COMMAND FIND (target table required)
UPDATE CURRENT RECORD
As indicated above, some features are valid only for forms that are
associated with a target table. Other features can be used with any
selected set.
To enhance manipulation of selected sets, two new statements have been

added to VISION 4GL:
DELETE CURRENT SET
REFRESH CURRENT (target table required)
Related information For descriptions of the DELETE CURRENT SET and REFRESH
CURRENT statements, see Unify VISION: 4GL Reference.
Clearing the selected set

VISION Runtime Manager clears the selected set when any of the
following events occurs:
A clear-to-find operation is executed.
A dismiss form operation is executed.
A cancel form operation is executed.
To clear the selected set, VISION Runtime Manager does not perform any
transaction operations; the current transaction is neither committed nor
restarted.
The actions taken depend upon whether the form is running at record
consistency or set consistency.
At record consistency, VISION Runtime Manager performs the following

actions:
1. Issues a lock release request to unlock all read-locked target table
rows associated with the selected set records.

2. Removes selected set records from the display.
At set consistency, VISION Runtime Manager performs the following

actions:
1. Retains all read locks on the rows associated with the selected set
records.
2. Removes selected set records from the display.
If any selected set records were modified or added, their associated target
table rows are write locked. Regardless of the forms consistency level,
VISION Runtime Manager does not release these write locks when it
clears the selected set. The write locks remain locked until the current
transaction is either committed or restarted.
The selected set can also be cleared by using the DELETE CURRENT
SET statement. This statement also deletes the associated target table
rows.
Related information For more information about consistency and locking, see Managing
transactions and locks in Unify VISION: Developing an Application.
For more information about the DELETE CURRENT SET statement, see
Unify VISION: 4GL Reference.

Providing Unify VISION with row identification information
The information in this section applies only to DB2 when accessed
through MDI, to INGRES on UNIX, and to SYBASE SQL Server.
When Unify VISION queries a database, the rows that match the search
criteria are returned to become the selected set. Unify VISION identifies
rows in the selected set by storing the values of specific columns. These
column values are the row identification information (row ID) that is used
to move from record to record in the selected set. As the following
illustration shows, the current record changes as Unify VISION moves
through the selected set.
Row ID
xxxxxxx xxxx xxx xx First current record

xxxxxx xxx xxxx xxx
xxxxxxx xxx xxx xxx
xxxxx xxxx xxxx xxx
Selected xxxxxxx xxxx xxx xx Next current record
set xxxxxx xxx xxxx xxx
xxxxxxx xxx xxx xxx
xxxxx xxxx xxxx xxx
xxxxxxx xxxx xxx xx New current record
xxxxxx xxx xxxx xxx
For database management systems, such as the ORACLE or Unify

DataServer, that have the ROWID pseudocolumn, the pseudocolumn is
used as the row ID.
For DB2 MDI, INGRES, and SYBASE SQL Server, which do not use the
ROWID pseudocolumn for the row ID, the row ID consists of one or
more columns that can be used to uniquely identify rows in the database
table.
To use row IDs effectively, you need to understand:
the importance of row IDs
how to specify row ID columns
how to determine the current row ID columns
how to coordinate row IDs and triggers
Why row IDs are important

Row IDs are important not only because they enable Unify VISION to
move through the selected set. Row IDs also ensure that when Unify
VISION accesses a record based on a specific request, the same record is

accessed every time that the request is executed again. If you know
which columns Unify VISION uses to identify selected set rows, you can
control selected set access.
You also need to know whether row ID columns can be modified by the
database and how those changes can affect selected set access. For
example, the database can fire a trigger (SYBASE SQL Server) or a rule
(INGRES) to change the values of the row ID columns, and Unify VISION
cannot detect the changes. If row IDs can be modified, you must have a
way of indicating to Unify VISION when the row ID information has
changed and in what way. (A DB2 database that is accessed through MDI
cannot fire triggers.)
Specifying row ID columns
To specify row ID columns, you create an entry in the appropriate row ID

table, which is created by the Unify VISION ridutil utility:
For DB2 MDI, the row ID table is named SYSMDI.UNIFYRIDS
For INGRES or SYBASE SQL Server, the row ID table is named
_aclrowids_
The row ID table is a database table for which you can display
information through the DBMS version of SQL. For example, to display
information about the _aclrowids_ table, execute the SYBASE SQL
Server sp_help stored procedure.
Each database in the server can contain one row ID table, but the table
exists only if you have used the ridutil utility to specify row ID columns
for one of the tables in the database. The row ID information for a table
can span one or more rows of the row ID table.
The following diagram shows three simple databases; two of the

databases contain row ID tables.

Database1 Database2 Database3
Table1 Table1 Table1
Table2 Table2 Table2
Table3 Table3
Row ID Row ID
table 1 table 1
ridutil c was executed ridutil c was ridutil c was

for Table1 and Table3 not executed executed for Table2
When a table has several indexes, and Unify VISION does not choose the
index that you prefer, you can use the row ID table to specify the columns
to be used. Row IDs specified in the row ID table override indexes that
are defined for the table.
Related information For a list of the database column types that can be used for row IDs, see
the ridutil utility description in Unify VISION: Application Reference.
Using rules or triggers
(INGRES and SYBASE SQL Server only)

A rule is an INGRES database procedure, and a trigger is a SYBASE SQL
Server stored procedure. The rule or trigger is automatically executed, or
fired, when data is inserted, deleted, or updated in a specific table. For
example, when a table is updated, a rule or trigger can be fired to make
sure that information is also updated in related tables. Thus, a rule or
trigger can be used to help maintain referential integrity.
For INGRES, these restrictions apply to using rules:

Rules can be created for tables but not for views.
To create a rule you must own the table.
A table can have rules for inserts, for updates, and for deletes.
One rule can be applied to one, two, or all three operations.
A rule can apply to only one table.

For SYBASE SQL Server, these restrictions apply to using triggers:
A trigger can apply to only one table.
A table can have up to three triggers: one for inserts, one for
updates, and one for deletes.
One trigger can be applied to one, two, or all three operations.
The following diagram shows rule and trigger table configurations.
Table Table
Insert Insert and
delete
Update Update
Delete
Rules/
Triggers
Table Table
Insert and Insert,
update update, and
delete
Delete

System information fields
A system information field on a form displays information about the state

of an application as it executes. For example, a system information field
on a form can automatically display the number of records in a selected
set.
System information fields are updated dynamically, that is, the data
displayed in the field changes as the state of the application changes. For
example, the record_number system information field displays the
current row number as you move through the records in a selected set.
Creating a system information field
The system information fields are predefined by Unify VISION; all of the
logic to generate and display the data is provided.
To create a system information field, create a text field object on a form

class in VISION Designer. On any of the panels associated with the
object, enter the name of the system information field as the text field
name.
System information fields have reserved names that cannot be used for
other text field names.

Choosing a system information field
The system information fields provide frequently needed information

about your application. Choose the appropriate system information field
by consulting the following table.
To display Use
the form mode (find or add/update/delete) form_mode
a message string as determined by the DISPLAY fyi_message
4GL statement or the FYI_MESSAGE attribute
the status of the current record in a selected set: record_action

adding, added, updating, updated, deleting, deleted
the total numbers of records in the selected set record_count
the number (positional) of the current record in the record_number
selected set
whether the information displayed on the current record_state
form is stored in the database
whether the current field is zoom enabled zoom_indicator
Related information For more information about the individual system information fields, see
Unify VISION: Application Reference.
Viewing the updated system information fields
When the data displayed by a system information field needs to change,

Unify VISION updates the data on both the current form and the first
form of the application. (The first form of the application is determined
by the form name that you specify in the entry point field of the Runtime
Properties panel of the application profile.)

Intermediate forms are not affected by changes to the system information
fields. For instance, assume that you have the following form mapping:
next form
next form next form

1 2 3
next form
B
Every form contains a record_count system information field. If you do

a find operation on form 3 and form A, the record_count system
information field is updated on those forms and form 1, the first form of
the application. The record_count system information fields on forms 2
and B are not updated.
If you do not want to see the fields being updated on the first form, you
can create an invisible first form of your application. Create a form with
the VISIBLE attribute set to false. Specify the user-visible first form as
the only next form of the invisible form. (In the ON CURRENT method,
put the single command NEXT ACTION is next form.)

Drag and drop
The drag and drop feature of Unify VISION allows a user of your
application to move objects on the screen by using the mouse buttons. A
user can select an object by clicking on it, drag the selected object to a
different location, and then release the object by releasing the mouse
button.
Object being dragged;

in this case, a text field
Drag icon Invalid drop

site icon
Target location of the
dragged object; the drop site
Moving an object to a new location is a way to move information; for

example, a user can move a field of data from one form to another form.
Moving an object can also provide a way to perform specific processing.
For instance, a user can move a subform to a trash can icon to indicate
that the subform is deleted.
You design and implement drag and drop functionality through VISION
Designer and optionally through the class script.

At runtime, the user drags an object by holding down the left mouse
button and then sliding the object to the destination. For text fields, the
user must hold down the shift, control, or alt key and the left mouse
button. You can either drag the whole text field or the highlighted
section.
As the object is dragged, an icon represents the object. The icon

represents whether or not the object can be dropped. The user can cancel
the drag by dragging the object away from the applications form
windows and then releasing the mouse button.
Related information To use a script to control drag and drop behavior, see the following
methods in Unify VISION: Class Reference:
ON DRAG DROP
ON DRAG ENTER
ON DRAG LEAVE
ON DRAG START
To specify drag and drop behavior and icons through Unify VISION:
Designer, see the Drag panel description in Panel reference in Unify
VISION: Designer.

Glossary
3GL function ancestor form

A type of external function written in A form in the form tree that is
a third-generation programming between the current form and the first
language, for example, the C form.
programming language. See also child form; descendent
form; parent form.
ActiveX ANSI (American National Standards

A graphical class used to associate an Institute)
ActiveX object with a field on a form. An organization that establishes
voluntary industry standards for
database systems.
abort
To terminate the application or the application
current transaction without saving A customized set of forms, menu
changes. bars, tool bars, functions, and services
that enables users to perform business
tasks. An application is composed of
one or more application partitions.
accelerator
A sequence of keystrokes that invokes application management event
a command. Any significant change in the state of
See also mnemonic. a system resource or an application.
application partition
add/update/delete mode A collection of Unify VISION
One of two methods of operation for a components that perform logically
form during application execution. In related tasks. Each partition is
add/update/delete mode the user can executed singularly.
add new records to the database,
modify existing records, or remove application preference
existing records. A variable that controls the runtime
See also find mode. properties of an application.
147
array browse area
A variable that consists of multiple An area, usually in a shared project,
elements arranged in one or two that contains read-only copies of
dimensions. objects that are maintained by version
control.
ASCII (American standard code for

information interchange) browse feature
A standard set of codes that are used The facility that controls the number
to represent characters on many of records added to the selected set
computers. An ASCII file is a text file when a find operation is executed.
that consists of standard characters.
See also binary file.
business event
An event defined by a Unify VISION
application.
attribute See also application management
A value that defines a particular event.
characteristic (for example, size) of an
object.
See also preference. button
An object associated with a command.
background color
The secondary color visual attribute cache
of an object. An area of memory, such as a buffer,
where data is temporarily stored to
reduce the need to read from disk.
base class
In a class library, the class from which
a particular subclass is created and cancel
associated with. To dismiss the current form, dialog, or
selection without executing any
changes.
binary file
A file that contains code in the format canvas
required by the computer processor. An object that contains an image.
Boolean cascading menu

An entity that has two possible values: A submenu that appears after
TRUE or FALSE. selecting a menu choice on a menu.

check box click
An object that is a graphical To press and release the mouse button
representation of a boolean value. A without moving the pointer.
check box is a type of view.
See also list box; slider; text field. clustered index
A SYBASE SQL Server index that has
the same physical and logical
child form (indexed) order.
A form that is a direct descendent of a
parent form. color palette
See also ancestor form; descendent A range of colors available for the
form; parent form. background and foreground colors of
an object.
class
column
A template of attributes and methods
The database entity that defines one
that is used at runtime to create forms,
data element in a table.
services, and other Unify VISION
objects. See also row; target field.
See also base class; subclass.
column type
The format in which the database
class hierarchy stores column data. Unify VISION
A tree structure representing the data types are distinct from database
relationship among classes. column types.
See also base class; subclass. See also data type.
combo box
class library A text object that is combined with a
A collection of class definitions. list box from which the user can select
a value.
clause
command
A discrete portion of a script
A user request that initiates an
statement. For example, the ON
application operation.
CHOOSE NEXT FORM method has a
USING clause. See also developer-defined
command; operation; predefined
command.
clear-to-find expression
An expression specified by the command line
CLEAR_FIND_EXP attribute that The operating system program
sets the initial search criteria for a interface that accepts and executes
target field. system commands.
Glossary 149
commit current record
Terminate a transaction and save all The record in the selected set that is
changes made by that transaction to currently active.
the database, making the changes
visible to other transactions.
current window
The window that has focus and where
compile operations can be performed.
To transform a Unify VISION script
from ASCII source text into an
executable format.
cursor
A pointer on the screen.
concurrence
The ability for multiple transactions to
access a single database custom command
simultaneously. A developer-defined command that is
defined in VISION Development
Environment through the Customize
context-sensitive help menu.
Help text that describes the currently
selected object or dialog item.
custom
Either a graphical class that is built
copy from a collection of other classes and
To duplicate a selected object. appears as a field class on a form, or a
developer-defined class that is defined
in VISION Development Environment
created form through the Customize menu.
A form that has been defined and
initialized.
custom manager
A developer-built version of vision
current field
where the developer has added
The active field on the current form.
customized 3GL function calls.
current form
The form that has user input focus. cut
To remove an object. The most
recently cut object can be pasted back
current object using the paste command.
The object that is selected. See also paste, delete.

data type database procedure
The format in which Unify VISION A set of SQL statements that are
stores or displays data. Unify VISION stored under a name and can be called
data types are distinct from database from a VISION 4GL script.
column types.
See also column type. DBMS (database management
system)
The set of software programs that
creates, controls, and manages
database
database properties and operations.
A set of related tables and other
related database objects, that may
include B-trees, columns, defaults, DDE (Dynamic Data Exchange)
hash tables, indexes, procedures, A method of interprocess
rules, views, or triggers, depending on communication based on the
the DBMS. messaging system built into Microsoft
Windows.
DDL (data definition language)

database connection
A string that names a connection and SQL statements that describe database
maps to physical database information elements and their relationships.
needed to connect to a database.
declaration
A script statement that supplies
database connection map (DCM) information about an identifier used in
file the script, such as the name and type
An ASCII file that maps database of a global function.
connection names with the physical
database information that is used to defined form
access and open a database. A form that has been defined as a
class in an object library.
database login form delete

A screen form that prompts the user To permanently remove a selected
for a user name and password to be object or region of text.
used to log in to the database. See also cut; paste.
deploy
database operation The process of customizing an
A VISION Runtime Manager process application and moving it to another
that affects values or rows in a computer system or environment for
database table. production use.
Glossary 151
dereference operator developer-defined method
A symbol that indicates that the A method whose name and access is
OBJECT_REF value on the left side defined by the developer by using
identifies the object to be referenced VISION 4GL statements.
on the right side, for example, See also predefined method.
text_ref>VALUE
dialog
A window in the Development
descendent form Environment or VISION Designer that
A form created later than, and is a enables the developer to specify
direct chain from, forms higher in the values of attributes.
form tree. See also panel.
See also ancestor form; child form;
dialog controls
parent form.
Options to control a dialogs state
such as Apply, OK, Reset, Default,
Help, and Cancel.
Designer Palette
A window that contains classes that dialog options
you can place on container classes. Settings for an object in a panel or a
The Designer Palette also contains dialog, such as Width. A dialog option
development tools such as the pointer, can be a radio group, check box, list
Label Editor, and Lock tool. box, or text field. The value of the
dialog option can be changed by the
developer.
desktop
The area in any of the windows in dirty data
VISION Development Environment Data that is write-locked by another
used to display icons representing transaction that may be updating the
objects. locked data. As a result, the data
cannot be relied upon to be up to date.
developer display format

A programmer who creates or The format or layout to display a type
maintains an application. of data.
display-only
Data that is read-only, that is data
developer-defined command cannot be edited or modified.
A command class that has been
defined by the developer in a DLL (dynamic link library)
COMMAND section of the script. A library of C functions that can be
See also command; predefined loaded and executed at runtime by
command; custom command. multiple Windows applications.

DML (data manipulation language) error message
SQL statements that manipulate A message that reports and explains
database information but do not affect an error that has occurred. The type of
the database design. error message depends on the severity
of the error and the information level
setting.
double-click exclusive lock

To click a mouse button twice in rapid See write lock.
succession.
executing form
A form running under VISION
drag Runtime Manager.
To hold down a mouse button while
moving the mouse across the desktop explicit
or form. An operation that occurs as the result
of a deliberate statement or user
action, such as pressing a command
key sequence.
drop See also implicit.
To release a dragged object onto a
valid drop site.
extension
Syntax that differs from or
supplements the ANSI standard syntax
drop site for SQL commands.
An object that can receive a dragged
object. field
An area on a form class used to
display and accept data.
See also target field.
dropdown combo box
A text object that is combined with a
dropdown list box from which the field attribute
user can select a value. A value that describes a characteristic
of a field, such as its type or length.
field variable
dropdown list box A variable that references a form
A dropdown list box from which the field. The field variable has the same
user can select a value; the selected name as its associated form field.
value is displayed in a read-only text Field variables have general variable
field. attributes and field variable attributes.
Glossary 153
find mode form mode
One of two methods of operation for a One of the methods of operation for a
form during application execution. In form: find mode or add/update/delete
find mode the user can search for mode.
existing records that satisfy specific
search criteria. form state
See also add/update/delete mode. In Unify VISION, a form instance can
be in one of three states: defined,
created, and current.
fire
To execute automatically when a See also created form; current
specific event occurs. For example, a form; defined form.
SYBASE SQL Server trigger can be
fired when an update is applied to a form tree
database column. At runtime, defined, created, and
current forms are controlled by a tree
structure, with the first form at the
folder root of the tree.
An object that organizes groups of
other items, such as class libraries, in
VISION Development Environment. format template
A pattern of special characters that
specifies the type of character to be
foreground color displayed in each position of a value.
The primary color of an object. For example, format templates can be
used to specify the positions of triad
separators.
form attribute
A value that describes a characteristic
of a form. general variable
A developer-defined variable that is
not associated with any form field or
form class database column.
A graphical class that represents an See also target variable; variable.
area containing dialog options and
images organized to display and
global function
retrieve information for a user.
A script that contains script functions
See also form instance. or 3GL functions that are defined for
all other scripts in the application.
form instance See also script.
A copy of a form class that is being
executed by VISION Runtime global name domain
Manager. The set of global service object names
See also form class. in a distributed application.

global name service help tag
An object that manages the location Attribute of a field or user-interface
and object reference of objects in the object that is an entry point into the
global name domain. hypertext help system.
heterogeneous database access

global object reference (HDA)
An object reference of a global A feature that enables the application
service object. to query and update multiple
databases based on software from one
or more DBMS vendors.
grid
A framework of parallel horizontal
holdlock
and vertical lines used to align objects
A SYBASE SQL Server shared lock
on a form.
that is held until the transaction is
committed.
group
A set of related dialog options. icon
A small graphic that represents an
existing object or form at runtime.
group box
An object on a form that is a rectangle iconify
that can contain other objects. To use the Window Manager to cause
a window to be transformed from the
GUI full rendition of the object or program
Graphical user interface. to an icon representing it.
implicit
handles An operation that occurs
Solid squares that appear around a automatically or by default whenever
selected object in VISION Designer a specified condition occurs.
that enable you to resize it visually. See also explicit.
height include file

The vertical size of an object in A file that contains declarations and
pixels. definitions for variables that are used
in a script.
help server index

The help subsystem available in Unify An access method by which specified
VISION. ordered column values are used to
See also indexed help. select database rows.
Glossary 155
indexed help list box
An alphabetized list of subjects that A scrolled list of text strings. A list
the user can select and read. box is a type of a view.
See also help server. See also check box; text field; slider.
local function
inheritance
A method defined only within a form
A feature that enables a class to make
or global function.
use of attribute definitions and
methods defined in a class above it in
the class hierarchy.
local name domain
See also class hierarchy. The set of local service object names
in an application partition.
input focus
The object to which keyboard input is local name service
directed. Assigning focus to a form An object that manages the location
instance makes the form current. and object reference of objects in the
local name domain.
instance local object reference

A named activation of a class. An object reference of a local service
object.
interactive database operation

A database operation performed on localization
the selected set that is initiated by the The process of customizing an
user or script. application to the local language or
local standards.
keyword
master-detail relationship
A word defined as part of the VISION
A relationship between two forms
4GL script syntax. Keywords are also
which is based on each target tables
reserved words; they cannot be
primary key.
assigned definitions by developers.
menu
label An application-generated list of items
A literal text string used to identify an from which the user can select an
object. option to be executed.

menu bar mnemonic
The bar across the top of a Unify A single-character keystroke that
VISION window that contains the invokes a menu item.
names of the menus that can be pulled See also accelerator.
down to execute Unify VISION
commands.
Motif TM
A trademark of The Open Software

menu item Foundation, Inc., for its X
A command on a pulldown or popup Window-based graphical user
menu. interface.
message mouse
A packet of information sent between A device for pointing at and selecting
service and form objects and other information on the screen.
objects in a partitioned application.
name domain
message handle The area within a distributed
An object that uniquely identifies a application in which an object
message and contains status reference is known. See local name
information relating to the message. domain and global name domain.
metacharacter name service

A special character, such as an An object that manages the object
asterisk (*), that represents a range or references for objects within a
pattern for matching search criteria. particular name domain. See local
Sometimes called a wild card. name service and global name service.
Metacharacters are DBMS dependent.
nested query manager

method The process that maintains the
An available procedure for a class. information that is needed to read the
Methods are written in VISION 4GL. SYBASE SQL Server database rows
See predefined method and selected for nested queries that
developer-defined method. perform database operations.
method signature noninteractive database operation

The method name, number of An operation on a database table that
parameters, parameter modes, and is initiated by an SQL statement or
parameter names and data types. noninteractive script statement.
Glossary 157
notebook occurrences
A collection of pages and their tabs Number of times objects are repeated
within a container class. Notebooks in a repeating group.
are commonly used to organize a
large set of dialog options into display
open
groups to minimize the screen real
Deiconify a GUI object or program.
estate necessary for a container class.
See also page.
OPEN LOOK TM
A trademark of AT&T for its

X Window-based graphical user
null interface.
A value of a specific type that is
empty. operation
See also undefined. The series of actions and script
sections that are executed in response
to an event, such as a user command.
object
option list
A self-contained packet of attributes
A group of panels available in a
and methods recognized by Unify
dialog.
VISION.
See also dialog.
See also instance.
origin
The base point where the vertical and
object reference horizontal axes of an object intersect.
A handle that uniquely identifies an
object instance in an application. page
Object references are assigned when A rectangle and a tab within a
the object is created, as in form notebook class. Pages can contain
activation. Object references are field classes, non-field classes, and so
stored in the Unify VISION data type on.
OBJECT_REF.
See also notebook.
page-level lock
object reference A lock that is placed on a page of
A unique identifier of an object in a database information, which may
distributed application. See local contain more rows than are in the
object reference and global object selected set. (This is in contrast to a
reference. lock on only the selected rows.)

panel paste
A group of dialog options for an To put a previously cut or copied
object. VISION Designer and VISION object on a window.
Development Environment provide See also cut; delete.
one or more panels accessible in a
dialog.
See also dialog; option list. picture
A graphical class used to display
images stored in database tables.
parent form
The immediate ancestor form of a
form. point size
See also ancestor form; child form; A unit of measurement for setting the
descendent form. size of a font. A point is
approximately 1/72 of an inch.
partition group
A group of one or more partitions that pointer mode
run on the same host platform and When the Designer tool is in pointer
share a common message router and mode, objects can be selected, moved,
message communication area. stretched, and resized.
See also application partition.
popup menu
partition profile A menu for a selected object or for
A class that contains information to the window. A user can usually
develop and run an application display the popup menu by pressing
partition. the menu mouse button. In Unify
See also application partition. VISION, all commands on a popup
menu are also available as commands
on pulldown menus.
partition group profile
A class definition that contains
information to develop and run a predefined command
partition group. A command provided by Unify
See also partition group. VISION that executes a predetermined
sequence of operations when selected
by the user. Predefined commands
password include typical database operations
A code that identifies the current user and record manipulation.
to the operating system or to the See also command;
database. developer-defined command.
Glossary 159
predefined method radio button
A method whose name and access is An element of a radio group which
determined by Unify VISION. represents one value the group may
See also developer-defined method. assume. It is selected by clicking on
it. A radio button is always next to a
label.
preference See also check box
A variable that specifies a value to be
used during application development radio group
or runtime execution. One or more radio buttons in a box
See also attribute. with or without a border. A radio
group is a type of view.
See also check box; list box; slider;
preference file text field.
A text file that contains variables to
configure a users application. raise
Changing the stacking order of a
window so as to hide another window.
press
To hold down the mouse button to read lock
make a selection. An instruction that permits read
access to database rows but prevents
write access by all transactions.
project See also write lock.
A symbolic name for a file system
entry point.
record
A copy of a database row, displayed
in a selected set.
protocol See also row.
A formal set of rules defining how a
message is exchanged.
referential integrity
The rules that govern data
consistency, which guarantees that
pulldown menu
when a table is updated, all related
A menu that is attached to a button
tables and objects agree.
within a menu bar in an application.
When the pointer is clicked on the
button within the menu bar, and then repeating group
dragged downwards, the menu pairs An object (such as a button or field)
and remains displayed as long as the that is repeated one or more times to
pointer button is depressed. display multiple records on a form.

replication group rubberbanding
A named group of service objects, To use the pointer to select several
each of the same class, operating as a objects on the form by drawing an
single virtual object. imaginary box around the objects.
rule
replication registry A special database procedure that is
A list of active replication groups. executed (is fired) when an insert,
update, or delete operation is
executed.
return status
A value returned from a function, a
runtime
database procedure, or a stored
The execution of an application, as
procedure that indicates whether the
opposed to its development.
function or procedure was completed
successfully.
script
A collection of VISION 4GL
revision statements that define the methods of
A specific version of an object that is a class.
maintained by version control and is
identified by a revision number.
script statement
A line in a script. A statement is
associated with an event section that
rollback transaction operation determines when the statement is
An operation that aborts the current executed.
transaction and reverses all operations
performed by the transaction.
scroll bar
A graphical device with arrows.
Moving a scroll bar access data not
row visible in a list box.
The database object that consists of a
unique set of related columns that
constitute a single entry in a table. select
Sometimes called a tuple. A method of indicating which object
See also column; record. or data is available for a subsequent
operation.
RTF (rich text format) selected set

A specification for formatting A group of records that are copies of
documents. rows selected from a database table.
Glossary 161
service stippled
A collection of methods in a script Disabled, indicated by shading an
that work together to perform some object with small dots.
non-graphical functionality. Other
objects use the methods to perform a stored procedure
given task. A set of database commands stored in
and executed by the DBMS.
shadow library
A version of a class library that has subclass
external references resolved. A class that is created from and
associated with another class
definition.
share update lock See also base class; inheritance.
An ORACLE lock that is placed on
selected rows to allow concurrent subform
access to the table. A form contained in a form class.
shared lock system administrator

See read lock. A person responsible for
administrative tasks, such as creating
user accounts, assigning access
shell permissions, and creating databases.
The operating system command
interpreter. system information field
A predefined field that is used to
slider display system information.
An object used to select a discrete
value from a defined range. A slider is table
a type of view. The database entity that stores related
See also check box; list box; text rows and columns. Sometimes called
field. a relation.
target field
sort A form field that is associated with a
To arrange objects based on an specific column in the target table for
ordering criteria. the form.
See also column.
SQL (structured query language)
A relational database language that target field variable
provides statements for creating, A variable that has general variable
manipulating, or searching tables, attributes, field variable attributes and
based on an English keyword syntax. target variable attributes.

target table title bar
The database table that is associated The area across the top of a window
with a specific form. that displays the title of the window.
tool
target variable A utility to help you build your
A variable that is associated with a application.
specific column in the target table for
a form. The target variable has the
same name as its associated target tool bar
table column. A row of buttons with frequently used
commands.
See also general variable; variable.
transaction
text field A set of one or more database or
An object used to display one line of transaction operations that must be
text. completed as a single unit.
transaction abort error

text label An error that causes the DBMS to
An object used to identify another abort the transaction.
object.
trigger
A special stored procedure that is
text pane executed (fired) when an insert,
A box usually containing more than update, or delete operation is
one line of text. executed.
undefined
text view Uninitialized; a variable that has no
View of a field which displays text. valid value or type associated with it.
See also field; view; text pane; text See also null.
field.
Unify VISION foundation class
A predefined class definition provided
timer with VISION Development
An application event, defined by the Environment. All classes that you
developer, that is executed after a create are subclasses of one of the
specified time period. foundation classes.
Glossary 163
unique index version archive
An access method by which specified An file that stores objects maintained
ordered column values that form a under version control. The version
unique key are used to select database archive is a file that contains the
rows. information needed to reconstruct any
revision of the object.
version control
update System in which revisions of an
An operation that changes an existing object are maintained in version
row in or adds a new row to the archives.
database table.
view
(DBMS) A subset of columns from
one or more database tables.
user
Any person who uses a completed
application. view
(Unify VISION) The visual
representation of an object that
provides a user interface to the object.
user name
The name used by the current user to VISION 4GL
log in to the database. The Unify VISION fourth-generation
language used to create scripts and
global functions.
value parameter
VISION Class Browser
A function parameter that is defined
as a local variable and initialized with The Unify VISION tool that allows
a value when the function is called. you to create and modify the contents
When execution returns to the calling of a class library.
program, the argument value remains
unchanged. VISION client
A Unify VISION application instance
that is acting in a client role.
variable VISION Designer

A name that is used to represent a The Unify VISION tool that the
value. developer uses to create and design
See also general variable; target graphical classes and place them on
variable. forms.

VISION Development Environment window
The Unify VISION tool that provides a The active visual frame enclosing a
fully graphical, integrated runtime portion of a Unify VISION
environment for developers to create application. The bottom of a window
and maintain applications. has controls such as Apply, Close, and
Help. The top of the window has
icons that enable you to move, resize,
iconify and quit the window. The
exact controls are dependent upon the
graphical user interface.
VISION Manager
The Unify VISION runtime work area
component that executes an A project, folder, or library that
application partition. contains a single users working
(updateable) copies of objects that are
maintained by version control.
write lock
VISION Script Editor An instruction that prevents both read
The Unify VISION tool for editing and write access to a specified
scripts. database row or table by all
transactions other than the transaction
that placed the write lock.
See also read lock.
width zoom form

A type of child form that displays
The horizontal size of an object in
information related to the current
pixels. form and that can return values to the
current form.
Glossary 165

Conceptos PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Conceptos PDF

Transféré par

Droits d'auteur :

Formats disponibles

R

Unify VISION Product Manager

About this manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Unify VISION: Concepts

6 Unify VISION: Concepts

Using this manual

This manual is intended primarily for the application developer.

The Unify VISION application development software is a programming

Operating system interface and file structures

italic words Italic words indicate arguments, variables, numbers, or

UPPERCASE Boldface UPPERCASE words are Unify VISION reserved

UPPERCASE Other UPPERCASE words represent Unify VISION data

! A right-pointing arrow represents the path to a command

variable The name of a developer-defined variable can be

10 Unify VISION: Concepts

function$ All Unify VISION system functions are suffixed by a

Windows The term Windows indicates Windows 95, Windows 98,

Title Chapter and section titles are enclosed by a pair of

This manual contains specially marked paragraphs containing noteworthy

Tip A tip contains a suggested action or other helpful information.

OO Principle An OO principle is a reference identified as [Taylor], and is quoted with

About this manual 11

Unify VISION feature overview

This chapter describes the general features of Unify VISION:

Unify VISION client/server architecture provides an advanced

Unify VISION client/server architecture has several characteristics:

14 Unify VISION: Concepts

Unify VISION couples its powerful client/server architecture with a

VISION Development Environment gives you easy access to everything

Additionally, Unify VISION combines an event-driven, object-oriented

Chapter 1: Unify VISION feature overview 15

Some of the advantages of this flexibility include:

Related information For more information about the object-oriented development of

16 Unify VISION: Concepts

The advanced application partitioning of Unify VISION allows you to

Some of the features of multi-tier, dynamic application partitioning

Chapter 1: Unify VISION feature overview 17

Unify VISION supports ActiveX containers on forms. These containers

For information about ActiveX automation, see ActiveX automation on

18 Unify VISION: Concepts

Studio was created specifically for web builders and application

Server-side components deployed as VISION AppServer services are

Chapter 1: Unify VISION feature overview 19

Unify VISION objects, classes, and

Some information in this chapter is from Object-Oriented Technology:

As it executes, a Unify VISION application is composed of a series of

Attributes and methods of an object

A foreground and background color attribute

Some Unify VISION objects have attributes and no methods, such as

OO principle An object is a software packet containing a collection of related data (in

22 Unify VISION: Concepts

Unify VISION objects can be divided into two categories: graphical

There are three types of non-graphical objects: services, global functions,

Profiles are objects that specify environment information including how

A partition group profile, used in partitioned applications only, specifies

Using the terms object and class

A Unify VISION object is technically an instance of a class. So, from a

Chapter 2: Unify VISION objects, classes, and methods 23

A class definition is a template that is used at runtime to build Unify

Every type of object in Unify VISION has a predefined class definition

OO principle A class is a template that defines the methods and variables to be

Unify VISION provides foundation classes that serve as master templates

24 Unify VISION: Concepts