Dexterity is more than a programming language; it is a comprehensive Integrated Development Environment (IDE). Dexterity is the tool that was used to create Dynamics GP in the first place. This proprietary tool was created by Great Plains Software, Inc. in the late 1980s. While most other financial application vendors were using toolsets developed in Visual Basic, Dexterity was written in C++ with the .NET elements written in C#. This is significant because Visual Basic is only available from one vendor, Microsoft. On the other hand, C++ is a standards-based programming language. As a standards-based language, you can purchase it from any number of vendors.
C++ is compatible with C and other languages, thereby offering portability and modularity. Being a standards-based language means there is an actual ISO standard defining the C++ architecture. You can purchase a copy of the latest currently published C++ standard at http://goo.gl/DP72P.
This section describes Dexterity in general and the features comprising it.
The Resource Explorer is the home page of the development environment. You design the user interface, build the code that defines the business logic, and create reports, all from this single interface. In short, it is from within the Resource Explorer that you create every aspect of your Dexterity application. The Resource Explorer is illustrated in the following screenshot:
Resources are stored in a file with a .dic extension called a dictionary. Each dictionary file includes all of the resources necessary to deliver a complete application. We'll talk about Dexterity resources in more detail in Chapter 3, Getting started with Dexterity, but in general, resources include:
Application Information – the product's name and build number
Base components:
Composites – a group of fields that form a single data type
Constants – an alias for another value used in scripts for readability
Data types – the type of information displayed or stored in a field
Fields – a single element of data
Formats – defines how a data type is displayed
Globals – fields that are available to any script at any time
Icons – a picture resource
Libraries – resource libraries and COM type libraries
Messages – predefined string values with an associated numeric reference used in scripts allowing for translation and substitution
Native Pictures – images that can be displayed on only one platform
Pictures – images that can be displayed across platforms
Strings – every occurrence of a string used in a dictionary
Table Groups – logical collections of related tables
Tables – a defined group of global fields
Forms – a collection of windows, scripts, menus, commands, and related tables
Reports – displaying or printing of a result set from a database query
Function scripts – global routines using parameters to pass data that always return a value
Procedure scripts – global routines using parameters to pass data
sanScript is the internal programming language you will use to write the code that provides business logic to the application. Scripts are attached to object events such as opening or closing a window, changing the value of a field, selecting a push button, picking a menu item, and so on. Your scripts run when the user causes the object event to occur. This behavior is what makes Dexterity an event-driven language.
The function library contains hundreds of specialized functions encompassing 45 different areas that allow you to implement key functionality in the application. Actions such as adding an auto-complete value to a specified field or adding an item to a list view field are examples of functions included in the function library.
Dexterity includes a built-in process you can use to recover from and document errors that occur while your application is running. Exception handling allows you to save the current state of execution at a specified point and then switch the execution to a subroutine known as an exception handler. The exception handler attempts to resolve the exception and then returns execution to the previously saved position.
Dexterity uses the throw and catch method to handle exceptions. The exception is raised, or thrown, to the exception handler. The catch method is the exception handler taking over code execution.
Dexterity supports integration with Microsoft Visual SourceSafe and Team Foundation Server. A generic provider is also included if you want to use another source code control program. The Generic provider uses a collection of text files to implement source control. You will be setting up and using the Generic provider in Chapter 11, Upgrading Customizations.
A single-pass, banded report writer is integrated into Dexterity. You can create simple text reports and lists or you can create presentation-quality documents with graphics and colors. However, since it only passes through the data once, a single-pass report writer has some pretty big limitations. For example, if you need to calculate a sum from which you can derive a percentage that you can show in the detail band of the report, you will need to write your own function to create the sum. Also, you cannot create the simple page X of Y notation.
To help with some of the limitations of a single-pass report writer, hundreds of user-defined functions are available to you for retrieving or manipulating data in a manner that you otherwise could not. For example, the RW_AccountNumber and RW_AccountDescription functions return the account number and account description of an account according to the account index you pass to the function.
The downside is that you won't find these user-defined functions documented in the software manuals. You will need to search the Knowledge Base in CustomerSource or PartnerSource to find instructions on how to use several of the functions. Using simply RW in your search criteria will retrieve many articles with instructions for several user-defined functions.
Report Writer also includes 21 built-in (well-documented) system functions that you can use to create calculated fields. Functions such as MONTH_NAME, used for pulling the name of the month out of a date value, and STRIP, for removing trailing spaces from a string field, are both examples of system functions.
As a developer, you can write your own user-defined functions to use with the Report Writer in order to solve problems similar to the derived percentage issue discussed earlier.
Component Object Model (COM) automation is a method you can use to access features and objects across different applications and languages. An object is something that can be acted upon, such as a button or a window. When using COM, one application can cause the other application to do something by following the rules described in an Application Programming Interface (API). Dynamics GP can provide access to its objects, which can be used by other programs. When it provides access to its objects, it is acting as an automation server. Dynamics GP can also access objects exposed by other applications. When Dynamics GP accesses objects on another automation server, it is acting as an automation client. The thing that allows access to objects is a server, and the one that is accessing the objects is a client. With Dexterity's COM support, Dynamics GP can act as both.
The Graphical forms designer is a WYSIWYG (What You See Is What You Get) tool used to layout and design the visual components of the application. You will create all of the components of the user interface using the Graphical forms designer.
Dexterity includes a source-level script debugger that you can use for interactive debugging of your application. These built-in tools provide the ability for you to set breakpoints in any script, apply conditions to break points, access scripts that are currently in the call stack, step through scripts one line at a time, display and set the values of fields and variables, and otherwise examine the state of your application at breakpoint.
In addition to the internal debugging tools, a Dexterity-based suite of tools called the Support Debugging Tool is available from Microsoft that allows you to examine, with precision, the specific series of events that led up to an error in your application. With the Support Debugging Tool, you can control and monitor all aspects of script execution. And best of all, it's free! Support for this tool is located at the Support Debugging Tool Portal at http://aka.ms/SDT.
Dexterity was ahead of its time, and is still unequaled in the development world. As we said earlier, Dexterity is both platform independent and database independent. Only the runtime engine is dependent on the platform. Standalone applications you develop using Dexterity can run on the Macintosh as well as the PC. Dynamics GP itself, however, no longer supports the Macintosh.
Dexterity currently supports three different databases Pervasive Software's P.SQL 2000 (formerly known as Btrieve), FairCom Corporation's c-tree Plus, and Microsoft's SQL Server. Switching between platforms or databases does not require any changes in the business logic code. If you're using the Microsoft SQL database, you can even use Dexterity to create and call SQL Stored Procedures.
The unique design of Dexterity keeps the technology piece of the application separate from the business logic. This strategy provides a means for Dynamics GP to update its technology without changing its code. For instance, Dynamics GP updated from a 16-bit application to a 32-bit application without re-writing the business logic. Beginning with version 7.0, Dexterity added COM (Component Object Model) support. Again, no code changes were required.