Monday, August 11, 2008

OOPS Proper: What's an obtainable goal for centralized code in Visual DataFlex?

*Click on image to enlarge please...



OOPS proper coding goal is "no code in objects except property settings", is this obtainable?




The Visual DataFlex Studio and Database Builder utilities are the tools we use to build applications, and the coding style used in actual practice varies from "artist" to "artist" as much as a painting style does.




While the true goal of object oriented style of programming is to truly centralize code, and to produce an application where all customization departure from the basic tools we use should reside in classes, not objects. Further to this, each class has property settings for given or endowed abilities which allow us to re-use the class as instantiated in an object in different settings with different results depending on need.




Here is an example of such "art" in the fact that a module of data entry is first programmed with object code for the desired result, tested.... and then the code is moved to the classes involved for centralization and standardization. Standardization is a fundimental concept where you desire the same behavior in all modules or a programmed variance of same behavior, all set in a central place.




Visual DataFlex allows the programming and testing of object code rather than specifying that all instantiated objects be pure classes.




The "art" to this simple example as illustrated can be taken to many varying ways of implementation. One of the true advantages of VDF is the concept of multiple-inheritance.


Here's the challenge that multiple-inheritance solves:

We have a property setting "Set Auto_Clear_DEO_State to False" and a function SAVEHEADER which really belong both to the cWSdbView and cWSdbModalDialog class as well as possibly a cWSdbTabPage.


Shall we type these into the three classes three times? I think not! Remember our rule of thumb where "when you type code twice, it's time to rethink your methodology", and here's a solution using a MIXIN class. The MIXIN class is "mixed into" a class layer in addition to the regular superclass inheritance. Here's how.
click on image to enlarge please


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/



Tuesday, July 29, 2008

DOS to Windows anyone?

DOS to Windows Conversion: a facelift?

What advantages does a DOS to Windows Conversion hold, and why should I fix what isn’t broken?

The title and subtitle indicates corporate thinking as I have heard it, from many of the clients I know who have a DOS product fueling their company’s IT needs. The fact of the matter is that there is apprehension to move from a proven software platform. So why invest?

“The most important development in computer technology since the IBM PC”

What was this magazine cover article describing? Not a DOS to windows move! It was describing the onset and implementation of OOPS programming technology that I glanced at while marking time in a company’s waiting room many years ago! More important than nice windows interfaces and gui screen design! The fact is, that both DOS and Windows can be programmed with “Object Oriented Programming Style” but the odds that your DOS program has this structure is very low. Here’s my spin on the top 10 ways this affects your life:

1. Spaghetti Code VS OOPS:
The older style of dos programming has become known as “spaghetti code” when seen in contrast to oops. The basic structure, layout, and philosophy of coding software changed in a wave of approval that is now standard with every modern programming language.

2. Centralized Coding:
The new style of programming impacts your cost to adjust business rules in a huge cost savings factor. The cost savings come mostly by being able to release new versions without unwanted side effects, and also in terms of IT time to create, test, and deploy.

3. Don’t Fix it if it isn’t broke!:
This stand on computer technology was caused by spaghetti code! With “spaghetti code”/DOS standard technology, a change in business rules was feared because it generally caused an upheaval in operations. With DOS standard technology, your system is comprised of hundreds of individual standalone executables running from a menu structure where each of the programs contains duplicate code to perform similar functions along with its look and feel individually set.

4. Training:
Compare the training necessary to learn the function keys that operate DOS with a simple OOPS menu (generally regarded as a windows menu, but also available in dos) where the function you want to perform “enter payments” is listed from a dropdown menu instead of “doing 4-2-5-7 as my first job in the morning”. A standard oops interface includes a FILE/SAVE option along with standard Microsoft keys that are known to many users, and once trained in them apply to “all windows and web products” – not an exercise in teaching company defined keystrokes!

5. Standardization:
New technology standardizes the look and feel of your individual modules inside one (or just a few) programs, not only from the “windows look” but in the way that the business rules apply such as;
· Whether the company name of customers is labeled “Customer Name:” or “Client:” or “Name:”.
· Whether the company name of customers is “required”, or “capslock”, or “able to be changed by the user”.
· Whether the “Apply Finance Charges” option accepts only a Y/N value and whether the value for a new customer is defaulted to “Y” or not… and how!
· Whether one can delete a payment or not!
· Whether these kind of options must be re-coded for every module or not!

6. Combining Similar Functionality:
One of the most visible changes of a conversion to oops takes similar DOS executables such as “Enter Sales Order”, “Change Sales Order”, “Delete Sales Order”, etc. and moves them into one program. The ability to do this is the power of oops centralized coding and new windows technology which just simply outperforms DOS technology and spaghetti code.

7. Transaction Control:
One of the most basic data related improvements introduced into database technology since most DOS programs were written is transaction control, where “half baked” transactions that partially succeed, leaving a cleanup job for IT are totally eliminated.

8. Speed:
It is true that DOS speed is unmatched by windows technology. It’s not true that this is a significant advantage considering that the reason for dos speed is partially that the transactions do not flow thru centralized business rules to perform their database actions, but simply “write to disk” directly!

9. Maintenance:
Once your system is retrofitted to use oops programming style and structure, changing a business rule such as the way a sales order is calculated is a matter of changing the business layer rule in one spot, instead of updating “sales order entry”, “change sales orders”, “print unshipped orders”, and “update order as delivered”. The tongue in cheek saying for this amazing new technology is; “One changes the business rule in just one spot, and the resulting code is either perfect system wide, or wrong system wide!”.

10. Investing in Technology:
The time to invest in a DOS to windows conversion is overdue. If you’ve waited for the “wrinkles to smooth”, the “bugs to be fixed”, or determined in the past that the “investment” wasn’t worth the result, then I believe you are on the brink of extinction, because the software engineers that understand BOTH the dos and windows technology (and hence the ability to render a modern version from the old true code) are on the verge of retirement! If you wait, it’s a total rewrite to face.

Summary:
These are my top ten reasons to consider a DOS to Windows conversion, and if you started with a goal to port some of your functionality to the web, please consider the windows conversion a half-step there, because most platforms/languages have an extension of the business rule layer that is applicable to the web, or usable by a webapp so that part of your cost is a move closer to internet presence, whether it be customer data sharing, order entry, part availability, or simply customer and prospect information gathering.

About the Author:
By: Peter A Donovan
Applause Software of Boston, USA http://www.applausesoftware.com/
Member in good standing of the NEDC Programming Group: http://www.nedataflex.com/

Peter started his IT career as a combined sales executive/custom application developer the year following the release of the IBM PC. After similar corporate positions, where he was responsible for both Sales and Programming responsibilities, he obtained a position with a software distributor/authorized factory technical service center, where he excelled in custom application development for many different industrial and commercial markets and also travelled throughout the USA, Canada, Europe, and Africa training IT staffs in correct implementation of OOPS foundation coding technology and data dictionary technology.
Currently an independent IT consultant specializing in database software, Peter is actively involved in bidding on new challenges, maintaining a customer base, and publishing a freeware database contact manager “rolodex style” called RoloFLEX as a showpiece for his business.
www.RoloFlex.Biz

Thursday, July 24, 2008

Visual DataFlex Class~ Instruction via Internet

Internet Or In-Person Instruction In Visual DataFlex:
*Highly Competitive with Data Access Rates!

"The wide open possiblities of coding techniques can be explained in conceptual terms so that you code to form a solid foundation for your application based on correct OOPS programming concepts."

Internet Instruction Benefits:
"a 10-20 hour course @ $80 per hour using your application will cover all of the topics of a classroom environment without the travel, hotel, and inconvenience and produce usable and functional code for you to implement at your company and use as a reference".

"GoToMyPC, PCAnywhere, VNC, or other communication software puts us on the same desktop together, while we discuss the challenges you are facing and decide upon the most useful tools available to use, and the best OOPS techniques to use to accomplish your goal."

Global Internet Instruction:
Applause Software can offer voiceover communication while we codevelop your application thru instruction: please see: http://www.skype.com/ which allows free communication from Applause to you with the use of a headset with microphone.

Kindly reach Peter A Donovan at http://www.applausesoftware.com/ for further details!

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/

Thursday, May 15, 2008

Uniform Rental Service Employee Paid No Contract

What you need to know about Employee Paid and Negotiated Uniform Rental Programs.

The author Peter A Donovan is not affiliated with any unform rental company now, and was previously employed in the industry for 12 years negotiating rental contracts and speaks from this experience.

For the sake of mathematics, let's assume the ABC Manufacturing Company has 10 employees who pay and contract for uniform rental service, and that ABC will not payroll deduct or manage uniform service for unnamed reasons which could include overhead of management time.

What impact does this have on quality of uniforms, price, and the selection of a uniform rental firm?

To understand, you need to be "in the head" of a uniform rental company.
In a normal situation, where ABC negotiates and signs a contract, here's what happens. The uniform rental plant bidding for the business does this:
Each employee gets an inventory of 11 uniforms: 5 in the locker for M-F, 5 dirty in the plant being cleaned from last week, and 1 on the back of the employee, a "swing" garment.
Uniforms cost money. Let's just say each uniform outfit costs $75, and with 11 to purchase, that comes to $825 - not a trivial amount. They "lay it on the line" with a 3 or 5 year contract at $14.00 per week coming in per employee and give new garments to begin service. Math please! That comes to an income of 14x52 weeks = $728 per year. There is cleaning, employees to pay, trucks to maintain, and gas prices too. The normal new uniform contract takes about 1/2 the contract amount to break even. Let's not even go to "value of money over time". The uniform rental plant is in the business of long term profit and when you renew your contract for another 3 years, there's no huge overhead so there is finally some profit at the end of the tunnel.

Now, when ABC refuses to sign a contract (employees cannot) what does this do?
You have to be the uniform company on this one.
First, let's talk about the "stock room" of uniform rental plants. Every plant has a stock room full of used garments that they decide are good enough to rent but used, so they use them a replacement garments when regular uniforms are destroyed and for employees added to a contract during the contract period. When you have a sizeable stock room bulging with used uniforms, you can go after employee paid no contract accounts. $14 per week per employee still and used uniforms. Wait.

Who has uniform stock rooms bulging? When a uniform company has customers that end contracts, all the uniforms are returned to them. When a uniform company has a low quality control standard for used garments and retains all rather than RAN "replace as needed" you get the perfect mix.

If your customers are happy and don't leave, PLUS you have a high quality RAN system, you just can't bid for the ABC account, can you?

So, the impact of ABC's non-involvement does this:
1. The uniform vendor will be of the type mentioned above most likely.
2. The employees get used and pay for new.
3. AND they impact the image of the ABC company when visitors arrive.

This article is written expressly for reading by the owner of ABC, whomever you may be.

Sincerely,
Peter A Donovan
Applause Software
http://www.applausesoftware.com/

Monday, May 05, 2008

Uniform & Linen Rental Plant Software Launched






A new software product for commercial textile rental plants (uniform & linen rental) will be launched this week from Applause Software of Boston.

Created in 20066, coming to market now, is RoloFlex UL.

A Sales and Marketing contact manager featuring custom proposal generator, email blaster, document management and scanning, market share analysis, targeted lead generation, and salesrep activity monitor, RoloFlex UL will be launched this week with a nationwide telemarketing campaign.

Based on a Visual DataFlex front-end, this product is years in the making and is singly the only PRO application available for the industry specifically.

There are approximately 400 commercial textile plants in the USA specializing in uniform rental and linen rental. The organization that forms the association for these companies is the Uniform Textile Service Association (UTSA) which features a publication and trade shows for the industry.

RoloFlex UL is currently featured on: http://www.roloflex.net/

Author: Applause Software of Boston: Peter A Donovan http://www.applausesoftware.com/

Sunday, April 13, 2008

Microsoft TAPI DIALER with Vista


With the advent of many new things in the Vista OS, there is an important undocumented method for using an application which utilizes the TAPI (Telephone) interface to Vista.


In a microsoft support conversation I had with the MS support team, I suggested the following:



  • Bug: The MS-Dialer in Vista is not backwards compatible with XP.

  • Bug: There is no documentation in Vista on how to use TAPI or the MS Dialer.Exe

  • Bug: The documentation that MS provided does not dial USA phone numbers correctly.

Here's the problem:


If you were to dial in XP, you would dial this: 1 781 555 5555 as an example. This no longer works in Vista, and the output dialed is exactly this: 1 7 555 5555 where 2 digits of the area code is truncated.


If you were to follow the (paid to provide) documentation, you would now dial: +1 781 555 5555 but this results in the following number dialed: 781 555 5555 without the long distance "1".


The Answer:


Short and sweet: You must take the digits previously dialed by XP and add the country code for the USA like this: "+1 17815555555" with an important space after the "+1 ", resulting in the number dialed of 1 781 555 5555


This will be an important new addition to programs (such as RoloFlex from http://www.roloflex.biz/) which perform under both operating systems, XP and Vista, so the programmer must identify the OS and adjust the TAPI interface accordingly.


In the hopes of helping someone else with their TAPI interface, so that you don't have to pay Microsoft $59 US to help you discover this....


Regards,


Peter A Donovan : Applause Software, Boston USA http://www.applausesoftware.com/



Saturday, March 15, 2008

EMail Marketing with Visual DataFlex Software

An amazing return on investment can be obtained from email marketing to your customer and/or prospect base...

... considering [as example] the “under $1,000” customized package available from Auto-Mate Software from longtime VB and VDF developer Garret Mott of the NEDC.

Once installed, you can instantly notify your entire market that new products are available, or write pre-written excellently worded letters that are sent to individuals when the need arises.

Layman’s terminology only:
1. Write an email. Edit carefully, proof, and save into a database using a windows program that guides you.
2. Select whom out of your database you’d like to send it to.
3. Click a button, and each of your prospects receives an individual email within minutes.

  • How to slice and dice your market:
  • Let’s assume you have a database with customers and prospects. If you don’t, it’s time to take this on. Your database contains vital information about each entry such as the zip code, state, type of account, balance, payment terms, etc.
  • What if you could instantly generate revenue for no cost? Let’s setup your email screen as Garret Mott would do for you. Select from a drop-down list “COD”, select “MA” (Massachusetts) and pick customers only. Write up an email offering 10% discount on orders in the next 48 hours, and send. When you feature a new product or listing on your website, why not let everyone know in a short email note?
  • The other use for this kind of tool is to respond to inquiries with pre-written letters, edited for presentation quality, available to send to individuals upon request of information. Each business model has a set number of popular inquiry topics that customers ask for. Currently, do you respond with ad-hoc written emails and mailing of literature? A pre-written letter send to the individual who requested the information actually takes less time and both makes a better presentation and offers a delivery vehicle to attach a .PDF document. No cost, improved results, and instant delivery.

These are the two most common uses for email marketing, but I’m sure you can think of more.

Delivery:
Are we all tired of the HTML emails that feature graphical art advertisements? The systems that I currently use feature plain text with links. They look like an individually typed email, and they are really. Many email recipients have “html off” as an option on their emails, so why send an email that only a portion of your readers will actually see?

Difficulties:
Many ISP’s (Internet Service Providers) have limits on how many emails you can send in an hour. We have found that options on your email sending package can spread these emails over the course of a day or two, or that simple negotiation with your ISP can unlock this limit. Many times a requirement that you include an “unsubscribe” link could be encountered, and is a good practice to include.
Summary:
Generate income, keep in touch with your market, break news instantly, and respond more professionally to both sales and service opportunities.

Recognizements:
Auto-Mate Software: http://www.automatesoftware.com/

Author:

Peter A Donovan, Applause Software: http://www.applausesoftware.com/

Friday, February 22, 2008

INCORRECT: Reports Of Visual DataFlex Corruption with Vista Home Edition: Read More!

Recently, Many blogs are picking up a report from a single source which is reporting that various software packages running under Vista Home editions experience corruption: NOT PROVEN.

This was my response to the earliest and most reputable blog I found with the post:
I am posting it here in case they decide to block my reply:

I am the owner/lead programmer of Applause Software in Boston, a Visual DataFlex business solutions firm, and I have a google watch on Visual DataFlex…

I would like to ask for details on your listing of Visual DataFlex in this list.It is unlikely that a Visual DataFlex application would cause data corruption in this environment, but it is very likely, that because programs written prior to the UAC of Vista came to being, that a VDF program trying to access a registry value could produce error messages that would be mistaken for corruption.

In addition, users of Visual DataFlex are not aware of the exact backend database used for their application since it could be one of many including Oracle, DataFlex embedded database, Pervasive, MS-SQL, or other backend.

I would like to offer my services to get to the heart of this matter and as a professional developer in the language for 25+ years I would like to challenge this information at the source and ask for a consultation with the firm reporting this information please.

Until then, please to anyone watching this thread with VDF kindly consult your system IT professional for more informative information prior to canning your application!

PS: Always make a backup! Don’t wait for a reason!

Thanks,Peter A Donovan
Applause Software of Boston
[ a google will find me ]

Monday, February 18, 2008

Definition: Data Dictionary

A data dictionary is defined as the business layer in-bewteen your table on disk, and the requested operation at runtime.

It handles the find, clear, save, validate, and delete requests from either the programmer or the user. A data dictionary exists both as a class coded definition and as an instantiated object which uses full delegation and polymorphism in the form of a data dictionary object in a "tree" structure for the data set you wish to perform an operation on.

Editing a DataDictionary CLASS in Visual DataFlex involves at least 10 identifiable options:

-1. Create/edit/delete data table columns.
-2. Set parent relationships.
-3. Define indexes for finding data by.
-4. Set column based options for when the data table is used as the main data entry source. This involves setting system-wide standard behavior such as "capslock", "required", and "auto-find". An option also exists to set columns as "key fields" where the user may not change the value at runtime.
-5. Set column based options for when the data table is used as a "server" [parent] of the main data entry source. Options here include "find required" and "noput" [user changes cannot overwrite the data table column]. It should be noted that depending on which place in the data operation structure (parent, child or main file... a data dictionary exists, the place determines which business rules apply in a display of polymorphism which is defined as the ability to produce different behavior simply by the context of it's use.
-6. Define the immediate relational tree for the delete operation based on a record delete in the table. The child tables are defined so that two basic rules apply (one or the other): either the record cannot be deleted if child records exist, or the child files will all be deleted when the record is called for delete AND a data dictionary object in the module must be present to handle the delete operation. This is as much a validation for the programmer as it is for the user, since operations cannot be successful unless both follow the rules programmed in the class. It should be noted that business rule exceptions and customized rules can augment this programming or replace it completely. It should also be noted that when data dictionary objects are connected together in a module, that deletes travel downwards in the tree, and upon each delete, a save and validation is sent upwards in the tree.
-7. Define the immediate relationsl tree for the save operations based on a requested save of the data table record. The parent data tables are defined so that your programming team must always place a parent DDO (data dictionary object - instantiated on the classes we are building) for each parent data table that is connected relationally. Omissions and "sometimes required" parent tables can be defined in both the class code and object code programmaticallty. The advantage of making a parent table "required" is to be able to both code update/backout operations to another table (knowing that it must always be present to handle your code), and also for the Visual DataFlex Studio to automatically model your relational tree when you request a data server to handle your find, clear, save, validation, and delete operations.
-8. Define the externally updated tables to be bound in the transaction block of saves/deletes. When a save or delete occurs, all table attributes are set to readonly momentarily, the tables that will be affected by the operation are set to default mode, and then a reread/transaction block occurs to lock all the tables in the tree that are affected PLUS the ones listed in externally updated tables. This allows, for instance, a reread and update from the system table to assign the next available number to a key field.
-9. Programming of stored procedures that exist as called methods already. REF: DDO Save Cascade: http://applausesoftware.blogspot.com/2008/02/visual-dataflex-ddo-stored-procedure.html
10. Programming of customized stored procedure methods that you introduce to the class, stored in a central depository (the foundation of oops programming) class and can be attached to either the exiting of a control attached to a column of the data table, or the exiting, or simply the validation of such column.

All together, these 10 functional abilities to centrally define data table rules are dwarfed by the fact that they are "hitched up in tandem" like a team of "Budweiser Clydesdales" which work interconnectedly to enforce your entire data structure on any data operation which includes save, clear, find, delete, and validation.

Find this definition and more at: http://www.vdfwiki.com/

By: Peter Donovan, Applause Software, http://www.applausesoftware.com/

Tuesday, February 05, 2008

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/

Wednesday, January 16, 2008

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

Tuesday, January 15, 2008

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)