Chapter 2: Planning for Success
Do you ever plan for success, or even plan for a failed deployment? Planning a deployment helps in avoiding the pitfalls and helps set your customer ‚ s expectations as to what happens when the software development is considered complete and ready for installation. It also hopefully ensures you are more prepared to deploy the solutions successfully than you would be if you did not take the time in advance to consider all the issues that can cause problems.
A number of issues need to be resolved before actually creating the SETUP.EXE. The issues presented in this chapter are best discovered and resolved before any code is developed because they will affect the design of the application, the architecture used in the development, and how the final solution is deployed in production.
Computing Environment
How many times have you shown up with the CD (or diskettes, tapes, zip disks) to find out the special label printer the end user needs for the application was never ordered? Have you shown up with a professional looking CD just to find out no machine in the office has a CD player because the boss does not want them used to play music in the office? Many custom applications need new hardware. Whether it is the latest in processor technology or the simple fact of dumping the dot matrix printers for a 32 page per minute laser printer, many applications have special hardware needs. Verification that needed hardware is delivered ahead of the application can save some embarrassment in the delivery of your new or upgraded solution.
Workstation inventory
The hardware that runs applications gets cheaper and cheaper every day. New functionality and increased capability and capacity continue to double every 18 months, which is recognized in our industry as ‚“Moore ‚ s Law. ‚½ The demands of software and the developer tools used to create solutions also require the hardware meet a certain level of performance.
What type of hardware does the customer already have that is working and capable of running applications developed in Visual FoxPro 8.0? You know Visual FoxPro has a minimum recommendation. However, we have found the minimum recommended is not always the minimum we would recommend for our clients .
| Note ‚ | Microsoft makes recommendations for each version of Visual FoxPro. It is our opinion the minimum recommended hardware will definitely provide the minimum performance and this is usually not acceptable. The minimum also does not take into account which operating system is installed and the other applications running on the same machine on a regular basis. |
| ‚ | VFP 8 | VFP 7 | VFP 6 |
|---|---|---|---|
| Processor | Pentium-class | Pentium-class | 486 66MHz processor |
| Operating System | Windows 98, Windows ME, Windows 2000 Service Pack 2 or later, and Windows XP | Windows 95, Windows 98, Windows ME, Windows NT 4.0, Windows 2000, or Windows XP | Windows 95, Windows 98, Windows ME, Windows NT 4.0, Windows 2000, or Windows XP |
| Memory | 64 megabytes (MB) of RAM minimum; 128 MB or higher recommended | 64 megabytes (MB) of RAM minimum; 128 MB or higher recommended | 16 megabytes (MB) of RAM minimum, 32 MB or higher recommended. |
| Display | Super VGA 800 X 600 or higher-resolution monitor with 256 colors (High color 16-bit recommended) | VGA or higher-resolution monitor is recommended | VGA or higher-resolution monitor is recommended |
| Peripherals | Mouse or compatible pointing device | Mouse or compatible pointing device | Mouse or compatible pointing device |
You may need to determine the recommended configurations for your applications. This knowledge is time sensitive and can be quite fluid because hardware specifications and performance are changed by hardware vendors regularly. Developers find recommendations made six months ago are very different from the ones you give today. Developers also know that ones given in 6 months will again be quite different. You also have to keep up to date with several computer vendors to make recommendation based on the best choice for that customer at the time of the recommendation. Depending on the quarter, our company may prefer one vendor over another based on our last experience with the vendor we last recommended to one of our customers or have used for our internal development machines.
What is the processor speed and how much memory is in each machine? You need to find out what customers have in their existing machines, if they already have some computers, and then compare this information to the required minimum configurations to identify any deficiencies.
Microsoft has included a tool in Windows since Windows 98 called Microsoft System Information (MSINFO32.EXE). Microsoft System Information (see Figure 1 ) displays information such as the operating system (complete with version and service pack), System Name and manufacturer, processor and processor speed, BIOS version and manufacturer, physical memory, virtual memory, drive space, peripherals, drivers, and some software configuration. This list only scratches the surface of details you can ascertain from this applet. The key here is it can be a big help when doing your hardware inventory. The applet also has a print option which prints out all the settings for all the categories. Be prepared for a very verbose and lengthy printout. This author printed his out to an Acrobat PDF file and it was 103 pages long. You can also use Microsoft System Information applet to diagnose computer issues in the technical support phase of the project.
Figure 1. The Microsoft System Information application provides an inside look at the computer including hardware configuration and software settings.
Creating a hardware inventory checklist can be very helpful. It is our experience that each project has its own criteria and each customer has their own tweaks. Hardware requirements change as software needs increase and as new hardware is invented and old hardware is improved or updated.
| On The Web ‚ | We have included a few hardware checklists we found on the web in the chapter downloads as examples for you to review and leverage as you create your own. |
How many computers will the user base need? Asking the customer this important question is sometimes met with blank stares. Does the office have 100 workers, but only 50 will need access to the application at a time and the teams work in two shifts? Often, when early in the requirements stage of development, the customer has no idea how many machines will be needed for the applications since they might not even have hired the staff to do the job. Getting a best guess at this point might be the best you can hope for, and it will help in the planning process. Eventually the customer will have to tie down a number so hardware can be ordered.
What peripherals will be necessary and are available, or will be ordered? Will the application need a specific monitor resolution? Are there special needs for a large monitor with low resolutions ? Does the work environment have harsh temperature conditions or is there little room on the desks, platforms, or work benches where a flat screen might be better or worse ? Do the machines have CD-ROMs or a DVD player so they can import the weekly feed from their vendor, and so you can do the workstation installations? Will a CD or DVD burner be required so to generate offsite backups , or for running an export routine? Are the printers fast enough (page per minute performance) and do they have the maintenance cycles necessary to meet monthly printing needs? Can they print to different trays (for envelopes, various paper sizes, and colors)? How about the need to handle duplexing and print in color? Other concerns can include scanners (resolutions, slides and negatives , paper size , and scanner speed), barcode readers (styles, compatibility, barcodes read), and PDAs (Palm or PocketPC, how much memory, synchronization capabilities, and developer tools). While there are common issues for each project, it is more common with respect to peripherals that you have custom issues to account for each time.
Since this book is being written in 2003, we are now dealing more and more with the issue of customers asking whether they should be looking at the Windows/Intel platform or Linux desktops for their solutions. The Linux platform is starting to mature and is becoming a viable alternative from our customer ‚ s viewpoint. As Visual FoxPro developers we know there are many technical issues involved in running Visual FoxPro on Linux and it is getting easier to do so each month. Even getting past the end user licensing issues presented to the development community and the technical challenges, you have to know how you plan to address this question with your clients. Having a recommendation that considers the total cost of deployment (hardware, OS, custom software, and ongoing support) is something you should be ready to discuss with your customers.
Figure 2. We have all run into the situation when the hardware infrastructure is a bit underpowered. This is a picture of an IBM PC from the early 1980 ‚ s.
Once you inventory the hardware and know the needs for the new application, you can make recommendations on additional hardware if it is necessary. One thing to keep in mind is customers can tolerate some performance issues and might be able to phase in the purchases at a later date. Knowing what needs to be ordered will allow the customers to make decisions knowing the total cost of the solution. Vendors can usually turn around new computers and peripherals on short notice, so making a decision that is short a couple of computers is not as big a deal as it might have been in the past.
OS Platforms
With FoxPro 2.x there were plenty of OS options with DOS, Windows, Macintosh, and UNIX. With Visual FoxPro we have Windows 95, 98, 98 Second Edition (SE), Millennium Edition (Me), NT 3.51, NT 4.0, Windows 2000 Workstation, Windows 2000 Server (as well as Advanced and Datacenter), Windows XP Home, Windows XP Professional, and Windows 2003 (server). Along with the various Windows versions, you have the montage of service packs to support or not support. Recently developers are looking at running Visual FoxPro applications on the Linux OS as well.
Running FoxPro 2.6 for DOS and Windows applications on newer OS platforms has presented a challenge to developers supporting legacy systems. Developers are recommending several best practices when faced with these challenges.
| Note ‚ | The author of this chapter has not regularly worked on a FoxPro 2.6 for Windows (FPW) application since 1999 and does not even have it loaded on his current development machine, which is running Windows XP Professional. The experiences and information with respect to FoxPro for Windows are based on his conversations with other developers and research based on various forum postings. The author feels strongly that older custom software should run on the operating systems it was developed to be deployed on. That said, we know other developers have other realities and we felt it important to include this information for our readers. |
| Note ‚ | The topic of deploying legacy FoxPro applications on current hardware and operating systems is detailed in Hentzenwerke Publishing ‚ s ‚“Painless Legacy FoxPro Applications ‚½ by Alan Bourke. |
The first recommendation is to ensure FoxPro for Windows runs on faster computers (faster than 333MHz) which newer operating systems are installed on. You need to apply the ‚“fast patch, ‚½ available from Microsoft.
| Note ‚ | The ‚“fast patch ‚½ and related information are available from Microsoft ‚ s Support website in Knowledgebase article number 240982. |
If your customers are upgrading to Windows 2000 or Windows XP and are still running FoxPro for Windows applications, they need to make sure the operating system is installed fresh, not upgraded from the previous operating system. It is our understanding from the experience of other developers that the NTVDM.EXE is not loaded properly if the OS was installed as an upgrade. We have also read that if another 16-bit application is allocated to the NTVDM.EXE program, running FoxPro for Windows terminates that other program.
FoxPro 2.6 for DOS also has some special considerations with respect to the number of file handles allocated by the operating system. Normally this is handled in the DOS CONFIG.SYS file, but in the NT family (NT4, Windows 2000, and XP) it is handled in the CONFIG.NT file. It is a flat text file you can open in Notepad or some other text editor (including the FoxPro editor). Figure 3 shows this file opened in a utility called TextPad (available from Helios Software Solutions, http://www.textpad.com ).
Figure 3. You can edit the Config.NT file using a standard text editor to update the file handles option to something more in line with what your applications require.
You will likely set the files to something a bit higher than the default 40 found on Windows XP. Another approach is to add an entry in the SYSTEM.INI file under the [386Enh] section called PerVMFiles and set it equal to the number of file handles you prefer for your applications. We recommend using the Microsoft System Configuration Utility (see Figure 4 ) if it is available on the operating system you are deploying to and supporting. It can be executed from the Start Menu Run command line, just type in MSCONFIG and press OK. Otherwise, you can use your favorite text editor to make the necessary changes.
Figure 4. You can add the files statement for Windows 98, 98 SE, Me, and XP via the Microsoft System Configuration Utility. Otherwise you need to edit the SYSTEM.INI file via a text editor.
| On The Web ‚ | The FoxWiki has several topics with respect to getting older versions of FoxPro to run on current operating systems. Check out the following web pages: |
The last aspect is the shortcut to the FoxPro 2.6 DOS/Windows application. For the DOS applications, it is recommended the memory settings all be set to ‚“Auto ‚½, especially the Extended (XMS) memory settings (see left side Figure 5 ).
Figure 5. It came highly recommended that all the memory settings for the shortcut (or the PIF file) be set to ‚“Auto ‚½ for better stability. Additionally you can set the compatibility mode to a specific operating system on the Compatibility page.
The last thing you might want to configure is the Windows XP Compatibility mode (right side of Figure 5 ). Each shortcut in Windows XP has the ability for developers and end users to have Windows treat the application as if it is running under a different operating system. You may find running in Windows 95 mode better suits your FoxPro 2.6 DOS/Windows applications.
Now let ‚ s move on to operating system issues with Visual FoxPro. Each version of VFP increased the requirements for your applications to run. VFP 3 would run on Windows 3.1 with some instability based on the Win32s layer, but the preferred platform was Windows 95. Visual FoxPro 5 dropped the Windows 3.1 support. Visual FoxPro 6 and 7 had no additional OS requirements and supported all flavors of Windows from 95 to the current version. Visual FoxPro 8 dumped Windows 95 and NT 4 support. These are important pieces of information because users do not always move forward with current operating systems and likely will have a mixture of different operating systems in their company. Vertical market application developers have even a better chance of experiencing a wide variety of platforms in their user base. Therefore, it is very important to inventory the expected user base to see what platform you need to develop to.
This brings us to a story we hope you can learn from. On January 31, 2003 Microsoft released Visual FoxPro 8 to manufacturing. This meant the product would be on the store shelves and in retail channels in mid-March. We (Geeks and Gurus) were working on an application suite to convert it from VFP data to SQL Server on the backend. We ran into a showstopper bug in Visual FoxPro 7 for release of this product in between the time Microsoft released VFP 8 to manufacturing and before it was in the stores. Our customer did not have an MSDN subscription like we do. We were able to test the bug in Visual FoxPro 8 and found it was fixed. We then asked our customer the magic question about the user base and their platforms. Note, the original application was developed using VFP 6. The developer did a quick survey of his customers to see if there were any Windows 95 and NT4 platforms. He found one customer with Windows NT4 as the primary platform at their site. So we tested the application extensively on Windows NT in our ‚“lab. ‚½ Our customer spent three weeks in our offices testing the application, mostly on Windows XP and Windows NT. We ran into one little issue with the report preview window (since fixed in Service Pack 1), but it was not a showstopper. With this knowledge, and knowing Microsoft did not support releases on Windows NT, we still moved forward. It worked well in production. Several weeks later we moved to the next beta site. They called us and asked why our installer routine would not install on Windows 95. Argh! The customer had two choices, upgrade to Windows 98 (a supported OS) or be test guinea pigs for the application. This issue was not resolved as of this writing. The moral of this story is to understand the OS limitations and know your client base.
What about Windows XP Home in the business environment? We never recommend it, but have found new customers already have it installed. We tested our applications on Windows XP Home and found no incompatibilities with our applications. What most concerns us is the networking limitations as far as connecting to Windows 2000 and 2003 servers, as well as the five workstation limit on a peer-to-peer network we commonly see in small businesses. We strongly encourage our customers to spend the extra money for the professional version of Windows 2000 and Windows XP for client workstations.
What about Windows vs. Linux? There has been much activity in the Fox Community in late 2002 and early 2003 about getting Visual FoxPro to run on the Linux platform. We are not going to rehash all the political ramifications , but rather discuss the licensing and technical challenges that face VFP developers in this regard. First of all, in case you missed it, you need to know our fearless publisher has been promoting the idea of getting Visual FoxPro to run on the Linux operating system (for a recap of his trials and tribulations see his editorial ‚“The Great Linux EULA Controversy ‚½ in the September 2003 issue of FoxTalk). There are a number of reasons people are looking and considering Linux a viable option, so it might be in our best interest to keep one step ahead of our customers on this issue. Most companies or organizations we serve are looking at Linux for the following reasons:
-
Cost: Linux is near free to purchase, while Windows has an automatic cost built into the hardware purchase or upgrades. Linux can be downloaded for free; more polished versions that have a cost are much cheaper than Windows.
-
Licensing: Microsoft really stuck corporate users with stiff licensing language causing their customers to take a second look and see if it makes sense to run a business under these new license agreements. Microsoft is also aggressively pursuing companies that break the license knowingly or unknowingly. Linux is more open and less strict, which is appealing to all users, especially those in non-profit organizations.
-
Open Source applications are more available all the time: developers all over the world are developing applications users have come to depend on.
-
Perception of dependability and security: Windows security patches get plenty of press and each failure or hack is seen as a weakness in the OS. While this is true, developers know for every measure of security there are ways to break it. Linux also suffers from this problem, but because there are more Windows installations at this time, the impact of a Windows security leak is larger.
-
Buzzword Compliance: We have all seen this, the boss of the organization heads into the IT department after reading the latest article in a trade magazine touting the benefits of the next big thing and demand to know why the company is not already doing it. Happens all the time. Linux is getting a lot of positive press.
-
Maturity: All software takes time to mature and become stable. Linux has been around enough at this point to be at this stage. Developers leading life on the bleeding edge have pushed this product to a point of stability where mere mortals can now safely deploy it.
Note ‚ If you are the least bit interested in getting Visual FoxPro to run on Linux you need to get a copy of the articles published in FoxTalk by Paul McNett and Whil Hentzen. Whil and Paul discuss some of the hardships and successes they have had and step you through the process of getting VFP to run on Linux. This is not for the weak, but if you are up for the challenge (we hear it is getting easier each day), head over to http://www.pinpub.com and get the back issues. You can find more information on the http://www.linuxtransfer.com/ web site as well.
Note ‚ The author of this chapter has only played with Linux. This cutting-edge technology, while interesting, does not yet have the deployment interest because our customers have plenty of applications to develop on the Windows platform. This decision does not mean it is not a viable platform, rather it reflects the economics of the situation at the time of this writing.
There are several options for integrating the Linux platform with your Visual FoxPro data and applications. The first is Linux could play the server role and host the VFP data or a run a backend database such as MySQL. Second, with WINE (which stands for Wine Is Not an Emulator) loaded you can run Visual FoxPro on a Linux desktop. Paul ‚ s articles detail how to set up Linux, WINE, and FoxPro. It is our opinion that this is still too unstable to recommend to our clients today, but stable enough to keep our eyes on it for the near future.
Networking
There are a lot of networking issues that can cause a lot of grief for a Visual FoxPro developer. Most developers are software centric and find the necessary evil of networking hardware daunting to deal with on a daily basis. Developers have also proven over the years that customers want you to be their one stop, all knowing, software and hardware vendor for technical support. While some developers hate dealing with the ‚“wires ‚½ aspect of a deployment, you may find yourselves becoming more and more knowledgeable with the infrastructure. Those who really hate this aspect of deployment and do not want the revenue opportunity should find a partner/vendor that can provide the expertise for this part of deployment.
The first thing we inspect at a client site with respect to networking hardware is the hub, routers, and switches ( Figure 6 ). We are looking for 100Mbps performance as a minimum for acceptable performance. We find at least 80% of the time when customers raise a performance issue, the culprit is a slow hub performing at 10mbit or a wireless hub performing at 11mbit (most of the time even slower). Switches are inexpensive now and spending a few hundred US dollars can greatly improve the speed by 10 times. Moving from a 10mbit hub to a 100mbit switch can actually increase the performance of a network by more than 10 times depending on the type of traffic and load usage.
Figure 6. Organizing the network wires lowers the overall support costs, but requires up front planning.
Network segmentation is the second most common problem/issue we run into with our applications performing slowly. Proper segmentation provides a load balance so no one line of the network is bottle -necked. If all the users that use the application are consistently running queries that pull data over wires all sitting on the same hub, or the same network card in the server, you might see a throughput problem. In small businesses this typically is the case because there are only a few users on the network and there is only one server with one network card and one hub/switch in the office. As businesses grow they might not take into account that all the users are still going through the same infrastructure as when they were small or do not properly add the necessary hardware to make sure performance is maximized.
Quality wiring is also critical. First ensure they are using Cat5 (supports 100mbit) or Cat5E (supports 1000mbit), but also be sure the wire is in good condition. We believe most developers have run into the situation where one workstation behaves poorly with their applications and later determine there was a bad network cable involved. If not, consider yourself very lucky. Tracking down wire trouble can be difficult, but can also be corrected easily by replacing the copper wiring.
The newer wireless technology based on the 802.11 standard is very convenient , especially for businesses with a dynamic environment where employees use laptops and move around. A few other reasons some businesses use wireless technology is in office space where they cannot make wire drops , it is not aesthetically pleasing to have wires lying around, or the building is a historical building and the landlord does not want any new holes cut in the walls (that was the case in the first headquarters for Geeks and Gurus).
This technology is easy to deploy, but there are several concerns with it as well. The first is performance. We find the 11mbit speed too slow even when developing and completely unacceptable in a production environment if there is any data transmitted from a server to the client workstation. It is not unusual to get timeouts from SQL Server on a frequent basis, and dragging indexes down from the server with VFP data can be painfully slow. At this time we are still recommending hard-wired networks because of the performance.
There are additional concerns with respect to security. There are many things you can do to secure a wireless network, but for every mechanism to secure it there are several ways to hack into it. These concerns are secondary to the performance issues, but they cannot be overlooked when for most clients their data is their competitive advantage and we do not want it exposed over the airwaves.
The last networking issue we are going to discuss is the server. We need to review both the hardware and the network operating system. We are amazed at how inexpensive server hardware is today. In the past we have seen small to medium size businesses run on weak hardware and be just fine, but now we can ‚“upgrade ‚½ the infrastructure with little additional cost and get much better performance. Naturally, each situation is going to be different, but we recommend dealing with vendors that deal with server technology.
Servers are built for performance and have technology for redundancy and disaster recovery. We are also realistic enough to know some small businesses can run on a peer-to- peer network, which means if there is a ‚“server ‚½ it will be a standard workstation-class machine. Because Visual FoxPro solutions work in this environment, and are often recommended in this environment, you need to be prepared to deal with this configuration. The server operating system can make a big difference in the type of solution you are going to deploy. For instance, if the client has an existing Novell Netware server and has no intention of changing or adding an additional server, we know we cannot recommend a SQL Server based solution because SQL Server does not run on a Netware box. If the customer wants a web-based solution and it needs to run on their Linux box with Apache we cannot deploy a WebConnect or Visual FoxPro COM object on the webserver . On the other hand, we can deploy VFP data on a Netware server and we can deploy SQL Server on Windows NT 4 Server (WinNT), Windows 2000 Server (Win2K), and Windows 2003 (Win2K3). We also can deploy an Active Server Pages (ASP) web solution that accesses a Visual FoxPro COM object to access data in Windows using Internet Information Server (IIS). Knowing the server ‚ s existing infrastructure and making recommendations to upgrade or get a new server is definitely something you want to handle near the beginning of the project, especially if you are subcontracting the networking aspect of the project to another company.
Database platforms
This book is about deployment, not about determining the pros and cons of each database platform and the decision tree in determining the best platform for the application data. There are plenty of books and whitepapers available on the process of selecting the proper database platform. It is, however, important to understand which database platform you are going to use when planning the deployment of the application. Do you have the knowledge necessary to deploy a SQL database backend? Do you know how to access a MySQL database on a Linux server? What is necessary in both hardware and software requirements is to insure your applications can access the data in the production environment? What are the deployment issues you will face when you roll out the solution?
Visual FoxPro data might initially seem like the easiest of the platforms when it comes to deployment. We believe the reason it seems to be the easiest is we have been doing it the longest. After all, you can deploy the database container (DBC, DCT, DCX) and the tables as simplistically as copying the files to a directory. This can be done from a CD, a floppy, downloaded from another network location, or even downloaded from the Internet. The biggest difficulty developers run into is the relative path issue. First of all, the production based tables must be in the same relative path to the database files as they were in development. This is why developers typically place the DBC files in the same directory as the tables. The second issue is the database files have to be in the same relative path to the executable and most importantly, the forms and reports with data environments need to be in the same relative path. Why? The answer is the cursor ‚ s Database property has a relative path to the DBC. Many developers avoid this by using a framework or developing a solution of their own that changes the Database property of each cursor to the current location of the database files. This is a generic solution that simplifies the deployment of the Visual FoxPro data.
SQL backend databases such as SQL Server, Oracle, DB2, SQLAnywhere, Sybase, Ingres, Informix, and MySQL present their own deployment factors. The biggest issues are security and connectivity. Are you going to access them via remote views? If so, you have the same issues with Visual FoxPro database container files (DBC) and relative path problems with forms as discussed in the previous paragraph. Does your application need a mechanism to connect to the backend data? Is this going to be handled programmatically in the application, or are you going to the route of ODBC datasource? Which version of the database is the customer running now? Is it current enough for your applications? Does the customer need to purchase the proper licenses to run the application? How much of the database administration (security, backups, etc.) will the client be able to handle vs. how much will you need to take charge on?
As you can see, we presented a number of questions that need to be answered . There are different challenges when deploying a SQL backend you might not have faced with local Visual FoxPro data that you need to consider. Also, there might be different hardware and server requirements that need consideration when deploying a SQL backend as well (see the section on ‚“Networking ‚½ earlier in this chapter).
Integration with other applications and technologies
It is very common for developers to craft solutions that integrate with other applications and Windows components. Many developers have integrated VFP with Microsoft Office applications, third party COM objects, reporting tools like Crystal Reports, the Windows Scripting Host (WSH), e-mail systems, Fax components , ActiveX controls, Adobe Acrobat technology, Charting/Graphing, and the Windows API.
The biggest deployment challenge is making sure the applications or components are loaded on each workstation where the integration will occur. Once again you may find yourselves confirming the necessary licenses are already purchased or there are plans to order them. We often work with small business clients to find a source to purchase the software. If they are not comfortable installing software we also do this. In small deployments this is a trivial exercise. Deploying to the enterprise at one large office or numerous locations can be far more challenging just from a time consumption point of view.
The second biggest challenge is ensuring the correct version is installed. Many applications have a Version property built into the executable. This allows you to instantiate the automation object and check the property. You can then compare it to the minimum requirements and inform the user if there is a problem. Here is a function extracted from the OFFICEVERSIONCHECK.PRG, available in the chapter downloads (there is one function per Microsoft Office applications):
FUNCTION GetWordVersion(toWord) LOCAL loWord AS "Word.Application", ; lcReturnVal, ; llCreated IF VARTYPE(toWord) # "O" OR TYPE("toWord.Documents") # "O" loWord = CREATEOBJECT("Word.Application") llCreated = .T. ELSE * We have passed an instance of Word loWord = toWord llCreated = .F. ENDIF lcReturnVal = loWord.Build IF llCreated loWord.Quit() ENDIF RETURN lcReturnVal The procedures in the OFFICEVERSIONCHECK.PRG do not capture the error ‚“Class definition ‚name ‚ is not found ‚½ (Error 1733). You may want to add a check if your error handling scheme does not account for this possibility and you deploy this functionality in production where the programs might not be loaded.
You can also access the Windows Registry to find the location of the program with the full path. Here is the code found in the program ACROBATVERSIONCHECK.PRG:
LOCAL loReg, ; lnErrorNum, ; lnErrNum, ; lcRegFile, ; lcAppKey, ; lcAppName, ; lcVersion, ; lnFileVersion lcRegFile = HOME(2)+"classes\registry.prg" lcAppKey = SPACE(0) lcAppName = SPACE(0) * Check for the existence of the registry class IF NOT FILE(lcRegFile) RETURN .NULL. ENDIF * Instance the Registry object loReg = NEWOBJECT("FileReg", lcRegFile) * Get Application path and executable lnErrNum = loReg.GetAppPath("PDF", @lcAppKey, @lcAppName) IF lnErrNum # 0 lcVersion = .NULL. ELSE * Remove switches here (i.e., C:\Program Files\Adobe\Acrobat.EXE "My.PDF") IF ATC(".EXE", UPPER(lcAppName)) # 0 lcAppName = ALLTRIM(SUBSTR(lcAppName, 1, ATC(".EXE", UPPER(lcAppName)) +; 3)) IF ASC(LEFT(lcAppName, 1)) = 34 && check for long file name in quotes lcAppName = SUBSTR(lcAppName, 2) ENDIF ENDIF DIMENSION laFileVersionInfo[1] laFileVersionInfo = SPACE(0) lnFileVersion = AGETFILEVERSION(laFileVersionInfo, lcAppName) IF lnFileVersion > 0 lcVersion = laFileVersionInfo[4] ELSE lcVersion = .NULL. ENDIF ENDIF RETURN lcVersion If you have not integrated with the specific technology needed by the application, you need to begin researching this during the business and technical design phase of the application. It is better to know what development and deployment issues you will face as early in the process as possible. For instance, if your clients require reports attached and sent via e-mail with HTML messages, you need to look at the various PDF generators, what e-mail infrastructure exists or needs to be installed, and how you are going to generate HTML content for the messages. This could mean you learn three new technologies with this one requirement. You may look at report generators that produce PDFs natively, other PDF drivers to integrate with the VFP Report Writer, purchase several tools (one to generate HTML output, one to generate e-mail, and one to connect to an SMTP server), and have the customer change from their existing AOL e-mail account to an ISP that offers flexible e-mail via SMTP. You also have to consider the external impacts of the requirements and make sure the users who will receive the e- mails will have Acrobat Reader to view the reports.
Internet connectivity
It is not uncommon for a feature or two of an application to have some sort of requirement for access to the Internet. Whether it is something basic like e-mailing a logged error or something more sophisticated like getting a stock quote from a published Web service, developers are finding more and more customers needing some sort of Web presence in their solutions.
The first issue to resolve is the connectivity to the Internet. Does it make sense to have a mission critical feature rely on a dial-up account? Can the site running your application get DSL from the local phone company or is the cable provider doing Internet service in the area? Is the demand on the application going to require a T1 line or better be installed and is there a local business able to get such bandwidth at a reasonable cost? These are all questions you need to ask your customers before you create the next big Internet enabled feature for this customer.
There are other considerations as well to determine performance needs on the upload and download side. Most providers of DSL, cable modems, and satellite dish connections to the Internet have slower upload speeds than download speeds. If your customer needs or wants to run a Web server inside of their installation to provide access to their Web site and/or a Web service, then the upload speed just became more important. At this point their customers will be hitting their site and downloading content (which is uploading to your customer).
What happens when the connection goes down? Does your application crash because it cannot send out e-mail, hit that stock quote site, run a report on the latest Detroit Red Wing statistics, or present the latest troop movements overseas? What about redundancy and a backup connection, would these be critical? This is new territory for the majority of developers who are living the easier life in a LAN-based application. If you think you have had a bad day when the local file server went offline for a couple of hours, imagine having users all over the world not being able to access the data served up from the Web server housed in the corporate offices because you left a MessageBox function in the COM object used by the WebConnect process or Active Server Page.
When your applications start depending on the services of others you open up new opportunities for failure. You also take on the additional burden of support when those services are not available. It is one thing to support an in-house Web server or e-mail server when it goes down because we can get our support staff, the in-house IT support staff, or our own hands on the server and fix it. This may not be the case when our applications rely on a Web service that runs on some other company ‚ s infrastructure half way around the world. What are the disaster recovery plans when this is not available? This is a tough question to answer in many cases. These issues and the related answers will dictate the design of the applications.
Physical office layout
As we have stated a number of times, we are software developers and computer solutions providers. We are not experts is office layout, building architects , or interior design specialists. We do find ourselves recommending layout changes to the locations of servers and computers, having to determine optimizations for wiring, and determining where the printers, scanners, and fax machines would best fit. We also need to make sure there is enough room for the new equipment being ordered. Have you ever recommended a 21 inch monitor for someone and found out it will not fit on their existing desk?
Need to order new equipment
The hardware inventory and a complete understanding of the requirements will help you determine whether the customer has the correct number of machines and required peripherals. If not, you need to make sure you make a purchase recommendation.
Some clients will do their own ordering. Many have inside IT departments with standard procedures, preferred vendor lists, and a consistent office environment. These customers handle the purchasing. What we like to do in this case is verify the orders are complete, and find out when the deliveries is expected. It assures us that we will have the necessary hardware to deploy when the application is ready, and it also shows our customers we are on top of all aspects of the project.
The majority of our clients do not want to take part in ordering hardware and want their vendors to help them out. We offer these services to our clients and often deploy the hardware as well as the custom software solution. We know this process consumes time and in the early days of our career often forgot to add this time into consideration when pricing fixed-price contracts. You may find some customers do not expect to pay for advice and direction or the time you spend on ordering the new equipment.
Do you know how long it takes to set up one new machine? After all, new machines come with color coded graphical instructions that make it almost so simple a monkey could put one together, right? Setting up, connecting the monitor to the processor unit, and plugging it into the surge protector might take 15 to 30 minutes by the time you get all the boxes thrown away. What about the time to complete the Operating System installation and registration, register and activate all the preloaded software, configure the network settings, load the printer drivers, make sure the fax software works, connect to the Internet, and then move all the data over from the old machine? Keep this in mind when you are estimating the time you will spend ordering the equipment and deploying the hardware.
Dealing with the unexpected
The only detail we can provide in this section is you will have to deal with something unexpected. Every project has one of those ‚“whoops ‚½ moments when something is forgotten, a detail was not mentioned by the customer, or the developer does not deliver something on time.
The key to a ‚“whoops ‚½ moment is how it is handled. Professionalism is the key to success. We like to inform the customer upfront when we first meet with them that something is bound to go wrong and we fully intend on working toward a mutually beneficial resolution. We have found that declaring our ability to make mistakes shows we are only human and brings an uncommon level of honesty to a business relationship. When a problem occurs, we have learned that immediately communicating the issue to the client is better than procrastinating and letting the problem get bigger. As with any real world problem, having a potential solution to present at the same time usually leads to a better resolution.
EAN: 2147483647
Pages: 232