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.

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.

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
Procedure_Return iRetVal

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