Seeking Employment as Visual Foxpro programmer/analyst based on following Experience:
1992-Current
Mida and WEFarm: FoxPro v7.0-Accounts Payable Applications. Recently developed apps available as code samples of my work.
Q-sys: FoxPro v7.0—Supported Navy Reclamation app with expert use of Custom Classes, Inheritance and other OOPs features. Designed stand alone modules using grid lookups that change color for typing errors.
First Air Express: FoxPro v6.0—Worked AR modules for transportation company that moved Dell computers. Integrated EDI ftp transfers into existing SBT database including 820, 211 and 997s. Extensive enhancements.
CompuHelp: FoxPro v6.0—Maintenance and Enhancements of Meal Service Software targeted for Cafeterias in School, Hospital, Resthomes and Prisons. Stand alone or Networked with Barcoding, other peripheries.
FocusCMC: FoxPro v2.6--Maintenance and enhancements of Elevator and Boiler Apps for States of Ohio and Tenn. Programs were multi-user, network distributed and designed for ease of maintenance.
Continental Promotion Group Inc: Visual Fox,2.6,Dos—Processed rebates, Coupons and gift items. Wrote several modules accessing mega tables and integrating app into larger application that was table driven.
Nordam Repair Division: FoxPro v2.6 Dos—Manufacturing using Fourth Shift software. Screens and reports used downloaded data in twelve coded and documented Foxpro modules. Programs accessed through directory.
IBM/State of Mo. DNR: FoxPro v2.6 Win—Designed and coded input screens for Federal Govt SuperFund, managed by State. Forty-nine FoxPro Screens and fifty Tables comprised the Foundation Read app. Met all client demands.
Equifax: FoxPro v2.6 Win--Designed and coded software to read scanned data, verify it and reformat for mainframe updating. Sybase was accessed using FoxPro Connectivity Kit. SQL selects were used throughout.
Inter-Net: FoxPro v2.6 Win--Maintained and redesigned telecommunications software. A tree hierarchy for downline and upline tracking of shared profits was used to manage the system
State of Ga MHMRSA: FoxPro v2.6 Dos--designed,coded and debugged a normalized database system to track and analyze waiver funds for MRWP. Screens, reports and menus supported fifteen tables with indexes and memos.
Perot Systems: FoxPro v2.6 Win--debugged and rewrote report portions of large Billing Edge software program.Source databases were access from CDs.
Martin Marietta: FoxPro v2.5 Dos--Redesigned and coded several major projects from stand alone Dos Prompt environment to Menu driven windows.
Graduation-1991 Petroleum Exploration in Texas and Oklahoma
Education BA Mathematics and Philosophy from Baylor University
Ron Cherry Austin,TX 512-331-1727 cherry@roncherry.com
Project Details Q-sys(Aug01-Jan02) Visual Fox v7.0
Custom Classes and Clever Searches
Design and Coding Challenge: On the Patuxent River in Southern Maryland lies a resort island, Solomons. Just north of the island is a Navy Recreation Center, no palm trees but clear water and sandy beaches. Some of the recreation area has been turned into a Logistics Support Center where parts are reworked, stored and shipped. Salvaging or Reclamation is a small portion of the operation and the app I maintained supported reclamation. Visual Fox Custom classes are an integral part of the app. Another feature of Visual Fox is a grid. This is like putting a browse window in a screen. Getting around in the grid is accomplished by scrolling, tabbing and clicking. Searching the grid is done from a text field. Several of the modules I designed and coded used grids and grid searching.
Design and Coding Response: The custom classes in the reclamation app are used for three distinct purposes: as subroutines, as a supplemental class and as a piggyback class. Methods can be called like a subroutine is called, the classes are searched until the method is found and then executed. Classes can be inherited so it will default up the inheritance chain which can be manage with the dodefault and nodefault commands. This can complicate reading the code especially when the inheritance chain is many classes deep. The debugger is indispensable when tacking down code locations. Supplementing an object with other classes properties can be accomplished by creating the object and simply accessing the properties. This makes, for instance, table names available to the current object that were previously defined. It can be useful to always have the calling object as a supplementing object. Instead of creating an object the object can be passed or piggybacked to another object. The init method of the object can test for object type and the object can be assigned to a variable. The object can then be accessed and updated as any other object. The advantage of passing the object is that the settings persist between passes. Defining objects, passing objects and deep inheritances can complicate an app. Its not the way I would have designed the app but it was a valuable and fun introduction to Custom classes. A number of the class methods were called only once, these could easily be part of the calling object and many of the piggybacked variables could be declared global. But once the app is familiar the encapsulation inherent in classes made it easy to work since the methods are isolated or grouped together. Compared to Fox v26 and its browser the grid is capable and easy to code. The features are many and they tie in smoothly with a text search. It takes two methods and one property to implement a really first class listing module. One way is to type the following statement in the Form init method: "this.grid1.SetAll('DynamicBackColor','iif(RECNO()=thisform.gridrecno,8453888,16777215)','Column')". On refresh the color of the grid record defined by the property "gridrecno" is changed. Gridrecno is set in the text field method "Interactive Change Event" where every hit on the keyboard is monitored. As each letter is typed in the lookup text field the color of the text changes, green if found and red if not found. This is handy and flashy to boot.
Ron Cherry Austin,TX 512-331-1727 cherry@roncherry.com
Project Details First Air Express(Feb00-Feb01) Visual Fox v6.0
EDI and Reporting, two of the many tasks successfully accomplished.
Design and Coding Challenge: First Air Express is a transportation company that moves goods by air and truck to destinations mainly within the United States. Bulk of the business is with Dell Computers who has large volume clout and a headlock on the transportation sector. Profit margins are low and employee turn over in the company is high. Training is an issue, costly mistakes are made. To reduce data entry Electronic Data Interchange is used for remittances, the EDI 820 format. Dollar amounts and other data are moved to SBT accounting tables from the transmitted 820 ascii document. One of my tasks is to make that move. Another task is to update legacy reports into a Visual Fox Project. The reports have accumulated over several years and several programmers, resulting in a jumble of supporting programs and screens. The task is to standardize the user reporting process making it a uniform experience and to streamline the coding for easy maintenance.
Design and Coding Response: The EDI ascii data is read one character at a time with each segment element of data being inserted into a table. A "sets" table stores all elements for segments ST,BPR,CUR,REF,DTM,N1,ENT and SE , likewise, an "items" table stores RMR,REF,ADX and NTE. Each sets record represents a check and each items record represents one remittance including invoice number and invoice amount. Once all the segments are stored in a table the items table is scanned comparing the edi data with the current SBT data determining if payment is Under, Over, Full, Zero, Twice Pay or Insufficient. An exception file is kept for printing under and over amounts and invoices paid twice. The data are reorganized and inserted into different tables suitable for appending into SBT tables. The tables are then set aside till the check arrives. When the check is in the bank, the date of the check is recorded, the module to append the SBT tables is run and the task is complete. A drone runs the module late in the night when the SBT files are not being accessed. All the thousands of remittances are entered in seconds without error and hassle free. The reporting was streamlined by moving each report into a reporting table record. Each of these records has a column for setup code, sorting, sql selects, more code, calling name, report name, report title, printing and closing. To run a report a program is called with the calling name, the name is found in the reporting table and the columns are executed accordingly. Further each report form(frx,frt) is stored in a separate table as memo fields with the report name. This provides: 1) all reporting is data and can be updated without rebuilding the executable; 2) maintenance is independent of the main program, that is, the report can be run without opening the calling program. Further more, all coding for all reports is in a single, searchable data structure. This streamlining of code forces a uniformity on the process of running a report, each run uses the same screens and most of the same code.
Ron Cherry Austin,TX 512-331-1727 cherry@roncherry.com
Project Details Focus CMC(Oct98-Nov98) FoxPro v2.6, Visual Fox v5.0
SQL and Grids
Design and Coding Challenge: Make enhancements to Ohio and Tennessee Boiler and Elevator Apps from a long list of desired changes and add ons. A couple of those desirables are of interest: one was a billing module to determine delinquent payments for inspections and licensing, the other was a data entry module utilizing Visual Foxpro features to record payment and interest amounts.
Design and Coding Response: Inspections on Elevators( and Escalators) were required every six months and inspectors had to be licensed by the State and periodically retested plus the Elevator had to have an original permit. Each company was notified and records kept of payments for audits, lawsuits, etc. Statements were sent three times and if still unpaid the account was sent to the Attorney Generals office for action. If the company was a State agency the billing route was different. This represented a lot of money and the State was not successfully recovering these delinquent bills. To get a list of delinquent bills to the Attorney General, the data tables had to be selected and additional tables for printing had to be created. A lot of qualifying of data was required to accomplish this task. To execute one select statement, macro substitution was used for each select clause so that the select statement looked like: SELECT &selfields &selfrom &selwhere &selorder &selgroup &selhaving. Each clause was conditionally assigned char values based on requirements of the data. This greatly improved the readability of the code and since it is structured the coding is more concise. The Visual Foxpro entry module was written using free tables. Container classes pageframe and grid were subclassed and several grid classes were built for the separate frame pages. Control classes were subclassed to complete the framework for the project. Within the Grid columns several objects were added to simplify data entry and reduce user input typing errors. Combo boxes were added to columns that allowed a data entry person to select a menu option instead of typing an entry. Spinner and Check boxes can also be added to a column. Several of the Visual Grids had Visual Views as RecordSources. Changes to these views had to be updated to tables. The CursorSetProp and TableUpdate commands were used to accomplish this so that when the Grid was left the table was automatically updated. Visual FoxPro brings a lot of functionality to the coder and user. Users appreciate the added variety that these Visual features provide and the coder gets to wrap his brain around a completely different way of approaching the building of an Application.
Ron Cherry Austin,TX 512-331-1727 cherry@roncherry.com
Project Details Continental Promotion Group Inc(Feb98-Apr98) FoxPro v2.6, Visual Fox v5.0
REBATES
Design and Coding Challenge: A medium size company that process Rebates, Coupons and Gift items for the US and worldwide. The company was functionally divided in three groups: the home workers, the ware- house and general processing which included setting up new accounts, supporting the account and mailing the goods. The home workers opened the mail containing rebate forms, etc and entered the name and address and other data into a Foxpro table. This data table was then uploaded into the general processing database. General processing was organized around a table driven application that did the bulk of the work. The warehouse inventoried items for mailing in a Database. One of the task was to enhance a module that had been written by a contractor that tracked shipping of tear-away pads for rebates. Another task, to be done in Visual Foxpro and 2.6, was to write a module that would estimate, based on warehouse inventory, needed items to maintain the companies inventories.
Design and Coding Response: The pads module task was just a matter of reading the code and making the requested changes. They were not able to make edits to entries and reporting was inadequate, several reports had to be written. One glaring problem with the module was that shipments could be entered more than once so that on a given day a mailing could be made to the same merchant of the same pads, it was changed so that only one shipment a day could be made and if a second was attempted the entry could not be completed successfully. This greatly reduced the number of shipments and improved their accounting numbers dramatically. The inventory task was a real analyst nightmare. The warehouse Foxpro tables used a code for the company identification while general processing used something like a name. It took quite some time to actually figure this out. Inventory is done in a warehouse environment where they are good at organizing but not particularly fond of computers. General processing modules were outsourced and coordinating different functions of the company didn’t happened until the need arose. The need arose and the solution was a table with codes and company names. But the table had to be checked and updated on the fly. Also it was to be written using Visual and v2.6. The warehouse tables were in a Visual Database and for the 2.6 version the data had to be in a free table. So the needed portion of the Visual data had to be selected and reformatted into a 2.6 table. This was accomplished by copying the data using SDF format and then importing into a Foxpro 2.5 table. This was compiled into a small module and ran from the v2.6 module, the shelling out to DOS was nearly seamless, just a flicker. The inventory task didn’t have a lot of GUI, but had several reports and a fair amount of code. The code included a low level generated Foxpro file which was printed on the fly that monitored several aspects of the process as it progressed through the code.
Ron Cherry Austin,TX 512-331-1727 cherry@roncherry.com
Project Details Nordam Repair Division:(Jun97-Oct97) FoxPro v2.6 Dos
Screens and Reports
Design and Coding Challenge: Purchasing and Inventory Control were having problems getting data out of Fourth Shift, the software used to monitor the repair division work. Foxpro was secondary software used on data outside Fourth Shift. Downloads were made every evening, weekly and monthly; downloaded data were in Foxpro format. One programmer was available to support entire small to medium size company, other MIS personnel were occupied with the network and installing intranet. A consulting manager was on site to improve operations, flow of work, communication, etc. One hot priority was to monitor part usage and prevent shortages that slowed production. Another was to find slow moving parts and remove them from inventories. A third was to log requisitions and link with Purchase Order number. Some of this functionality existed in Fourth Shift but was not presented in a usable form, some was simply ignored and some didn’t exist, but all were buried deep in databases with unknown qualifying fields and unrecognizable column headers.
Design and Coding Response: For part usage, from six separate downloaded database files, gathered data into browse screen with indexing options. Function keys offered a browse edit option using partition, lpartition, redit and lock that viewed the same data but in a no scroll format. Two fields could be edited, one toggles between today’s date and empty the other allowed free input, and were used for tracking part usage. Customer Order information was optionally included and individual Orders could be printed from a nifty CO compiling screen. Hot keys were listed in a help screen and detailed documentation was written. For slow moving parts fetched history data from a Fourth Shift report printed to file and read by foxpro low level file commands. Once information available two other programs were spawned, one to track slow moving parts daily usage and one to provide floor with access to slow moving parts list for picking. A file was reserved as ‘the slow moving file’, other reports could be run using different reports. For requisition logging an entry screen with navigation and maintenance functionality allowed requisitions to be recorded and showed Purchase Order information if order was logged into Fourth Shift. Automatically logged requisition if PO entered into Fourth Shift. Data was refresh each night with downloaded data. Req Nos were entered into a comment field in Fourth Shift; the comment fields had to be parsed for these Req Nos, a required prefix was established to ease the parsing. A total of twelve modules were coded including a directory screen allowing users to scan modules by name, description, user and department requesting program and to executing chosen module using a function key. This was accomplished in a DOS batch file that searched for a file name and executed another batch file if found otherwise ended. The directory served as a reminder of what a function did and how it was executed; the modules can be run from DOS prompt. A select option showed a select directory where single SQL selects and other information where stored in memo fields; a function key ran a program that accessed information from the current directory record. The select option is handy for printing reports when no entry screen is required. Documentation was written for all modules. It was a pleasure working with users who were competent, motivated and disciplined.
Ron Cherry Austin,TX 512-331-1727 cherry@roncherry.com
Project Details State of Missouri DNR:(Feb97-Mar97) FoxPro v2.6 Win
SMARS
Design and Coding Challenge: Arrived on the 26th of February and was give thirty-eight pages of specs and was told the Federal funding ceased on 31st of March. Within that time frame the task was to generate Screens, Browses and Reports to enter and report on activity concerning Superfund and other environmental cleanup sites. The specs were well designed and easy to follow; made a lot of difference in time required to get it underway. Emphasis was to be on data entry error prevention and to get as much done as possible.
Design and Coding Response: Work ten hours a day, seven days a week. The plan was to code all the menus but only three screens and get that out to the data entry people to start debugging and get a feel for their requirements. This would also make data available for testing and, depending on how far we progressed with the project, the code that they had would be useable. If all the coding was accomplished and then data entry began they might be left with a lot of code that couldn’t be used. The three screens were New Site, Locate and Edit site. These allowed basic data to be entered in to the app. Data entry fields, memo fields, popups and buttons that opened other screens and performed navigation were qualified with Where functions and Valid functions to ease the entry task. Data entry fields where set to Confirm, the alert bell was set to off, cursor was forced to first character and Object Orders were set. Changes were tracked and warnings given if logical sequences were not followed. Menus included the Main menu, Site menu and the Status menu. These menus have no screens, but where designed to have graphics instead. Each screen has its own menu with minimum options of a ‘status description’ and menu places that can easily be added to later. Menus method is Pushing and Popping of the system menu. From here the program grows; many screens were added, many menus added. After exhausting all there requirements and adding all the specifications there were 48 screens and 54 tables. They were done in time and where at least partially debugged. Other features include four ways to locate Site data. One way used the alphabet, letting the used choose a letter and then choose from a list of Sites that begin with the letter. Another allowed entry of the Site name and if not found the last letter is dropped until a match is found and if more than one is found a list is presented. Yet another allows a word to be entered and Sites with that word are listed. Finally a browse of Sites. The project was called SMARS, an enjoyable experience and a superb train ride.
Ron Cherry Austin,TX 512-331-1727 cherry@roncherry.com
Project Details Equifax:(Nov96-Feb97) FoxPro v2.6 Win
VERF
Design and Coding Challenge: Participate as a team member in converting financials, etc. from IBM E-series program to Dunn & Bradstreet supported SmartStream software. This was a two part task: first part was to get E-series up to date with latest employee information and part two was to provide the team an ASC file to move data to SmartStream. Data for E-series and SmartStream update was delivered in Foxpro Tables from Cardiff Teleform software which scans data. Table data for E-series must be attached to an E-series code and formatted to eighty column input suitable to IBM. Table data for SmartStream was from six different Cardiff forms. Each form required separate ASC file outputs for updating. Verification was necessary for selected fields that required accessing tables in the SmartStream Sybase Database. SmartStream updating was ongoing while E-series update was a one time need.
Design and Coding Response: A structure table was built for E-series data and for each SmartStream form. In addition to field names the table had coding information and verification functions. By scanning the structure table each field of the input data record could be handled appropriately and output generated accordingly. If a field failed the verification test the record was copied to a separate table. A recycle screen was built to processes the corrections and reenter the data into the update cycle. Logic was developed to track errors and corrections and assure that data was not processed repeatedly and not lost. Several methods of checking output ASC files where developed. For E-series codes and SmartStream forms a printed display showed separate fields in different shades of gray making checking easy. Also the data was converted back to a table and displayed in its original form for another check. New forms for SmartStream processing can be added through the screens. This requires that the menus in the application be rebuilt while the app is executing. Another feature of the app is that the foundation read is located in the main menu in cleanup. All the screens are modal so the menu is return to at completion of work in each screen and the read levels are kept under control, less than five. Screen layouts where rendered in black, white and grays with accents in red and blue. The project was called VERF.
Ron Cherry Austin,TX 512-331-1727 cherry@roncherry.com
Project Details Inter-Net:(Oct95-Sep96) FoxPro v2.6 Win
INTER-NET
Design and Coding Challenge: Inter-net was a telecommunications company; they made money managing long distance connections, eight hundred numbers and travel cards. A pyramid like system allowed Associate members to sell, train and recruit new customers and share downline profits on usage activity. Computer programs maintain these customers, sort through long distance usage records and distribute profits. Many variations and marketing inducements have been tried and abandoned; software programmers likewise have come and gone. The computer programs that supported the system was a patchwork of styles, experience and expertise that is hard to imagine. A large percentage of the daily and monthly tasks were accomplished using the command window of FoxPro. Searching for programs and database files, reformatting, appending, zapping, copying and changing lines of code and executing the appropriate applications was time consuming and prone to error. Streamlining code into a good design is required if the company is to be successful.
Design and Coding Response: Data throughput was simplified. A batch like posting was reworked to be truly interactive. Four separate executables were combined into one FoxPro screen. Moving data around on floppys was finally eliminated. Users were encouraged to make suggestions and were involved in making the system run smoothly. The Customer Service operation was radically improved. Information from current tables were made available in a multi-user environment. Updates were possible and carrier billing and customer data changes were integrated into a manageable office environment. Customer Service was operated from one screen with a wealth of information and pertinent data readily available. Check statements, printed every two weeks, were expanded to show detail, source of income. There were about two dozen schemes for making money. Each method had a block of data dedicated to its explanation. As expected this exposed many errors and misunderstandings in the overall system. A longtime employee worked closely on the design of the statements and on their subsequent execution. Hewlett-Packard printing sequences and FoxPro commands were used to print the statements. Unfortunately, this phase of the business was discontinued, mostly for lack of profit! But it was the source of a lot of satisfaction, a very enjoyable experience.
Ron Cherry Austin,TX 512-331-1727 cherry@roncherry.com
Project Details State of Ga DMHMRSA:(Feb95-Aug95) FoxPro v2.6 Dos
WIMS
Design and Coding Challenge: MRWP( Mental Retardation Waiver Program ) is a State and Federal scheme to deinstitutionalize Clients back into the community for a normal life. To accomplish this Federal funds are available to match state funds up to the Slot limits outlined in the Waiver Program at roughly a 70/30 ratio. Funds are authorized and slots filled by the nineteen State Regions. The challenge is to monitor the activities of the Regions so that: 1. the Waiver Program Slot limit is not exceeded, ( no Federal funding beyond Slot limits ) 2. the State Matching funds are promptly reallocated. ( unused State funds are lost at end of fiscal year ) Development environment is FoxPro v2.6 Dos; initially no networking. Regions are to mail pertinent data to Atlanta on floppies or paper.
Design and Coding Response: Data is distributed into six principle tables in the database. One table each for Clients, Client Services, Providers, Provider Services, Region Lapses and Rates. Tables are normalized and all data for a specific Client and Service can be related and accessed as a single record. Tables are maintained using FoxPro screens built with the Genscrn program. User entry is minimized by the table design and by tracking State funds with dates. Dates for funding, service and termination completely define status of State funds. Reports showing status of funds are written using FoxPro Report writer program. These reports are feed by FoxPro SQL Select cursors. Also the SQL count clause is used to report Slots status. Slot limits and matching State fund calculations are checked dynamically as user entry is performed and appropriate warnings are given. An upload and download menu option is available to manage Region's data submissions. The modules check incoming data for consistency, system limits and program requirements. Reports are issued showing comparisons with existing data highlighting changes, additions and other pertinent information. Outgoing data is select by Region and copied to floppy to minimize Region user input; report options exist for paper submission. All coding is organized into a FoxPro Project and Applications are built for execution. The application is Windows-like with menus, controls and overlapping clickable windows. An extensive Help from a Function Key can be edited by user. A Query screen that allows users to save Queries is accessed from the main menu. A Data Dictionary drives Help and Queries features. The App is called WIMS for Waiver Information Management System.
Ron Cherry Austin,TX 512-331-1727 cherry@roncherry.com
Project Details Martin Marietta:(Apr94-Oct94) FoxPro v2.5 Dos
PROMAN
Design and Coding Challenge: From twenty-five existing FoxPro programs execute a specific sequence of these programs based on an accounting schedule of weeks. There are four types of weeks; a Normal week, Month End Initial, Month End Final and a Week Following Month End. Each week requires a different sequence of programs and a different set of Tables that must be available for processing. Also, reporting is different for each week. These programs are executed in sequence from the Dos Prompt according to a check-off list of twenty-eight different steps. A FoxPro programmer is required to perform the day long operation. The challenge is to build one Application that executes the required steps and that an accountant or the assistant can perform with a few clicks of the mouse. The executing sequence must be visible to the user so 'Back Start' can be performed when problems with data are found and corrected. Certain procedures must have stand alone status for execution outside the usual processing sequence.
Design and Coding Response: A table for Week dates and Week types is added to the tables already in the Data Base. The last Week type executed is also stored. With this information and a Case statement of all the possible steps in a sequence, any requested sequence can be executed. Back Start is a pull down menu of visible steps for restarting at an earlier step when necessary. The user marks the Back Start menu with a click of the mouse. The menu marker is moved automatically by the program during processing so the user knows the last step executed. Another menu option shows a window with flow diagram of processing sequence. Boxes in the diagram representing executed steps are live and when clicked results of step are browsed. The menu also has a selection for rebuilding the budget. This occurs completely in the background with only one break for user input. The stand alone programs for execution outside the sequence are also called from the menu. Many of the programs were recoded using structured programming features including SCAN, FOR, WHILE, PROCEDURE and FUNCTIONS. This reduced the lines of code by half and in some cases ninety percent. Reports are regrouped and the user is given the option to print all or a subset or none. Monarch, a third party program, is integrated into the program allowing tables to be built from available reports. All programs are included in a FoxPro Project and an executable Application called PROMAN (Project Manager) is built.