Visual DataFlex - Organization Foundation

Visual DataFlex:

an outline:

• - Workspace


• - Project


• - Layers

Workspace:

A Workspace is defined as an organization of resources supporting an application in subfolders defined by the workspace. Standard Layout of a Workspace (with no modification) is;

• - AppHtml - .asp code and supporting images plus cascading style sheets, etc.


• - AppSrc - windows source code


• - Bitmaps - images


• - Data


• - DDSrc - data dictionary class layers and table definitions


• - Help (blank)


• - IDESrc - vdf class information


• - Programs - executables and workspace definition file plus debugging tracer code

So, with the advent of Vista, and the desire not to place our live app within the PROGRAMS folder, an actual deploy model would look like:

C:\Visual DataFlex Projects\MyWorkspaceName .... with subfolders.

PROJECT: A project is defined as a workspace application (there may be more than one project inside a workspace) executable.

A Project is usually a MDI (multiple dialog interface) application with the following layer structure:

DESKTOP:=================================

• - The Desktop is the name for anything outside the inner containers


• - The Desktop contains an application object which defines the paths and behaviors associated with the application.


• - The Desktop contains: the MAIN panel, the CodeJock skinning, and possbily a Login Panel?

MAIN: ====================================

• The Main is a SDI panel which functions as a main container object for the application.


• The Main contains the MENU


• The Main contains the CLIENT_AREA : the container for interactive modules/objects.

APPCLIENT_AREA:==============================

The APPclient_area is the working ground of all major components of your system.

It contains:

• Data Entry Forms


• Reports


• Selection Lookup Lists


• Modal Dialogs


• Business Process Objects


• Resources such as methods and classes

All Together, the workspace, as described, is designed to let delegation, encapsulation, and polymorphism happen within the context that the modules and sub_objects are arranged.

All Together, it looks like the picture above: click on image for larger view!

Regards,

Peter A Donovan, Applause Software

http://www.applausesoftware.com/

Container Technology in Visual DataFlex

Recently, I worked with a co-developer who coded a similar procedure such as this:

Procedure Item_Change integer iFromItem integer iToItem returns integer

Integer iRetVal
Forward Get Msg_Item_Change iFromItem iToItem to iRetVal

If (Current_Col(Self) = 2) Begin
Send Request_Save of oProdLine_DD
End
Procedure_Return iRetVal
End_Procedure

What came of the conversation we had was that the "Send Request_Save" actually (and unintentionally) avoided the container technology of Visual DataFlex so that validation, the confirm message, and the ability to augment these functions in the container were completely misdirected!

Here's what happens when a Request_Save is sent by normal means (i.e. clicking the save button, using the save key, changing a row in a dbgrid, etc):

• The container runs request_validate of the server ddo and validates the datadictionary class rules upon the data. Upon failing, the save is aborted, a message about the error is sent to the user, and the focus attempts to go directly to the window or cell that doesn't pass validation. Upon success, the next step occurs.
• The container then runs the function named in the verify_save_msg property handle. "Would you like to save?", or a custom message if you have programmed it. Upon a NO answer, the save is aborted and the focus returns to the object or cell in the focus tree. Upon a YES answer, the save cascade of messages continues.
• The container then asks the DDO (server) to save. Upon any error, all changes are rolled back and the focus returns to the object/cell in the focus tree.
• Then, the container (if it's not a data aware grid or list) clears the buffer and the ddo record attached to it.
• Then, the container (if it's not a data aware grid or list) sends the message "beginning_of_panel" (augmentable) which determines the first focusable object on the form/view and gives the focus to it.
• DONE

So, as many are aware, when you take control of the save mechanism to do it manually, you should do the following steps:

1. Request the ddo validation to a boolean: Get Request_Validate of oProdLine_DD to bCancel.
2. Ask or confirm the save: Get Confirm "Would you like to save?" to bCancel
3. Send the save command: Send Request_Save of oProdLine_DD
4. Upon success, clear the record: If (Not(Err)) Send Clear of oProdLine_DD
5. Move the focus: Send Beginning_Of_Panel

So, in summary, the container technology has 5 main steps to it (actually six!). Prior to any of the five actions, it asks the server DDO if there are any changes to save! If there are no changes to save, then none of the above five steps ever execute.

Many are familiar with the Save cascade of messages from creating, backout, update, etc. but the container cascade of messages/methods is also important to realize prior to the save cascade ever occuring.

Posted by:

Peter A Donovan

http://www.applausesoftware.com/

Visual DataFlex DDO Stored Procedure Delegation

As advertised: for Visual DataFlex programmers.

This is a snippet showing the Visual DataFlex cascade of messages that is called in each one of the data dictionary objects in a connected tree of data table dictionary objects in a form/view.

Creating: [a method to put code for new records only]
Backout: [a method to put code where the record on disk is in memory before ui]
Update: [a method to put code for all saves both new and existing]
Validate_Save: [a method to put complex validation or validation to be done after update]
Save_Main_File: [a method where the parent values drop down into the child and the record is saved to disk]


[ double click image to expand]

Regards,
Peter A Donovan
http://www.applausesoftware.com/

Oops foundation centralized coding in Visual DataFlex

OOPS Foundation Centralized Coding in Visual DataFlex:

One of the most fundamental concepts in oops programming [object oriented] is centralized coding so that unlike previous spaghetti code where the same calculation was formulated over and over again in different code segments, instead we now place the code in one spot so that if business rules change then we go to one spot, change the code, and we're done.

Earlier attempts at centralized coding involved gosubs where the same piece of code was reused, but with Visual DataFlex, utilizing datadictionaries, we have hooks in the finding process and constrain process for instance where the code is placed in a "stored procedure" along with all the other rules of the datadictionary class for a table. In Visual DataFlex methodology, which supports full message delegation, the find passes through a DDO [data dictionary object] which delegates the find to it's DD class code and utilizes the onconstrain method of the class as well as the object.

Technique: in order to fully utilize delegation, we "forward send" each message even if it is an "event" method.

The code described below takes a business rule exception to constrain a table by it's status which is used throughout a system in many places including windows data entry, batch processing, and webapp interfaces.

The beauty of Visual DataFlex database centric code is that this one event can be turned on or off by a property setting [business rule exception] in any of the above mentioned applications.

Here's some sample code:

This is intended as a "get-to-know features of Visual DataFlex" article.

Sincerely,

Peter Donovan

The NorthEast DataFlex Consortium

The NEDC: what it is!

The NEDC was formed in April of 2003 by a group of New England based Visual DataFlex custom application developers with varied specialties. It offers "the power of a large corporation without the large cost" for potential software partners/clients and is noteworthy as being the largest single resource for Visual DataFlex programming in the United States.

Why Choose the NEDC?
The NEDC is a group of independent Visual DataFlex (VDF) programmers that have joined in camaraderie to provide increased value and capabilities to their customers. The NEDC is not a conventional consulting firm, or even a legal entity, but “an almost virtual company”.
We think this concept works to make the NEDC an exceptional partner for your business, as we can offer the power of a large corporation without the cost.

· Experience: Collectively, the NEDC provides over 150 years of VDF (and other language) system development experience. Whether your needs are for an inventory, sales, manufacturing, time & attendance, ERP, or some other kind of system, we most likely have real life experience implementing similar systems.

· Skills: When working on a project, the person best suited to a particular portion is the one doing the work. NEDC members have worked in many environments: independent, small business, corporate and as a VDF instructor. This gives us real life understanding of how companies work. We all started in character mode (DOS based) DataFlex, so we know the language from the ground up. Most of us are also involved in testing of the newest version, so we know what’s coming.

· Project Types: We work in many different ways: conversions of character mode DataFlex systems to VDF, conversions of systems written in another language, maintenance of existing VDF systems, and whole new systems. Whether you need a classic Windows system, a Web-based system or a combination of the two, we can do it.

· Costs: Being a “virtual company” saves our clients money: no rent, tax burden or administrative costs to pass on. This means that we can work for a substantially lower hourly rate while providing excellent service. Of course it also means we can’t invite you to visit our expensive corporate headquarters! Instead, we come to you, which helps us get a better picture of how your company works.

· FLEXibility: The NEDC normally assigns one developer as project leader. If he goes on vacation or gets sick, another fills in. If you prefer to work with another developer as lead, simply ask and we’ll swap roles. This means that you are in the driver’s seat, not at the mercy of someone you’ve never met deciding that another project is “more important” than yours or that you will have to work with a particular person.

· Security: If you are used to working with a single developer you may worry about something happening to that person. In the NEDC, if something were to happen, another developer will switch into the role.

by:
Peter A Donovan
Charter Member of the NEDC (NorthEast DataFlex Consortium)

RoloFlex Release: Press Release and Marketing

RoloFlex 12.5 Released November 2007
Featuring Visual DataFlex

Rated highly by submission to download sites listed herein, the RoloFlex CRM/PIM [customer relations management/personal information manager] is going out to major download sites and features the upgraded RoloFlex product released with the Visual DataFlex 12.1 platform.

The marketing effort for RoloFlex is just beginning!

Soon, RoloFlex will be available at most major download sites featuring anonymous download under the Visual DataFlex 12.1 evaluation period and subsequent registration/licensing when registered through http://www.roloflex.biz/

Under Construction: RoloFlex Time Tracker 12.5 for billing hours and invoicing.

Nearing Release Now: RoloFlex EMail Module, due for distribution on November 15 2007

Please Note the RoloFlex Blog Site http://www.roloflex.blogspot.com/ for future news!

Sincerely, Peter and Kimberly Donovan

DDO Tree Technology – DAF Methodology

Terms:
DDO Tree: A combination of instantiated data dictionary objects tied together.
DAF Methodology: How the ddo tree handles find, clear, save, delete and validation.

Here’s a sample (simple) ddo tree as found in a sales order data entry program or other module…

“Knowing how the ddo tree handles user requests is at least important to know as how to model a data dictionary class”

Communication between the ddo tree and the objects in play is a two way street!

In this example of data entry, the Server of the main panel is Salehead and it controls the find/clear/save/delete and validation of itself and all it’s parent ddo objects.

In a lesson in polymorphism, the “Customer” ddo recognizes it is a parent object of the server in play, and enforces different rules (find required on record for instance) than it normally would if it was the server itself.

Further, the SaleHead ddo takes responsibility for accepting the find/clear/save/delete messages sent via the user. When the cursor/focus is in the customer name window, for instance, the request_find message actually goes directly to the SaleHead ddo, not the Customer ddo. The SaleHead realizes that the message is directed at a parent ddo and forwards the message up thru the connection to the Customer ddo to handle.

Test!
Take your data entry module with parents and put a hook message inside the server and the parent “request_find” method and see which pops up first!

In the same way that this communicates upwards, it also communicates downwards so that when a delete message comes to the server, it travels downwards, deleting all children of the server and then itself. The beauty of the methodology is that no parent records can be deleted by the user unless programmatically allowed by the software engineer.

Test!
Take any data entry module, place the focus in a parent object cell or window, and press delete. What get’s deleted? Not the parent!

So, augmentation of ALL find/clear/save/delete requests can be done at the server level! Here’s how to code so the customer of an order cannot be changed:

Object Customer_DD is a Customer_DataDictionary
End_Object

Object SaleHead_DD is a SaleHead_DataDictionary
Set ddo_server to Customer_DD

Procedure Request_Find Integer iMode Integer iFile Integer iIndex
If ((iFile = Customer.File_Number) and (Current_Record(Self))) Procedure_Return
Forward Send Request_Find iMode iFile iIndex
End_Procedure

Procedure FindByRowID Integer iFile RowID riRowID
If ((iFile = Customer.File_Number) and (Current_Record(Self))) Procedure_Return
Forward Send FindByRowID iFile riRowID
End_Procedure

End_Object

Test!
This is one correct way to code a sales order so the parent cannot be changed of an existing sales order!


So, what have we learned? DAF Methodology.
It’s a study of communication between data entry objects which delegate user messages to the server, and how that server communicates the messages to it’s parent and child tables.

Visual DataFlex DDO Tree Technology Reference

A Reference Guide of DDO Technology
– Visual DataFlex–

Outline Mode:
- Introduction
- Terms
- What is a DDO?
- What is a DD Class?
- What is a DDO Tree?

Introduction:
Based on DAF Methodology, the DDO Technology in Visual DataFlex is a study of instantiation, delegation, and polymorphism.

Terms:
Instantiation: The act of creating an object based on a class and class hierarchy.
Delegation: Visual DataFlex features natural full delegation of methods by default, where the method travels first to the object, then to it’s superclass, and on throughout the full class hierarchy until the method is resolved. A method runs to completion without augmentation or definition on the object level but such augmentation, forwarding, or canceling is supported on both the class and object level.
Polymorphism: The act of an object to produce different behavior depending on it’s context.

What is a DDO?
“data dictionary objects” are instantiated in each data entry (or other type) module for the purpose of:
- Providing a “server” for find/clear/save/delete and validation operations for a data table.
- Providing data aware controls with attributes such as capslock, valid values, default values, range definition, selection list definition, etc.
- Communicating with other DDO’s in tandem to do all of the above with coordination.
- Definition of “constraint data filters” where your data can be a subset of the whole.

Sample Object Code:
// doc: instantiation of customer_datadictionary class placed inside panel of data entry form.

Object oCustomer_DD is a Customer_DataDictionary // instantiation of class.
Set DDO_Server to oSalesRep_DD // parent or “server” ddo
Set DDO_Server to oTerms_DD // parent or “server” ddo
Procedure OnConstrain // predefined method
Forward Send OnConstrain // continue delegation
Constrain Customer.Active EQ “Y”
Constrain Customer As (Customer.TotalOwed What is a DD Class?
A data dictionary class is a number of things: about 10 major functions with more omitted for space constraints in this article.

[1] A Data Dictionary Class defines the attributes for the data table to be communicated to the data aware controls tied into that database table. Attributes include “capslock”, “required entry in this column”, “auto-find upon exit”, “shadowed/non-enterable”, etc.

[2] The DD Class sets the (above noted) attributes differently depending on whether the ddo (instantiated object based on the class) is the direct server of operations, or a parent ddo of the operations server. This creates polymorphism on the object level and allows parent records to be found, required to be found, but not allow changes, for instance.

[3] The DD Class defines which other database table objects must be instantiated alongside with it to perform save and delete operations. For instance, the save of a sales order lineitem would require a dd object (ddo) for the product it was related to in order to reduce inventory or create a backorder. In another instance, the sales order header would require a ddo for the sales order lineitem to be present in order to delete the related order lineitems. Also, a DD Class may be configured to not allow deletes if child records exist.

[4] The DD Class allows columns to be associated with a “selection list” or lookup object. The chosen selection list will create a lookup button on the control chosen for that column and automatically popup and communicate two ways with the selection list.

[5] The DD Class allows the database programmer to define the object labels for each column and also to default the creation of controls for this column to a certain type such as a spinform or comboform, etc. (communication with the visual dataflex studio).

[6] The DD Class features augmentable save, find, clear, delete, and validate methods. The operations server (ddo) in a form or “view” will initiate a cascade of messages designed to perform an operation such as a save operation. When this save occurs, it cascades to all the connected data dictionary objects in the form or “view” which then delegates to the DD Class where you can augment the operation based on business rules you define and business rule exceptions which can be controlled via various means, usually with a property setting.

[7] The DD Class allows the setting of “valid values” validation tables which accompany a column in whatever control form it takes (regular form, comboform, or in a grid). The DD Class can define a list such as “activeinactive” for itself, or share a validation table with other DD Classes such as a list of US states or valid shipping terms.

[8] The DD Class allows for the definition of entry and exit methods for each column of the database table. Whether the column, in data entry, is represented in a comboform, or in a grid, the entry and exit methods follow it.

[9] The DD Class allows for auto-incrementing from a “system file” for ID fields, for instance or lineitem numbers.

[10] The DD Class communicates when instantiated, to validate the find/clear/save/delete cascade of messages along with whatever other ddo objects it is connected to.

What is a DDO Tree?
Data Dictionary Objects are run in tandem to find/clear/save/delete and validate these operations.
Let’s take a sales order entry application for example. The business rules given to you are;
· Customers who are not active may not purchase.
· Active customers may not go over their credit limit by more than 10%.
· Sales orders update the customer total owed.
· Lineitems update both the sales order total and reduce product from inventory.
· Product records update vendor purchase history.
· Sales orders update the salesrep volume sold.

Here’s a sales order entry application ddo tree (simplistic) example:
// doc: ddo tree for SO application
Object oTerms_DD is a Terms_DataDictionary
End_Object

Object oSalesRep_DD
End_Object

Object oCustomer_DD is a Customer_DataDictionary
Set DDO_Server to oSalesRep_DD
Set DDO_Server to oTerms_DD
Procedure OnConstrain
Forward Send OnConstrain
Constrain Customer.Active EQ “Y”
End_Procedure
Function Validate_Save Returns Integer
Integer iReturnVal
Forward Get Validate_Save to iReturnVal
If (Customer.Owed > (Customer.CreditLimit * 1.10)) Error 999 “Customer Over Credit Limit”
Function_Return iReturnVal
End_Function
End_Object

Object oVendor_DD is a Vendor_DataDictionary
End_Object

Object oProduct_DD is a Product_DataDictionary
Set DDO_Server to oVendor_DD
Procedure Update
Forward Send Update
Add (Product.Qty * Product.Price) to Vendor.Volume
End_Procedure
Procedure Backout
Forward Send Backout
Subtract (Product.Qty * Product.Price) from Vendor.Volume
End_Procedure
End_Object

Object oSaleHead is a SaleHead_DataDictionary
Set DDO_Server to oCustomerDD
Procedure Update
Forward Send Update
Add SaleHead.Total to Customer.Owed
Add SaleHead.Total to SalesRep.Volume
End_Procedure
Procedure Backout
Forward Send Backout
Subtract SaleHead.Total from Customer.Owed
Subtract SaleHead.Total from SalesRep.Volume
End_Procedure
End_Object

Object oLineItem_DD is a LineItem_DataDictionary
Set DDO_Server to oSaleHead_DD
Set DDO_Server to oProduct_DD
Procedure Update
Forward Send Update
Add LineItem.Total to SaleHead.Total
Subtract LineItem.Qty from Product.QtyOnHand
End_Procedure
Procedure Backout
Forward Send Backout
Subtract LineItem.Total from SaleHead.Total
Add LineItem.Qty to Product.QtyOnHand
End_Procedure
End_Object
// END CODE

With a pictorial version of what’s happening in the tree:

RoloFlex Companion #1

The first RoloFlex Companion Product *for Professional Version Only will be Launched on November 15th.

Contributed by longstanding custom app developer Garret Mott of Auto-Mate Software.

Note: Garret has done a number of custom email managers, adding in features such as disclaimer, logo as an image, signature with custom field placement capability, attachments, well... it has a lot of features. Any developer looking for a custom email attachment to their product please contact http://www.automatesoftware.com/.

Note: This is intended as a launch of companion products, both for RoloFlex, and a platform for getting your Visual DataFlex product out in a new market. Please contact http://www.applausesoftware.com/ for more details and a prototype agreement.

Thanks! Good luck to the pooch - "Rolo".

The Agile Manifesto

Quick Note:

This morning, I read one of the greatest blog articles by Joe Coley of the NEDC. In a newly opened blog, Joe's article just posted features the AGILE MANIFESTO which is an incredibly poignant statement about software development philosophy.

I recommend checking in on Joe's blog as a "must read"- http://itknowledgeexchange.techtarget.com/customapps/

Joe's photo and background can also be found at:
http://www.nedataflex.com/NEDCtest1.asp?pageid=22

PS: You can become a signatory of this manifesto if you agree with it's content.

Publising an article about Visual DataFlex

Publicity for Visual DataFlex:

I am writing this article specifically geared for Visual DataFlex developers who would like to write an article publicizing your views or information about visual dataflex...

I personally have tried to publicize VDF thru article writing, and posting to different sources, and would recommend the following strategy to anyone who would like to do the same:

In looking for publicity for Visual DataFlex and other associated products, I use this resource to locate a suitable article site:

http://www.manhattanservice.com/

Manhattan Service is a SEO optimization help site, but specifically a inner link especially for articles:

http://www.manhattanservice.com/network/article-directories/

which lists [at the bottom] a number of article sites which accept free articles.

Now, from experience, I recommend 2 sites from this list:

EZine

and

Buzzle

The compelling reasons I recommend these two sites are:

[1] Will my article be formatted nicely and not cluttered with advertisements on key words within my article?
[2] Will the page rank [power to make the article stand out on google] be high enough to effectively publicize my work?
[3] Are the site underwriting standards tough enough to eliminate spam articles so that my article will not be cluttered by junk articles, AND will it stand a chance of being distributed to other article sites?
[4] Will they review and approve my article in a reasonable time frame?

Sites to avoid:
ISnare - this site effectively only publicizes when you pay and your articles will just hang in limbo until you do.

Secondary Site:
Article Factory - this site has low underwiting standards and your post will disappear in time if not popular, however they feed other channels and my article on Visual DataFlex product review got over 600 views, 21 other sites picked up the article, and it is still up and running.

Note: If you have a blog, and feature articles about Visual DataFlex in the blog, I recommend you visit www.BlogUpper.Com [a child site of Manhattan Service] for assistance there.

If you have a topic to write about, and would like to further the cause of Visual DataFlex, please consider publishing an article or more thru these channels!

Sincerely,

Peter A Donovan