OVERVIEW.............An Overview of the dCLIP Application Design System
DATA-DRIVEN..........What is "Data-Driven" and how is it useful?
DATA DICTIONARY......What is a "Data-Dictionary"?
THE CONCEPT..........The Application Design concept. How is dCLIP different?
ARRAY-DRIVEN.........What is an ARRAY-DRIVEN architecture?
ARRAY DEFINITIONS....Definitions of each sub-system array
GETTING STARTED......Getting Started with a Simple Application
OVERVIEW
An Overview of the dCLIP Application Design System
Description:
dCLIP was designed to be a versatile application design
tool. Many application design systems require that the
system designer adopt a methodology that is structured
around the likes and dislikes of the product author.
Of course, dCLIP takes on the personality of it's author,
like any other product, but it also provides an open
architecture that allows the user and programmer to work
around any problem he/she may encounter during the evolution
of his/her application.
dCLIP is a different type of application design tool than
most application development systems.
1. First, and foremost, it is a well-documented library of
functions and commands. The entire system is built
around this library. Every public function in the
library is prefixed with a DC_ and every DC_ function is
documented in the DCHELP.DBF database and the DCLIP.NG
Norton Guide compatabile database.
2. dCLIP is written almost entirely in Clipper and includes
all the source code. The programmer should never be
stuck in a corner with no where to evolve. The
architecture is as open as the architecture of Clipper.
3. dCLIP is an integrated development environment that speeds
up the process of development by including a Clipper
interpreter, a dynamic-linker and a set of commands and
functions specifically tailored for quick development.
4. dCLIP includes a set of design tools that allow the
programmer to build and maintain portions of the
application without requiring writing of any source code
at all. These design tools will build menus, file group
specifications, field group specifications, browse and
data-entry screens, dialogue screens and other special
features. Each design tool consists of an editor that
uses drag and drop or fill-in-the-blanks methods for
creating the application sub-system. This sub-system can
then be saved to a Data-Dictionary, array files or source
code. The designer/programmer has the option of deciding
which portions of the program to run from the data-
dictionary databases and which portions to commit to code
(for speed and the reliability of early-binding).
5. dCLIP is a complete application that can be used as a
Clipper learning tool or as a Database manager.
DATA-DRIVEN
What is "Data-Driven" and how is it useful?
Description:
The concept of "Data-Driven" applications has been around
for many years. Some languages are ideal for writing
data-driven applications, others are not. Clipper has
always been a better-than-average language for this kind
of application, but early releases just couldn't deliver
enough power to handle the job for large, mission-critcal
applications.
Many application developers are now finding that the
evolution of the Clipper language, operating systems, and
computer hardware in recent years has given rise to looking
at Data-Driven much more seriously than ever before. Take
the introduction of multi-dimensional arrays, Lexical
scoping, Virtual memory-management, protected mode linking,
Replaceable Data-Drivers, and basically a rock-solid release
in Clipper 5.2e. Add to this the improvements in speed and
reliability of the DOS operating system and WIN-95 or OS/2
DOS Windows. Throw in the advanced hardware technology with
huge amounts of disk space and super-speed 386/486/586
processors, and we now have the ingredients for building
applications an entirely new way - "Data-Driven".
WHAT IS DATA-DRIVEN?
Data-Driven applications are those in which the fundamental,
functional behavior of the application is defined in data-
tables rather than in code. For example, the definition of
a menu-system, a data-entry system, a browse configuration,
file and field specifications, even dialogue screens, can be
stored in databases and retrieved during the running of the
application to "drive" the application's basic functions.
WHY IS DATA-DRIVEN BETTER?
It isn't always better. For example, a very specialized
database application such as an "Appointment Scheduler"
system that requires complicated display screens would NOT
be a likely candidate for data-driven. The basic model for
scheduling of appointments varies only slightly from
business to business, so a well-written, hard-coded system
will very likely perform well for most business requirements.
On the other hand, a "Contact Manager" is an ideal appli-
cation for data-driven techniques because it must almost
always be specially tailored to meet the needs of the user.
Nearly every business handles contacts differently and
requires fields, validations, data-entry requirements,
reports, etc. that are suited for that business. This is
where Data-Driven concepts have proven themselves to be
invaluable when developing custom applications.
The pace of technology is forcing corporations to be much
more flexible in the handling of data than ever before.
A new federal or state law, new market opportunties,
competitive pressures, etc. can often require that an
application be modified to handle a variety of new field
and file definitions, data-entry requirements, and reports
with a rapid turnaround. It is becoming more and more
impractical to make these changes in code for a variety of
reasons:
1. Modifying code requires longer development and debugging
time.
2. Modifying code can increase the risk of de-stabilizing
the application and decreasing reliability.
3. Modifying code requires a high level of skill and
familiarity with the design of the application. This
limits the choice of personnel to handle the job.
4. Modifying code can be much more time-consuming when
performing language-translations.
WHEN SHOULD YOU CHOOSE DATA-DRIVEN OVER CODE?
Very few data-driven applications can be written without
requiring some amount of hard-coding. Here is a basic
checklist that will help you determine if your application
is a candidate for data-driven.
1. How powerful is the basic architecture of the "engine" that
drives the Data-Dictionary system? If the engine is weak
in its capabilities, then much of the application will need
to be hard-coded. If the engine is strong and robust in
its capabilities and architecture, then much of the
application can be Data-Driven.
2. How much of the application requires regular redefinition
of file, field or data-entry requirements? If the
application must be constantly adapted to changing needs,
then it is a candidate for data-driven.
3. How much of the application revolves around the process
of data-entry and queries such as lookups, searches, and
browses. If this percentage is high, then the application
could be data-driven.
4. How much of the application can be designed around a
set of menus that call pre-defined functional modules in
the library of routines supported by the "engine"? If
this percentage is high, then consider data-driven.
5. Will this application need to be ported to other operating
systems or languages? If the answer is yes, then Data-
Driven will improve in portability.
DATA DICTIONARY
What is a "Data-Dictionary"?
Description:
A Data-Dictionary is a collection of tables or databases
that defines the basic functionality or behavior of an
application. A good, well thought-out, Data-Dictionary
system is "normalized" to break down the basic elements
of an application in to logical sub-systems that can
then be easily hooked together. The dCLIP Data-Dictionary
system consists of the following files:
DCFILES.DBF - Used to store "FILE GROUPS" consisting of
information about databases, indexes and
relations that all make up a related group
of databases. Each File Group has a Unique
"Tag Name" that can be passed to functions
in the dCLIP library to restore (open) all
the files before operations such as data-
entry, browsing, or reports.
DCFIELDS.DBF - Used to store field attributes, default
validations, picture clauses, descriptors,
encryption codes, help codes, etc. for all
fields in all databases defined in the
application. Each field group is given a
unique name matching the ALIAS of its
respective database.
DCMENU.DBF - Used to store complete top-bar with pull-down
menu systems or sub-menu systems to be used
for driving an application. Each Menu has
a Unique "Tag Name" that can be passed to
functions in the dCLIP library for attaching
a menu to another menu, to a data-entry
screen, to a browse screen, etc.
DCEDIT.DBF - Used to store editing configurations for data-
entry. A configuration can consist of real
and/or virtual field placements anywhere
within an editing window. Fields may be
merged from Parent and Child databases. Field
descriptors, screen objects, colors, pick-list
options, menu and key tag references, page
layout, etc. are all stored in this dictionary
for restoring a data-entry screen.
DCBROWSE.DBF - Used to store browsing configurations for multi-
window browsing. A configuration can consist of
real and/or virtual field columns. Field columns
may be merged from Parent and Child databases
or configuration may be multiple browse windows
consisting of one-to-many relational browses.
Column headers, colors, pick-list options, menu
and key tag references, scoping options, column
totalling options, printing options, etc. are all
stored in this dictionary for restoring a browse
screen.
DCKEY.DBF - Used to store keyboard "KEY GROUP" definitions.
Any key on the keyboard can be temporarily
redefined to call a code block, stuff a string,
disable other keys. Key Groups are given "Tag
Names" so they can be passed to other functions
like data-entry, browse and dialogue screens.
DCUSER.DBF - Used to store log-on information, passwords,
and access keys to menus, databases, fields,
etc.
DCSCRN.DBF - Used to store Screen objects, such as boxes,
backgrounds, text, modal dialogues consisting
of Gets, radio-buttons, check-boxes, etc.
DCCODES.DBF - Used to store Code tables for data-entry
validations.
DCLOCKS.DBF - Used to store definitions of locks on menu
items, databases, fields.
DCFMAP.DBF - Used to store database "MAP GROUPS" for mapping
fields between groups of databases. Maps can
be used for transferring data from child
fields into parent fields after a validation
lookup or for filling in default information
when appending a new record.
DCPROG.DBF - Used to store "interpreted" programs. Each
program can be executed from the dCLIP
interpreter. Interpreted programs can include
any command that can be executed from the dot
prompt and DO..WHILE, IF..ELSE..ENDIF, DO..CASE,
BEGIN..END, FOR..NEXT, PARAMETERS, and RETURN
statements. Interpreted code can be used to
handle special customizing of validations,
input screens, etc.
DCHELP.DBF - Used to store general help and context-specific
help screens for a hyper-text style help
system.
DCPRINT.DBF - Used to store printer driver data.
DCGATE.DBF - Used to store DOS Gateway information for
calling other programs.
DCQUERY.DBF - Used to store Query expressions created by
the Query Builder for re-use at any time.
See Also:
FIELD EDIT
FILE EDIT
EDIT
BROWSE
CODE EDIT
KEY EDIT
MENU EDIT
THE CONCEPT
The Application Design concept. How is dCLIP different?
Description:
dCLIP's design tools work with "ARRAYS" of information.
In Object-oriented designs, these array are referred to as
"OBJECTS". dCLIP's archictecture is NOT Object-oriented
for a variety of reasons. For one, Clipper itself, is not
an object-oriented language. Yes, it has a few classes, but
the design team, for obvious reasons, have chosen not to
give the Clipper programmer the ability to create his/her
own objects. The basic architecture of Clipper, the
limitations of DGROUP under DOS, and the fact that Clipper
is a PCODE interpreter, do not fare well in creating
applications that are fully object oriented and event
driven.
dCLIP is an idea that has been evolving for about 7 years
(first release was late 1988). It started as a simple
programming tool to help the programmer get started faster
with Clipper. It's first major features were the dot-
prompt interpreter and the dynamic-linker. Over the years,
dCLIP users were the most instrumental in the evolution of
this product. It is now a serious application development
system and it's future focus will be in the area of rapid
and robust application design for multiple platforms, i.e.,
DOS, Windows, OS/2, Unix, etc.
Unlike many other application development systems, dCLIP
is, and will always be, a "hybrid" style of product, geared
toward the professional developer and consultant rather than
the casual programmer.
dCLIP is NOT a code generator, yet it writes source code
for many of the sub-systems.
dCLIP is NOT an application generator, yet it can be used
(with Clipper) to generate complete applications.
Most applications generated with dCLIP will consist of a
hybrid of custom code, function-library calls and Data-Driven
sub-systems. Unlike many other data-driven systems, dCLIP
itself IS NOT Data-Driven. It's basic functionality is
completely hard-coded in Clipper with a little bit of C and
ASM code. dCLIP's core functionality (the Engine) is
basically a collection of function calls that have been
linked into an .EXEcutable program and are connected together
via dot-prompt commands, menus and hot-keys to create a fully
functional program. dCLIP does not use any data-dictionary
files at all when accessing it's own editors, browsers,
pick-lists, menus, hot-keys or dialogue boxes. Like earlier
versions of dCLIP, databases may be edited and browsed using
any RDD supported by Clipper and no access to any data-
dictionary files are required to do any type of data
manipulation. The dCLIP.EXE engine will perform without
requiring any other files at all.
Data-Dictionary files (and their indexes) are automatically
created when, and only when, the designer/programmer decides
to use the design tools to help customize a menu, a screen,
a field configuration, a file-group configuration, a data-entry
configuration or a browse configuration.
ARRAY-DRIVEN
What is an ARRAY-DRIVEN architecture?
Description:
Each configurable sub-system is "ARRAY-DRIVEN", meaning that
the behavior of the customizable portion of the sub-system
is held in the arrays. During the design of a Data-Entry
screen, Browse-screen, Menu-system, etc., the array data is
manipulated by the associated editor. The arrays are
designed for "persistence" meaning that they can be easily
copied to a variety of storage systems, such as Databases,
memo fields, Text Files, Array Files and/or source code
for later retrieval.
When an array is retrieved, it is then passed to the
required sub-system for execution. For example, the
DC_MenuEdit() function is a menu editor system that is used
to load and edit a menu array from the DCMENU.DBF dictionary,
from a *.DCM menu-array file, or from a source-code function.
This array may then be passed to the DC_MenuMain() function
for running the menu.
Before an array is saved it must be assigned a unique
"Tag Name" which is used as a reference for later retrieval.
For example, after designing a main menu pull-down system
you may assign it the tag name "MAINMENU". When saving
this menu to the Menu Dictionary, each array element is saved
as an individual record in the DCMENU.DBF database and grouped
together by the common MENU_NAME field containing the "MAINMENU"
tag name. When saved as an array file, the entire array is
saved under one file named MAINMENU.DCM. When saved as
source code, a *.PRG file is created that contains a function
named MAINMENU_M(). This function, when called, will return
the contents of the menu array.
The advantages of designing a system this way start becoming
obvious especially when it's time to start building a hybrid
application. For example, when designing a main menu it is
often necessary to test the menu often to make sure it is
functioning properly. In this case, you would want to load
the menu array from the Menu Dictionary file, make the
changes, save the changes to the dictionary, then run the
menu from the dictionary. Once you are sure that the menu
is functioning properly, you can then choose to save it to
an array file or source code.
All the dCLIP sub-systems were designed to retrieve
configuration arrays by the fastest method possible. Let's
take the example of the DC_MenuRun() function. This is the
function that is used to retrieve a menu by its tag name
and pass it to DC_MenuMain() for execution. Here's the
order of events when dCLIP is processing a menu for
execution for the example:
DC_MENURUN("MAINMENU"):
1. The DC_MENULOAD() function is called to retrieve the
menu from it's source.
a. First, the MENU CACHE is tested to see if the menu was
previously loaded and stored in Cache memory. The
size of the cache is determined by DC_MEMCACHE().
b. Second, the program is tested to see if a function named
MENUMAIN_M() has been linked into the program. If it
exists, then the function is called and its return value
is passed back as the menu array. This is the FASTEST
method of retreiving a menu array and does not open any
files at all. If the function does not exist, then:
c. Third, the directory established as the Dictionary
directory with the SET DCLIP=(directory) command is
searched for a file named MENUMAIN.DCM. If it exists,
then it is loaded to an array with the DC_ARESTORE()
function and passed back as the menu array. This is
the SECOND FASTEST method of retreiving a menu array
and does not open any databases. It also provides the
advantage of easily updating an application in the
field by simply copying an array file into the
dictionary directory. If the file does not exist, then:
d. Fourth, the DCMENU.DBF Menu Dictionary is searched
for a menu with the tag name "MENUMAIN". If it is
found, then it is loaded to an array, stored to the
menu cache and passed back as the menu array. If not
found, then an error message is displayed.
2. The array retrieved by DC_MENULOAD() is compiled into
an "executable" array that can be passed to DC_MENUMAIN().
Menu arrays must contain code blocks for executing func-
tions. Code blocks cannot be saved to disk so they must
be compiled first. The array is passed to DC_MENUCOMPILE()
which in turn passes back a compiled array.
3. The compiled array is passed to DC_MENUMAIN() for
execution.
All array driven sub-systems under dCLIP operate in basically
the same manner. See ARRAY DEFINITIONS for definitions of
each sub-system array and their methods of retreival.
See Also:
ARRAY DEFINITIONS
ARRAY DEFINITIONS
Definitions of each sub-system array
Description:
MENU ARRAY - Defines a Top-Bar/Pull-Down Menu
---------------------------------------------
This array is a 2-element array consisting of two
sub-arrays:
1. The first sub-array contains all the general information
about the menu, such as the menu tag name, screen location,
menu type, colors, help prompt options, behavior, etc.
2. The second sub-array contains one element for each top-bar,
pull-down, sub-pull-down, etc item in the menu.
See DC_MENUEDIT() for a specification of this array.
Order of events for loading the array with
DC_MENULOAD((cTagName)):
1. Test for function (cTagName)_M()
2. Test for an array file name (cTagName).DCM
3. Test for a menu named (cTagName) in DCMENU.DBF.
FIELDS ARRAY - Defines a Database Field-Group Configuration
-----------------------------------------------------------
This array is a 2-element array consisting of two sub-arrays:
1. The first sub-array contains all the general information
about the field group and database such as the Tag Name,
File Alias and Description.
2. The second sub-array contains one sub-array for each field
that actually exists in the database. Each sub-array
contains information such as field name, type, length,
decimals, default, descriptors, picture, default value,
validation techniques, encryption password, etc.
See DC_FIELDEDIT() for a specification of this array. The
array element definitions are also documented in DCFIELDS.CH.
Order of events for loading the array with
DC_FIELDLOAD((cTagName)):
1. Test for function (cTagName)_G()
2. Test for an array file name (cTagName).DCG
3. Test for a Field configuration named (cTagName) in
DCFIELDS.DBF.
FILES ARRAY - Defines a File-Group Configuration
------------------------------------------------
This array is a 2-element array consisting of two sub-arrays:
1. The first sub-array contains all the general information
about the file group such as the Tag Name, Description,
default directory, Date, Time and User who last edited
files, etc.
2. The second sub-array contains one sub-array for each
database, index tag or relation that makes up a group of
related databases. Each sub-array contains information
such as file name, alias, RDD, Index Key, Description,
parent-child relations, etc.
See DC_FILEEDIT() for a specification of this array. The
array element definitions are also documented in DCWORK.CH.
Order of events for loading the array with
DC_FILELOAD((cTagName)):
1. Test for function (cTagName)_W()
2. Test for an array file name (cTagName).DCY
3. Test for a Field configuration named (cTagName) in
DCFILES.DBF.
EDIT ARRAY - Defines a Data-Entry Configuration
-----------------------------------------------
This array is a 3-element array consisting of three
sub-arrays:
1. The first sub-array contains all the general information
about the data-entry screen such as the Edit Tag Name,
screen location, size, screen options, relation options,
Menu tag name, Files tag name, Browse tag name, Keys tag
name, etc.
2. The second sub-array contains one element for each screen
object that is painted in the edit window. Screen objects
can be text, boxes, radio-buttons, check-boxes, etc.
3. The third sub-array contains one sub-array for each field
that is painted in the edit window. Each sub-array
contains information such as field location, descriptors,
colors, editing options, validation techniques, and other
properties.
See DC_EDITDB() for a specification of this array. The
array element definitions are also documented in DCEDIT.CH
and DCFIELDS.CH.
Order of events for loading the array with
DC_EDITLOAD((cTagName)):
1. Test for function (cTagName)_E()
2. Test for an array file name (cTagName).DBE
3. Test for an Edit configuration named (cTagName) in
DCEDIT.DBF.
NOTE: All EDIT arrays are loaded into a public array named
DCEDIT and their locations within the DCEDIT array
are equivalent to the work-area for each database.
For example, if the file CUSTOMER is opened in work
area 10, then the EDIT array with the Tag Name of
"CUSTOMER" will be loaded into DCEDIT[10].
BROWSE ARRAY - Defines a Database Browse Configuration
------------------------------------------------------
This array is a 2-element array consisting of two sub-arrays:
1. The first sub-array contains all the general information
about the browse screen such as the Browse Tag Name, screen
location, size, screen options, relation options, column
locks, Menu tag name, Files tag name, Browse tag name, Keys
tag name, etc.
2. The second sub-array contains one sub-array for each column
that is painted in the browse window. Each sub-array
contains information such as column width, headers,
colors, editing options, validation techniques, and other
properties.
See DC_BROWSEDB() for a specification of this array. The
array element definitions are also documented in DCBROW.CH
and DCFIELDS.CH.
Order of events for loading the array with
DC_BROWLOAD((cTagName)):
1. Test for function (cTagName)_B()
2. Test for an array file name (cTagName).DBR
3. Test for a Browse configuration named (cTagName) in
DCBROWSE.DBF.
NOTE: All BROWSE arrays are loaded into a public array named
DCBROWSE and their locations within the DCBROWSE array
are equivalent to the work-area for each database.
For example, if the file CUSTOMER is opened in work
area 10, then the BROWSE array with the Tag Name of
"CUSTOMER" will be loaded into DCBROWSE[10].
SCREENS ARRAY - Defines a Screen Configuration
-----------------------------------------------
This array is a 2-element array consisting of two sub-arrays:
1. The first sub-array contains all the general information
about the Screen group such as the Screen Tag Name and
Description.
2. The second sub-array contains one element for each screen
object that is painted in the edit window. Screen objects
can be text, boxes, radio-buttons, check-boxes, etc.
See DC_SCRNEDIT() for a specification of this array.
Order of events for loading the array with
DC_SCRNLOAD((cTagName)):
1. Test for function (cTagName)_S()
2. Test for an array file name (cTagName).DCS
3. Test for a Screen configuration named (cTagName) in
DCSCRNS.DBF.
KEYS ARRAY - Defines a Group of Hot-Keys
-----------------------------------------
This array is a 2-element array consisting of two
sub-arrays:
1. The first sub-array contains all the general information
about the key group, such as the Key Group Tag Name,
and description.
2. The second sub-array contains one element for each defined
key in the key group.
See DC_KEYEDIT() for a specification of this array.
Order of events for loading the array with
DC_KEYGET((cTagName)):
1. Test for function (cTagName)_K()
2. Test for an array file name (cTagName).DCK
3. Test for a Key group named (cTagName) in DCKEY.DBF.
See Also:
ARRAY-DRIVEN
GETTING STARTED
Getting Started with a Simple Application
Description:
The best way to get started with understanding how to use the
dCLIP design tools is to open a few databases and indexes at
the dot-prompt, then "capture" the work area information into
various editors such as the Field Spec. editor, the File Spec.
editor, the Browse Editor and the Data-Entry editor.
Here's an example of getting started by using the CUSTOMER,
INVOICE and INVITEMS databases from the \DCLIP4\TUTOR
directory.
1. Open each database in a new work area, then use the
FIELD EDIT command to load the Field Spec. Editor with
the database structure. Save each Field Group to the
DCFIELDS.DBF dictionary before exiting the Field Spec.
Editor.
. SET DEFAULT TO \DCLIP4\TUTOR
. USE CUSTOMER
. FIELD EDIT
. USE INVOICE NEW
. FIELD EDIT
. USE INVITEMS NEW
. FIELD EDIT
The above action will create a default set of Field Spec.
properties for the three databases and store them in the
Field dictionary.
2. Create indexes and set relations for the three databases.
. SELECT INVOICE
. INDEX ON CUST_NMBR TO INVCUST
. SELECT INVITEMS
. INDEX ON INV_NMBR TO INVITEMS
. SELECT INVOICE
. SET RELATION TO INV_NMBR INTO INVITEMS
. SELECT CUSTOMER
. SET RELATION TO CUST_NMBR INTO INVOICE
3. Run the File Spec. Editor with the FILE EDIT command.
This will read the current work areas into the file spec.
editor. Save the file group to the DCFILES.DBF dictionary,
then exit the File Spec. editor.
4. Run the Browse Editor with the BROWSE RELATION command.
This will create three (3) browse windows. The first window
will display all records in CUSTOMER.DBF. The second window
will will display all records in INVOICE.DBF that relate
to the selected record in window 1. The third window will
display all records in INVITEMS.DBF that relate to the
selected record in window 2.
5. Save the Browse Configuration to the Browse Dictionary by
selecting (F), (C), and (S) from the menu. Enter the
BROWSE TAG name "CUSTOMER" with a description of "Customers
and Invoices". Enter the FILES TAG name "CUSTOMER" to
establish the CUSTOMER file group as the file group to open
before restoring the browse configuration. Click on the
Radio Button titled ALL OPEN WORK AREAS, so that the window
configurations for all three databases are restored.
6. Run the Data-Entry Editor with the EDIT command. This will
create 1 Data-Entry window with fields from all three work
areas. Select (V), (S), then (R) from the menu to SET
RELATIONAL FIELDS OFF. This will repaint the Data-Entry
window so it includes only the fields from the current
work area. Perform this operation for each work area as
follows:
. SELECT CUSTOMER
. EDIT
Save the Data-Entry configuration to the Data-Entry
Dictionary by selecting (F), (C) and (S) from the menu. Enter
the EDIT TAG name "CUSTOMER" with a description of "Customers".
Click on the Radio Button titled CURRENT WORK AREA then press
F10 to save the configuration and exit the Data-Entry system.
. SELECT INVOICE
. EDIT
Save the Data-Entry configuration to the Data-Entry
Dictionary by selecting (F), (C) and (S) from the menu. Enter
the EDIT TAG name "INVOICE" with a description of "Invoices".
Click on the Radio Button titled CURRENT WORK AREA then press
F10 to save the configuration and exit the Data-Entry system.
. SELECT INVITEMS
. EDIT
Save the Data-Entry configuration to the Data-Entry
Dictionary by selecting (F), (C) and (S) from the menu. Enter
the EDIT TAG name "INVITEMS" with a description of "Invoice
Items". Click on the Radio Button titled CURRENT WORK AREA
then press F10 to save the configuration and exit the
Data-Entry system.
7. Now that the FIELD, FILE, BROWSE and DATA-ENTRY configurations
have been save to the different dictionaries, let's restore
everything. To be sure that we are starting with a clean
slate, quit dCLIP then start it up again and enter the
following commands:
. RESTORE WORK FROM CUSTOMER
. BROWSE
The FILE, FIELD and BROWSE dictionaries will all be accessed
to restore the configuration. From the Browse menu select
(E) then (E) to call the Data-Entry system. The DATA-ENTRY
dictionary will be accessed to restore the Data-Entry
configuration.