Sample MetaData Extensions

• All businessrules (Entity Triggers; DynamicBlankField check) are data-driven from code in xCase. This mean no more "DO CASE" statements in your businessrules object.
• Additional Entity Triggers have been added: PostPostSave and PostPostDelete, which run after the transaction has succesfully completed.
• Entity Triggers have available to them the record object in force before the action, thus allowing comparison of values.
• List_Toolbars on forms are created automatically from an added attribute in xCase, as a default when no List_Toolbar is specified on the form.
• F2Lookup Lists coordinate with a builder that supplies the definition specified in xCase; which in turn fills in by default from the parent entity's List_toolbar definition.
• Entities have a default EditForm attribute in the VPM DD, which coordinates with an Edit Button.
• Controls respond to an Enabled Expression (controls ReadOnly status) and Visible Expression.
• The VPM oApp subclass has a method for finding opening the right view, based on DD information, for a given entity, entity parent (optional), and whether the view should be a Compound View (an xCase2VPM creation).

Sample OOP Extensions

• The object hierarchy is fully implemented, giving you full control over look, feel, and behavior throughout your application.
• A Developer Subclass is created, so you can modify the native settings of the PSP Subclass Layer.
• Forms have added behaviors (all of which are controlled by flags and are optional), some of which include:
  • Open with all records, even if a view
  • Open with Lookup List (List_Toolbar)
  • Run only once (existing copy pops up if the form is already open)
  • Post-Activate property (attach code which will run after the Activate has fired; handy for custom situations involving record pointer selection)
  • Post-Add property (attach code which will run after an ADD has occurred; handy for setting FK values when record pointer selection has been handled throughthe Post-Activate property)
• Candidate Key messaging (what fields are involved in the Key, specified by Caption) is implemented.

Additional/Modified Controls

We have found the need for subclassed controls to perform special actions. These are some of the controls included in the PSP Libraries:

• txtSmartDate: Quicken-style date control, but binds to date, datetime, and string datatypes.
• txtSmartTime: Modify just the time component of a DateTime or String datetime datasource.
• cmdDropCal: coordinates with txtSmartDate, by providing a dropdown calendar using the calendar contained in the Win32API, but with the additional feature of responding to off-calendar clicks and being able to display beyond the edge of the form.
• cmdGoMover: implements a mover for the link children in a 1:M relationship, allowing the user to select/deselect all the available possibilities at once, rather than by adding and deleting records one at-a-time.
• listbox_: modified to be able to automatically display child records of any alias, including a child on a form_toolbar_onetomany. Integrates with cmdEdit_Lookup which pops to the EditForm for the record currently selected in the Listbox_, when used in this manner.

IDE Extensions

Working with clients in developing vertical market solutions, something we do every day, gives us a real-world feel for the needs of developers. Here are some of the framework extensions we've created, to meet our own needs:

• The oAPP emulator: when you are in the VPM development environment, you are not running your application's ProApp class. Rather, you are running the oApp class contained in VPM.APP. This means that your businessrules will not fire, because the oApp nBusinessRulesType must be set to 1 (if you are using a Class-based businessrule object). It also means that any subclassing you have done to VPMAPP (which can include bug fixes) will not be running -- while you are testing your forms! Frank Camp's oAPP Emulator solves this problem for you, by dynamically substituting the oApp object of your project in those calls where it is required, while still providing the VPM.APP oApp object in those calls where the original is required.
• The PSP Builders: we have created builders that integrate with the VPM DD to assist in the development of your application:
  • The F2Lookup Builder: to set the settings required to perform F2Lookups when using views (which we use exclusively in our applications)
  • The ReDo CS builder: how many times have you changed a field's controlsource name and the found out that you missed some settings (cDDField and cDDTable) crucial to the control's operations? This builder resets cDDField and cDDTable, and resets the caption (whether on a label_, or in a grid) based on the DD, unless the VPM flags that control caption settings indicate otherwise. It also changes the name of the control (and the label when selected) to the VPM-style name, so you have consistent naming in your application.
  • The SOB Builder: substitute one object for another, optionally moving settings over from one to the other.
  • The Grid ReAliasing Builder: what a pain it is to re-alias a grid: there are settings everywhere. This builder catalogs the existing aliases, and lets you indicate the new alias each of these should use.
• Intellisense Integration: the PRGs in your application, as well as those in the PSP Libraries, are automatically integrated into Intellisense, so you won't have to remember the parameters.

Helper PRGs

The humble PRG has a place in everyday programming. For one thing, they are easy to write, test, and maintain. For another, they don't change datasession on you (as classes do), and thus can facilitate readability in code, because the extra machinations required when datasession could have switched require extraneous code.

Here are some of the PRGs in the ProSysPlus Libraries:

• VPM Data Behavior (CRUD) PRGs. VPM has method calls to handle the CRUD (Create, Read, Update, Delete) functions . We've wrapped them so they're a little more intelligent in everyday use. In the case of R (Read), we've created PRG's that handle the 3 kinds of views in VPM: PkValue, ParentPKValue, and FIND views.
• Enhanced VFP behavior functions: GetWordNum and GetWordCount, like their FoxTools.FLL predecessors, ignore empty entries. It's as though they don't exist. Bad idea in situations where you are counting empty entries as valid information. So, we've created PRGs that give you what you expect in this case.
• Everyday functions: we have over two hundred PRGs, each of which performs a function you'll use sometime. The goal is to write code that does what we want, rather than writing code that does a bunch of other things that finally do what we want.