What is Focal Point?

Focal Point is a programmer’s tool for database programming. It encapsulates common data input/output operations, and enforces the automatic execution of pre-defined business rules when a record is created, deleted, saved, or navigated to. It also encapsulates the process of binding to outside, visual objects.

Focal Point is the middle-tier of a logically three-tiered software architecture. It acts as the "central clearinghouse" of information processing for Visual Basic (VB) applications. It enables the developer to drastically reduce lines of code, avoid common coding errors, and increase the clarity and maintainability of applications.

All data going between the databases and your applications pass through the lens of Focal Point. As the middle of the three software tiers, Focal Point separates the visual input front end from the raw data access on the back end.

Focal Point encapsulates most of the commonly used operations that you need to perform. It is a combination of many widely needed components specific to VB database applications.

Focal Point currently works with VB6 and databases accessed through ADO.

How does Focal Point work?

Focal Point is basically a "wrapper" around each ADO recordset created for any Table that can be accessed through Microsoft ADO. This wrapper is called the DataHandler. One of its most visible functions is that it acts like a DataControl which can bind to textboxes, checkboxes, grids, and other controls so that you don’t need to write ‘glue code’ to link your Form controls to your recordset.

And Focal Point DataHandlers can automatically link to other Focal Point DataHandlers of your Parent/Child/GrandChild tables in hierarchical fashion, so that all parents and children automatically follow the main table as the user changes rows.

Focal Point also implements the "Business Rules" in this middle tier, where they are properly maintained, separate from either the user input or the raw data.

For example, the following is executed by the Business Rules every time a new record is saved, to ensure a unique Customer ID Number:

Public Sub Creating ( )

dhCustomer.Field("CustIDNum") = GetNextUniqueIDNumber( )

End Sub

Focal Point is responsible for all the standard mechanics of data I/O and linkage between Tables. Focal Point does not control what you do -- rather, it coordinates, orchestrates, and facilitates it.

Is Focal Point a code generator?

No! Focal Point is not a code generator. And it does not lock you into a fixed application format. You write your code. Focal Point simply handles all the redundant details of data management, ensuring consistency and accuracy, and freeing you from having to laboriously code each and every repetitive detail surrounding common events like Add, Save, Delete, Move, etc.

For example:

When the "AddNew" method is called for the Customer file in Focal Point, the "Customer_AddNew" event is fired to the Form and also to the Business Rule object, looking for "hooks" that you have put in. The same is true for events like MoveComplete, Delete, Save, etc., so that you always have access to and control of what is going on with your data and screen. The same ‘event hooks’ exist at the field level such as "Customer_CreditLimit_ LostFocus" that is fired whenever focus leaves a control bound to Customer!CreditLimit.

Is Focal Point an "object-oriented" tool?

Yes, Focal Point embodies object-oriented functionality such as message passing, delegation, and augmentation.

Focal Point ships with some ActiveX controls. Are they required to run Focal Point?

To help make the Code section of your Form cleaner, we have taken the standard VB6 controls for Textbox and Checkbox and made them into an ActiveX control so that we can embed some simple, common functions. Thus, you don’t have to repeat this code for every such textbox or checkbox.

For example, the Focal Point Text Box bound to the Customer!CreditLimit field fires an extra event when it loses focus, telling the DataHandler that this just occurred. These activity status updates allow Focal Point to stay on top of all the nitty-gritty details that otherwise plague you. Also included are convenient features like "Capslock" and a built-in popup Selection List for navigating to other rows (with filter and sorting ability by ID, Name, etc). You are not required to use these controls, but they can make life easier. If you wanted to use your own textboxes, for example, you would just need to make sure they call an event like dhCustomer. EventHandler, "CreditLimit", "LostFocus" and they are about as good as the ones we provide.

Focal Point also comes with ActiveX command buttons for Recordset manipulation like Add, Undo, Save, Delete, First, Previous, Next, and Last. Again, these are just standard VB6 command buttons that were wrapped in an ActiveX control to simplify your code. The Save button, for example, knows to send the dhCustomer.RequestSave command when it is clicked. Thus, the "Save" code is not in your way when looking at the important code that you wrote in your application. Furthermore, these command buttons monitor their DataHandlers’ status buffers so they know automatically when to shadow themselves and when to re-.Enable themselves. The Save button for example, knows not to enable itself until the buffer is dirty, and to shadow (.Enable = False) itself when there are no records in the recordset. This is 100% taken care of for you automatically, though you are perfectly free to use your own such buttons and include all of this intelligence yourself.

Will Focal Point work with VB5 or earlier?

No. For both development and runtime, VB6 is required. We plan to make Focal Point fully functional with VB7 when it is released, but right now VB7 is still in pre-Beta.

Will my application look like a Focal Point product when I'm done because of mandatory hoops I have to jump through?

Definitely not. With the possible exception of the Selection List on the ActiveX textbox control that we include for free (which you don’t have to use, if you’ve got your own), your application follows your own VB style. The purpose of Focal Point is to encapsulate all the internal nitty-gritty details that every database application must deal with, in order to free up the developer for those things that are unique to his or her application. Along the way, we throw in some ActiveX controls (described above) to encapsulate things like Capslock and automatic shadowing to further clean up the simple-but-cluttering code in your Form.

Do I need to access my data through ADO?

Yes, the current Focal Point is built on the ADO 2.x standard, specifically ADO 2.2 and above.

What kind of data can I access?

Any data format that is supported by ADO 2.2 and above, such as those with OLE DB or ODBC drivers that support ADO level 2.2 or better.

Can I get at the recordset myself, or is it all wrapped up and hidden inside of Focal Point?

Yes, you can get directly at the underlying recordset anytime you want to (e.g. dhCustomer.rsData.Field("cCusID"), or dhCustomer.rsData.EoF, etc.). To take advantage of Focal Point’s power and to be consistent, we recommend that you use the exposed Focal Point properties and methods (e.g. dhCustomer.Field( "cCusID"), or dhCustomer.EOF)

Can Focal Point read outside recordsets in n-tier architecture where the database itself is not directly available?

Not right now, but possibly in the future. Currently, Focal Point uses its own ADO connection string to create and rebuild recordsets as needed during the course of typical operations. An upcoming version may allow Focal Point to be used with n-tier architecture even where direct access to the database is not available.

Can I mix-and-match recordsets of different formats?

Yes. Each DataHandler can have its own ConnectionString to the targeted ADO Table. So you can have one DataHandler for SQL Server, another for Jet, a third for Excel, and another using an ODBC driver for products like DataFlex. Microsoft’s ADO platform is what promises standard interface.

How many DataHandlers can I have in a Form?

Pretty much as many as you want. They are wrappers around ADO recordsets, and limitations on memory and performance are largely the same as you would expect in an application using those recordsets directly, without the Focal Point wrapper.

What's all this talk about "Business Rules"?

This is one of the truly powerful underlying features of Focal Point. While not everyone uses the term the exact same way, "Business Rules" in this context are those methods to be invoked as "hard and fast" rules for data operations.

For example: in the "How does Focal Point Work" question, we showed how the Creating method is used when a new record is first saved. Below is an example of how the "BackIn" method is used, as it is automatically invoked whenever a record is saved.

Public Sub BackIn ( )

dhCustomer.Field("Balance) = dhCustomer.Field("Balance) + dhInvoiceHeader.Field("Balance")

End Sub

The above would be part of the Business Rules. This rule ensures that whenever the dhInvoiceHeader is called upon to save a record (from your Form, someone else’s, another program, anywhere), that the parent’s! Balance field is properly updated. (The "BackOut" method would do the opposite with a deletion or removing the prior value.) This happens automatically and "invisibly" to your main code. It’s like having a company policy that everyone follows without being told each time.

The Business Rules are implemented as a Class in your VB Project, typically with one Business Rule Object (class) per Table. Other examples of standard methods in the Business Rule class include VerifySave, UpdateInternalFields, and CopyFieldsFromParent.

Are these Business Rule examples just like "Triggers"?

No -- they seem very similar, but the Business Rules have added functionality that is much more difficult to emulate in Triggers. For example, changing an Order Line Item from "5 Apples" to "7 Carrots" is very difficult to fully process with a single "Change record" trigger because not only does the Order Header quantity have to be incremented by a net of 2 (which a Trigger could easily do), but the Inventory record for Apples must be decremented by 5 while the Inventory record for Carrots must be incremented by 7, as well as subsequent processing that might be required for the parents of the Inventory records for Apples and Carrots. The "BackOut" takes care of 5 Apples, while the "BackIn" takes care of the "new" 7 Carrots. This is not very practical with a single trigger.

Can I call Stored Procedures?

Yes! Inside of the methods called by Focal Point (either to the Form or the Business Rule Object), you can execute any code that VB will let you normally do. Remember, Focal Point is not controlling what you do, it is merely coordinating and orchestrating it. Note that within Focal Point, you cannot (currently) replace its basic ADO calls (such as .Update, .Delete, etc.) with your own Stored Procedures.

Is this like SmallTalk?

In many ways, yes. One of the driving forces behind Small Talk and OO programming is to remove "spaghetti code" by organizing actions into small, logical pieces that can then be utilized in multiple, generic ways that would arise in applications. Each DataHandler knows how to handle its own data, and how to relate to its immediate parents and children only!

In the above example of changing an Order Line from 5 Apples to 7 Carrots, the dhOrderLine DataHandler knows only how to tell its immediate parent, the Inventory record, to decrement 5 from Apples, then navigate to Carrots and add 7. If there is a parent table above Inventory, such as FoodType (with header records for "Fruits", "Vegetables", "Nuts", "Dairy", etc), then it would be dhInventory’s task to have its Business Rules have a BackOut/BackIn method that updates its FoodType parent (i.e., "Fruit" for the Apples, and "Vegetables" for the Carrots) when such a change was given to it. This is an incredibly powerful way of keeping accurate track of complicated transactions, since each entity (the DataHandler) must only concern itself with its "immediate family" and it never, ever reaches out to affect any entity beyond its immediate parents or children.

What’s the FocalPoint Assistant?

It is a VB Add-In included with Focal Point to help remove even more of the tedious code-writing burden from your shoulders. Even the simple act of dropping Controls on a form and declaring the Focal Point objects can be a little time-consuming, and also presents an opportunity for typing errors that cause failures. When you add a control to a Form, you need to set its .DataField and .DataMember property, as well as make sure that a DataHandler object has been declared and instantiated for it. The Assistant does this code writing for you, so that you don’t have to worry about it. The first time you use a Table on a Form, it also adds the above-mentioned command buttons for Save, Undo, etc., which you can delete or keep.

The Assistant is not a code writer in the usual sense of the word; rather, it handles the following repetitive tasks for you:

• Adding a few lines of code for each DataHandler.
• Offering to create a basic Business Rule Object class file for you if one does not yet exist.
• /making sure that the spelling is correct for the Table name and field name on the newly-added Control’s .DataField and .DataMember property.

Does Focal Point support "Aliases", the ability to open the same Table under two different names simultaneously?

Yes, the line that "registers" each DataHandler allows for the Actual Table Name (e.g. "Customer") as well as a Virtual Table Name (e.g., "CustomerForBillTo" or "CustomerForShipTo").

Do I get to control all the ADO properties for the tables that Focal Point is handling for me, like .CursorLocation, .LockType, etc?

Absolutely. Those are properties of the DataHandler, which it in turn uses as the corresponding properties when doing the actual ADO recordset setup. Furthermore, Focal Point knows that some combinations (like Client-side, Keyset cursors) will not be allowed by ADO and that ADO will convert them to whatever ADO thinks is the closest legal combination. Focal Point will warn you when a recordset is created that has these properties changed for you (since ADO would just change it and never tell you about it).

Any other "Programmer’s helper" things that Focal Point does?

Lots! Three examples are AutoMove, Selection List, and automatic control enabling.

AutoMove

Here are some of the highlights of AutoMove:

• Taking care of all navigation for you, including the offer to create a new record if the specified key-field value does not exist.
• "Finding Next Closest" that can locate a row given the first few letters of its key value (e.g., find "FocalPoint" if you type in "FocalP"
• Warnings and offers to save if you attempt to move to another record with a dirty current buffer.
• Look-before-you-leap warnings if you try to move to a record whose ID isn’t in the Table (so you don’t lose the record you are currently sitting on because you moved to the non-existent row that you asked for).
• Keeping lookup/referential parents aligned, so that if you change the Order Line from Apples to Carrots the Inventory record is automatically re-navigated to the Carrots record, and not just the OrderLine field value.

Selection List

The Selection List is a popup Form with a grid, and fields for filtering the displayed rows. This tool greatly enhances the end user’s ability to find a specific record quickly and easily.

For example, when using a Customer database, you can specify the columns to be displayed on the popup grid -- e.g., ID, Company name, City, LastPurchaseDate, SalesRep, Telephone, anything. In addition, you have up to 4 fields to filter with -- so the user could type in "Tire" in the Company filter box if they knew the company had "Tire" in its name, and "NY" if they knew the State the company was located in. Then the column headings of this filtered grid of records can be clicked on to sort in ascending/descending order, making it as easy as possible for the user to find the row desired.

You can define these Selection List properties for each Table, in its Business Rule class. This Selection List is then automatically available any time that DataHandler is used in the normal course of data entry, or for "standalone" purposes such as report entry criteria.

Automatic control enabling

Since Focal Point is in constant contact with the Controls that bind to its Table, it knows when those controls should be enabled or disabled. So when you have an empty recordset, all controls bound to that recordset immediately get their .Enabled property set to False. If the .AllowChange property is set to False, then too are all controls for that DataHandler disabled. And those Controls are re-enabled when appropriate. This prevents users from trying to enter data in the first place into controls that are not allowed to send these changes back to their recordsets. Similarly, the Selection List popup is dynamically enabled just prior to the time that the user can legally navigate to one of those rows.

You have enough things to worry about to get your program written. The details of data management shouldn’t be one of them.

Focal Point is "electronically delivered" only