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/

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/

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/

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".