Translate this page automatically.
dCLIP 4.0 Product Information
Introducing dCLIP 4.0
How is dCLIP Different?
What is Data-Driven?
What is a Data-Dictionary?
What is an Array-Based Architecture?
Highlights of dCLIP 4.0 Features
The dCLIP 4.0 On-Line Manual
dCLIP - Year 2000 Compliance Statement
Introducing dCLIP 4.0
The purpose of dCLIP has always been to speed application design while
remaining the easiest-to-use database management tool and library for
Clipper. With dCLIP 4.0, we bring you many new design tools that will
allow you to speed your development as well as give your designs
greater flexibility, portability and ease of maintenance.
We have waited to introduce data driven concepts to dCLIP until we were
able to do extensive testing to prove its success in large data-driven
applications. We are now confident that we have a set of robust
library functions that support the data-driven concept. Data-driven
applications have proven to be the most portable of all applications.
This has caused system development to move in the direction of
data-driven. Because the behavior of the application is defined in
data tables rather than code, this behavior can then be ported to
other platforms like Windows, Unix, AS-400, etc. Much of the behavior
of an application is the definition of data-entry screen, validations,
menus, field and file specifications, browse configurations and reports.
Both the dCLIP 4.0 "DOS Version" and dCLIP 4.0 "Windows Version"
(expected release in Last Quarter '96) can use the same data-dictionary
tables and run applications concurrently.
dCLIP 4.0 allows Clipper developers to satisfy the desires of end-users
As Windows applications continue to evolve, many Clipper programmers
are finding that they don't necessarily need to convert their legacy
applications to run as a true Windows applications, but instead can
satisfy the needs of their user-base by simply improving the user-
interface of the DOS (Clipper) application so it will run well in a
Windows DOS box or an OS/2 DOS box and have the look and feel of a
Windows application. From our experience, we have come to the
realization that converting a Clipper application to Windows (even
with Visual Objects) could take several years, whereas improving the
same DOS application using the new dCLIP 4.0 library and design tools
could take only weeks or months.
dCLIP 4.0 is fully compatible with previous versions
dCLIP 4.0 continues to be evolutionary rather than revolutionary. Our
goal is to help prevent revision-shock while bringing you ever more
powerful tools. We have designed dCLIP 4.0 to create an easy
transition for you to the world of data-driven techniques.
dCLIP 4.0 has metamorphosed into an application generator
The developers of application designers make many promises, however,
they rarely deliver on the promises because no application generator
or code-generator can build a complete application that satisfies
every need of the sophisticated programmer and user. dCLIP 4.0 is
a whole new class of application generator that provides the developer
with an architecture never before offered in a Rapid Application
Development system.
The Application Design concept. How is dCLIP 4.0 different?
dCLIP's design tools work with "ARRAYS" of information. In Object-
oriented designs, these arrays 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 8 years (first
release was late 1989). 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.
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 API library) 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. 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.
dCLIP 4.0 was designed to be a versatile application design tool with 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 4.0 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.
What is Data-Driven and how is it useful?
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, and dialogue
screens, can be stored in databases and retrieved during the running of
the application to "drive" the application's basic functions.
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-critical 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, Windows-NT, OS/2 DOS Windows. Throw in the advanced
hardware technology with huge amounts of disk space and super-speed
486/586 processors, and we now have the ingredients for building
applications a better way - "Data-Driven".
The requirements for database browsing and editing systems are as
different as every person who uses the program. Even with the
sophisticated features of Tbrowse and the new 5.3 menu class, changing
a browse and/or data-entry configuration requires changing source code.
dCLIP 4.0 has a set of design tools that allows on-the-fly design of
browses, data-entry screens and menus for most database requirements
without the need to change source code. This is accomplished by
designing a living application that allows multiple, relational windows,
validations, field-descriptors, column-order and field-order, pictures,
column-widths, field-placement, totals, scoping options, screen
background options, and even a custom user-defined pull-down menu. All
this can be accomplished with live data in a true WYSIWIG fashion using
the keyboard and the mouse. After the design is completed, the browse,
edit, key menu, screen and file arrays can be save to the Data-
Dictionaries, array files or source code. Restoring the browse, data-
entry, menu, key, file-group and/or screen configuration is as simple
as running a function with a passed array returned from the generated
source code or by passing the function the tag name of the configuration
in the data-dictionary.
When is Data-Driven Better?
Even though Data-driven concepts are superior in many application design
projects, it isn't always the best choice. For example a "Contact
Manager" is an ideal application 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.
On the other hand, a very specialized database application such as an
"Appointment Scheduler" system that requires complicated display screens
and reports 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.
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.
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 API Library? 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.
What is a "Data-Dictionary"?
A Data-Dictionary is a collection of tables 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, access keys to
DCLOCKS.DBF menus, databases, fields, etc. and definitions of locks on
menu items, database fields, etc.
DCSCRN.DBF - Used to store Screen objects, such as boxes, backgrounds,
text, modal dialogues consisting of Gets, radio-buttons,
check-boxes, push-buttoons, mouse-events, etc.
DCCODES.DBF - Used to store Code tables for data-entry validations.
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 for
a hyper-link style help system.
DCPRINT.DBF - Used to store printer driver data.
DCQUERY.DBF - Used to store Query expressions created by the Query
Builder for re-use at any time.
What is an Array-Based architecture?
Each configurable sub-system is "ARRAY-BASED", 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 becomes 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 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 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= 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 calling functions. Code blocks cannot be saved to
disk so they must be compiled. 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.
Highlights of dCLIP 4.0's new features
Data-Dictionary system provides for design of quick applications with
little or no code. Applications are automatically moused and designed
for Windows-like look and feel.
New Designer Tools: Menu Editor, Browse Editor, Data-Entry Editor,
File Editor, Field Editor, Screen Editor, Report Editor, Program Editor,
Modal Dialogue Editor, etc.
Clipper 5.2 and 5.3 compatability. Full downward compatablity with dCLIP
versions 2.5 thru 3.5. It is NOT required to own Clipper 5.3 to use
these new design features nor is it required to run any Windows
applications (i.e. the Clipper 5.3 IDE). The design tools are written
in Clipper (dCLIP 4.0 functions) and can be even linked into your own
applications. The source-code is written using some conditional-compiling
to allow access to new features supported by the 5.3 RDD system that are
not available in 5.2. For example, Comix and FlexFile technology are now
part of the 5.3 RDD system and will behave like other Clipper RDD's
rather than products that are hybrids (RDD/API). This means that when
using the Clipper 5.3 version of dCLIP 4.0, you will automatically have
database optimization features included when using the new DBFCDX driver
with no recompiling required.
Fully protected-mode compatible with Blinker, ExoSpace and CauseWay.
Better memory management. Many dCLIP 4.0 functions use only a fraction
of the Eval Stack space of previous versions. The Eval Stack is the
portion of DGROUP that is used to push LOCAL values. Applications that
use many LOCALS with deep nesting of calls can blow up the Eval Stack.
dCLIP 4.0 uses a system of LOCAL Arrays to prevent stack problems in
large applications. In addition, great care was taken to insure that
dCLIP 4.0 uses no more conventional memory than previous versions even
though more than 500k of .OBJ code has been added to the library to
support the 110 new functions and the new data-dictionary system.
Improved User Interface. dCLIP 4.0 provides improved user-interface
features like a better pull-down menu system, context-help, better
browsing and editing, an improved dot-prompt interpreter, an improved
Assistant, better dialogue screens with support for Check boxes, Radio
Button Groups, List Boxes, Push-buttons and, of course, full mouse
support.
Improved Browsing power combined with simpler and quicker on-the-fly
Browse designs. Save configurations to data-dictionary, array files or
source code. New features include column totalling, column scoping,
column color-configuration, column sizing and relocating via the mouse,
improved speed on relational and filtered databases, etc. Improved Browse
printing features make the browse system into a simple to use, columnar-
oriented report editor.
Improved Data-Entry power combined with simpler and quicker on-the-fly
Editing designs. Data-Entry screens may consist of multiple pages of
field GETS or horizontal and vertical scrolling GETS. Field properties
allow for display and printing options, powerful validation techniques
including pop-up data-base or array pick-lists, code-tables, run
interpreted code, auto-fill, range-checking, calendar, calculator, etc.
Data-Entry screens can be designed with no required coding. Save
configurations to data-dictionary, array files or source code. Improved
printing features make the Edit system into a simple to use, page-oriented
report editor.
New Menu system provides improved support of sub-sub-menus, help-messages,
context-help, gray-items,user access keys, evaluations, code-blocks and
return values. Much lower memory usage and better performance than
earlier versions. Menu-designer allows design of complicated menus with
no coding required. Test the menu and make modifications from the menu
designer, then save menus to Data-Dictionary, array files or source code.
Menu are "compiled" to arrays when they are pulled from they data-
dictionary and passed to the menu execution function. Conditional-
compiling allows items or sub-menus to be excluded "on-the-fly" at run-
time by simply passing a compile "key" or evaluating a code-block.
Improved GET system and Dialogue Screen Designer now supports (in addition
to full mouse support) Hidden Gets (for passwords), Radio Buttons, Check
Boxes, Scrollable Gets, CUA-compliant option, alternate navigation modes,
etc. Easy-to-use syntax makes design of improved dialog boxes a breeze.
Example:
@ 15,12 SAY '40 Lines' GET aRadio[1] RADIOGROUP 1 MEMVAR nLength ;
DELIMS '(*)' VALUE 40
@ 16,12 SAY '55 Lines' GET aRadio[2] RADIOGROUP 1 MEMVAR nLength ;
DELIMS '(*)' VALUE 55
New Help system is now fully context-sensitive and integrated with menu
system, browse system, data-entry system and any custom code. System
includes hyper-links and improved printing options. Help maintenance
system even writes Norton Guide and Expert-Help source code.
Windows-style *.INI file support functions.
Improved Interpreter. The dCLIP Interpreter now supports structural
statements like DO WHILE..ENDDO,FOR..NEXT, IF..ELSE..ENDIF,
DO CASE..ENDCASE, PARAMETERS, and RETURN values. The interpreter
provides the ability to create quick and complex data-driven validations
and custom code without the need to compile the program into the .EXE.
The new DCPROG.DBF (program dictionary) makes it easy to create
on-the-fly interpreted programs and simply execute them with the new
DC_PROGRAM() function.
New Key Editor. dCLIP 4.0 has several new functions that make it easy to
store "Key Groups" in a Key Dictionary file and load, edit, delete,
display, etc. key groups in your application. Key Groups allow you to
control the behavior of virtually any key on your keyboard. Store
Strings, macros, code-blocks, or even disable a key. Create new key
groups quickly by tagging keys from a "TEMPLATE" of all available keys.
150 New Functions and commands. Some Examples:
SET DOSKEY ON|OFF
SET CUA ON|OFF
CODE [EDIT] [DELETE] [{group}]
FIELD [EDIT] [DELETE] [{group}]
FILE [EDIT] [DELETE] [RESTORE] [{group}]
MENU [EDIT] [DELETE] [RUN] {menu}
SCREEN [EDIT ] [PAINT] [DELETE] {group}]
BROWSE [RESTORE {config}] MENU {mnu} KEYS{keys} [PROTECT]
EDIT [RESTORE {config}] MENU {mnu} KEYS {keys} [PROTECT]
DC_Ar2Str() Convert an array to a string for storing to memo field
DC_Array2Prg() Write an array to a source-code file
DC_BrowRestore() Restore a browse configuration from array or dictionary
DC_BrowSource() Create source-code from a browse configuration
DC_DictRdd() Set the RDD to be used for all dictionary databases
DC_EditRestore() Restore an edit configuration from array or dictionary
DC_FieldArray() Create a new field array from work area info
DC_FieldConfig() Edit the contents of a field array item
DC_FieldEdit() Edit a field definition array
DC_FieldValidate() Validate data-entry based on field spec properties
DC_FileArray() Return an array of work-area (file group)info
DC_FileLoad() Load file group array from DCFILES.DBF dictionary
DC_HelpF1() Display or Edit Context-Help
DC_IniLoad() Load an array from a *.INI file
DC_IniSave() Save an array to a *.INI file
DC_KeyLoad() Load Set-Keys from the Key Dictionary Group
DC_MenuCompile() Compile a menu array to an executable menu
DC_MenuEdit() A Complex Pull-Down-Menu Designer/Builder
DC_MenuLoad() Load a menu array from Menu-Dictionary
DC_MenuRun() Load, compile, and run a menu from menu dictionary
DC_Program() Run an interpreted program from the Program dictionary
DC_QueryA2S() Convert a Query Array to a Conditional expression
DC_ReadWindow() Set @SAY..GET Scroll-Region for DC_ReadModal()
DC_ScrnEdit() A screen-designer and editor
DC_ScrnPaint() Paint a screen with objects from a Screen array
DC_Str2Ar() Convert a string or memo to an array
DC_Token() Extract a token from a string
DC_TokenArray() Extract all tokens in a string to an array
DC_UserAccess() Determine if user has key to a specified lock
DC_UserInfo() Return information about logged-on user