ÐÏࡱá > þÿ ^ ` þÿÿÿ W X Y Z [ \ ] ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿì¥Á M ø¿ r bjbjâ=â= %@ €W €W þ s ÿÿ ÿÿ ÿÿ l n n n n n n n ‚ 2Ø 2Ø 2Ø 8 jØ l ÖØ ¬ ‚ ( Ž ŽÜ ¾ Lé ( té té té té ¼ 0÷ ô $û ü !$ #$ #$ #$ ) L$ ô @& ô 4( * =, ¶ 4( n ý té té ý ý 4( d n n té té I( d d d ý n té n té !$ d ý !$ d d d ¢ [ n n té ‚Ü 0k_‘aЂ °Ë 2Ø ý ý _( 0 ( ó, ý D ó, d ‚ ‚ n n n n Ù West Wind Web Connection For Visual FoxPro Welcome to West Wind Web Connection. This product can connect your Visual FoxPro applications to the World Wide Web in real time, allowing you to take full advantage of Visual FoxPro’s powerful data access functionality for providing dynamically generated Web Content. The supplied classes and tools greatly simplify receiving CGI requests, using the CGI information and generating the final dynamic HTML pages to return to the web server. What you need to check out Web Connection The current implementation of West Wind Web Connection is designed to work with any Web Server that supports either the WinCGI 1.2 or later (WebSite, Commerce Builder, FolkWeb) or the Internet Server Application Programming Interface (ISAPI) (Commerce Builder, MS IIS) specification. You will need a copy of either a WinCGI 1.2 or ISAPI compliant Web Server and have it operational in order to use Web Connection with the example forms provided here. A Web Server is fairly resource intensive so a reasonably fast machine (486-66 or better) and 16 megs on Windows 95 and 20 megs on NT are highly recommended. Web Connection allows you to run multiple Visual FoxPro sessions in order to process simultaneous CGI requests and more memory will make this process much more responsive. Although Web Connection was originally created for and tested with WebSite by O'Reilly Associates, it also works with any Web server that supports the WinCGI (Version 1.2 or later) or ISAPI specifications. This includes Commerce Builder by the Internet Factory (version 1.5 Build 16 or later) which provides secure transactions and Microsoft's Internet Information Server. A couple of extra setup steps may be required to get other servers working (see Running with non-WebSite Web Servers in this document) You will also need a Web Browser (preferably the Netscape and/or MS Internet Explorer) and a copy of Visual FoxPro to run this fully functional demo version. Finally, it will be helpful, but not required, to have a basic understanding on how a Web Server and the Common Gateway Interface (CGI) are used to process interactive HTML pages. CGI is a standard protocol that is used by web servers to return information about the server, the browser and form variables used to capture user input. Features of West Wind Web Connection In-Process Server Web Connection allows you to run Visual FoxPro in ‘Server’ mode to eliminate load time of Visual FoxPro when acting on CGI requests. Instead of calling a VFP EXE file directly all CGI requests call a tiny (11k) EXE file which generates requests that are picked up by the VFP CGI Server class implementation. Speed CGI processing overhead for requests is very small and is measured in sub second times. Simple CGI requests can be returned to the server in less than a second on fast machines. In addition, Web Connection has an option that allows the VFP server to set a higher task priority when processing CGI requests, so that the VFP queries or other code can be processed at the fastest speed VFP allows even when running in the background. Web Connection supports ISAPI, a highly efficient mechanism of processing CGI requests on the Web Server that greatly reduces Web server resource load. Scalability If your web server’s load makes heavy use of your VFP CGI server you can opt to create multiple Web Connection sessions. Simply start up another session of VFP and run another copy of the CGI server program to allow processing of simultaneous CGI requests. In addition to running VFP on the machine local to the Web server, you can also run Web Connection from a networked machine efficiently seperating the data processing and Web service. This reduces CGI processing overhead on the Web server to practically nothing and allows you to scale your data processing to any kind of request load that the Web server can dish out, simply by adding VFP sessions and/or adding sessions on additional machines. Blow away any locally hosted data engine by a wide margin! Easy to use Web Connection was designed with ease of use in mind. All pieces of the framework are implemented as clearly laid out classes that make the process of responding to CGI requests both easy to use and flexible. In addition this documentation gives you an overview of how CGI and the web server interact, so even if you have never used or read about CGI you should be able to create Web enabled VFP applications. Fully extensible via VFP Classes Unlike other products, Web Connection was designed with programmers in mind. Ease of use does not come at the expense of limited functionality. The VFP portion of Web Connection is implemented as a set of easily reused and extensible class libraries (non-visual). The classes are: wwCGIServer to process incoming CGI requests, wwCGI to return CGI information and wwHTML to ease creation of HTML pages under program control. Registered users of Web Connection get full source code to all classes. Pricing Registration for West Wind Web Connection costs $99.00 plus shipping and handling. For this price you get the full Visual FoxPro source code for the supplied classes and utilities. Registration is available via CompuServe’s SWREG mechanism and by check via postal address. To register by CompuServe GO SWREG and search for registration ID #8561. The amount will be billed to the credit card used for your CompuServe billing. Shipping and handling amounts to $6.00 and the registered copy of the code will be e-mailed to you at your CompuServe address as soon as payment is received. If you would like to have the software sent to another address email or otherwise you have to contact Rick Strahl at 76427,2363 with instructions. To register by mail send a check for $99.00 plus $3.00 shipping and handling in the US/Canada, $6.00 in all other countries. All payments must be made in US Dollars. Mail to: Rick Strahl West Wind Technologies 400 Morton Road Hood River, Oregon 97031 USA Mail orders are returned by standard mail, but you may specify an e-mail address to send the program to. Email must either be an Internet address that supports file attachments or CompuServe. Sorry, no credit cards at this time. Support If you have problems, questions, comments, suggestions or customization you can contact me at the following addresses: email: rstrahl@west-wind.com URL: http://west-wind.com/tech CIS: 76427,2363 Phone: (541) 386-2087 Warranty Disclaimer: No Warranty! IN NO EVENT SHALL THE AUTHOR, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THIS PROGRAM AND DOCUMENTATION, BE LIABLE FOR ANY COMMERCIAL, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM INCLUDING, BUT NOT LIMITED TO, LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR LOSSES SUSTAINED BY THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS, EVEN IF YOU OR OTHER PARTIES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Table of Contents TOC \o "1-3" \f \t "CommandHeader,3" West Wind Web Connection For Visual FoxPro GOTOBUTTON _Toc352014588 PAGEREF _Toc352014588 1 What you need to check out Web Connection GOTOBUTTON _Toc352014589 PAGEREF _Toc352014589 1 Features of West Wind Web Connection GOTOBUTTON _Toc352014590 PAGEREF _Toc352014590 2 Pricing GOTOBUTTON _Toc352014591 PAGEREF _Toc352014591 3 Support GOTOBUTTON _Toc352014592 PAGEREF _Toc352014592 3 Warranty Disclaimer: No Warranty! GOTOBUTTON _Toc352014593 PAGEREF _Toc352014593 3 What's New GOTOBUTTON _Toc352014595 PAGEREF _Toc352014595 7 Version 1.49 GOTOBUTTON _Toc352014596 PAGEREF _Toc352014596 7 Version 1.45 GOTOBUTTON _Toc352014597 PAGEREF _Toc352014597 7 Quick Start GOTOBUTTON _Toc352014598 PAGEREF _Toc352014598 8 Startup Problems GOTOBUTTON _Toc352014599 PAGEREF _Toc352014599 9 Using the examples with ISAPI Servers GOTOBUTTON _Toc352014600 PAGEREF _Toc352014600 9 How Web Connection works GOTOBUTTON _Toc352014601 PAGEREF _Toc352014601 10 Web Connection Components GOTOBUTTON _Toc352014602 PAGEREF _Toc352014602 10 Setting up the VFP CGI Server GOTOBUTTON _Toc352014603 PAGEREF _Toc352014603 11 Receiving a CGI Request GOTOBUTTON _Toc352014604 PAGEREF _Toc352014604 12 Processing CGI Requests GOTOBUTTON _Toc352014605 PAGEREF _Toc352014605 13 Creating output quickly with ShowCursor and ShowMemoPage GOTOBUTTON _Toc352014606 PAGEREF _Toc352014606 17 Running Web Connection with Web servers other than WebSite GOTOBUTTON _Toc352014607 PAGEREF _Toc352014607 20 Using Web Connection with ISAPI based Web Servers GOTOBUTTON _Toc352014608 PAGEREF _Toc352014608 21 Troubleshooting GOTOBUTTON _Toc352014609 PAGEREF _Toc352014609 21 Finding WinCGI Temp Files GOTOBUTTON _Toc352014610 PAGEREF _Toc352014610 21 Windows NT and TEMP Files GOTOBUTTON _Toc352014611 PAGEREF _Toc352014611 22 Clean up the temp directory GOTOBUTTON _Toc352014612 PAGEREF _Toc352014612 22 Setting up Web Servers GOTOBUTTON _Toc352014613 PAGEREF _Toc352014613 22 Running Web Connection over a Network GOTOBUTTON _Toc352014614 PAGEREF _Toc352014614 23 Setting up SMTP Mail Capability GOTOBUTTON _Toc352014615 PAGEREF _Toc352014615 24 The wwCGI EXE and DLL files GOTOBUTTON _Toc352014616 PAGEREF _Toc352014616 25 How to use it GOTOBUTTON _Toc352014617 PAGEREF _Toc352014617 25 What does it do? GOTOBUTTON _Toc352014618 PAGEREF _Toc352014618 26 The wwCGI.ini file GOTOBUTTON _Toc352014619 PAGEREF _Toc352014619 26 Class wwCGIServer GOTOBUTTON _Toc352014620 PAGEREF _Toc352014620 28 Parent Class: Form GOTOBUTTON _Toc352014621 PAGEREF _Toc352014621 28 How it works GOTOBUTTON _Toc352014622 PAGEREF _Toc352014622 28 How to use it GOTOBUTTON _Toc352014623 PAGEREF _Toc352014623 28 Exposed Methods: GOTOBUTTON _Toc352014624 PAGEREF _Toc352014624 29 wwCGIServer::Init GOTOBUTTON _Toc352014625 PAGEREF _Toc352014625 29 wwCGIServer::Show GOTOBUTTON _Toc352014626 PAGEREF _Toc352014626 29 wwCGIServ :: SetCGIFilePath GOTOBUTTON _Toc352014627 PAGEREF _Toc352014627 30 wwCGIServ :: SetProgramToRun GOTOBUTTON _Toc352014628 PAGEREF _Toc352014628 30 wwCGIServ :: SetTaskingPriority GOTOBUTTON _Toc352014629 PAGEREF _Toc352014629 31 wwCGIServ :: SetTimerInterval GOTOBUTTON _Toc352014630 PAGEREF _Toc352014630 32 wwCGIServ :: SetLogToFile GOTOBUTTON _Toc352014631 PAGEREF _Toc352014631 32 wwCGIServ :: GetLogToFile GOTOBUTTON _Toc352014632 PAGEREF _Toc352014632 32 wwCGIServ :: LogEntry GOTOBUTTON _Toc352014633 PAGEREF _Toc352014633 33 wwCGIServ :: SetStatusWindow GOTOBUTTON _Toc352014634 PAGEREF _Toc352014634 34 wwCGIServ :: SetCGITemplateFile GOTOBUTTON _Toc352014635 PAGEREF _Toc352014635 34 wwCGIServer::SendMail GOTOBUTTON _Toc352014636 PAGEREF _Toc352014636 34 Class wwCGI GOTOBUTTON _Toc352014637 PAGEREF _Toc352014637 36 Parent Class: Custom GOTOBUTTON _Toc352014638 PAGEREF _Toc352014638 36 How it works GOTOBUTTON _Toc352014639 PAGEREF _Toc352014639 36 How to use it GOTOBUTTON _Toc352014640 PAGEREF _Toc352014640 36 Exposed Methods GOTOBUTTON _Toc352014641 PAGEREF _Toc352014641 36 wwCGI::Init GOTOBUTTON _Toc352014642 PAGEREF _Toc352014642 36 wwCGI::LoadCGIFileNames GOTOBUTTON _Toc352014643 PAGEREF _Toc352014643 38 wwCGI::GetCGIVar GOTOBUTTON _Toc352014644 PAGEREF _Toc352014644 38 wwCGI::GetFormVar GOTOBUTTON _Toc352014645 PAGEREF _Toc352014645 39 wwCGI::GetFormMultiple GOTOBUTTON _Toc352014646 PAGEREF _Toc352014646 39 wwCGI::GetOutFile GOTOBUTTON _Toc352014647 PAGEREF _Toc352014647 39 wwCGI::GetContentFile GOTOBUTTON _Toc352014648 PAGEREF _Toc352014648 40 wwCGI::GetCGIParameter GOTOBUTTON _Toc352014649 PAGEREF _Toc352014649 40 wwCGI::aCGIParms GOTOBUTTON _Toc352014650 PAGEREF _Toc352014650 41 wwCGI::GetCommandLine GOTOBUTTON _Toc352014651 PAGEREF _Toc352014651 41 wwCGI::GetPreviousUrl GOTOBUTTON _Toc352014652 PAGEREF _Toc352014652 41 wwCGI::GetServerAdmin GOTOBUTTON _Toc352014653 PAGEREF _Toc352014653 41 wwCGI::GetServerName GOTOBUTTON _Toc352014654 PAGEREF _Toc352014654 42 wwCGI::GetBrowser GOTOBUTTON _Toc352014655 PAGEREF _Toc352014655 42 wwCGI::IsNetscape GOTOBUTTON _Toc352014656 PAGEREF _Toc352014656 42 wwCGI::GetRequestMethod GOTOBUTTON _Toc352014657 PAGEREF _Toc352014657 42 wwCGI::GetRequestProtocol GOTOBUTTON _Toc352014658 PAGEREF _Toc352014658 42 wwCGI::ForcePath GOTOBUTTON _Toc352014659 PAGEREF _Toc352014659 43 Class wwHTML GOTOBUTTON _Toc352014660 PAGEREF _Toc352014660 44 Parent Class: Custom GOTOBUTTON _Toc352014661 PAGEREF _Toc352014661 44 How it works GOTOBUTTON _Toc352014662 PAGEREF _Toc352014662 44 wwHTML Class: Exposed Methods GOTOBUTTON _Toc352014663 PAGEREF _Toc352014663 44 wwHTML::Init GOTOBUTTON _Toc352014664 PAGEREF _Toc352014664 44 wwHTML::Destroy GOTOBUTTON _Toc352014665 PAGEREF _Toc352014665 45 wwHTML::Send GOTOBUTTON _Toc352014666 PAGEREF _Toc352014666 45 wwHTML::SendLn GOTOBUTTON _Toc352014667 PAGEREF _Toc352014667 45 wwHTML::SendPar GOTOBUTTON _Toc352014668 PAGEREF _Toc352014668 46 wwHTML::SendMemoLn GOTOBUTTON _Toc352014669 PAGEREF _Toc352014669 46 wwHTML::BreakMemo GOTOBUTTON _Toc352014670 PAGEREF _Toc352014670 47 wwHTML::ShowCursor GOTOBUTTON _Toc352014671 PAGEREF _Toc352014671 47 wwHTML::MergeText GOTOBUTTON _Toc352014672 PAGEREF _Toc352014672 48 wwHTML::ShowMemoPage GOTOBUTTON _Toc352014673 PAGEREF _Toc352014673 51 wwHTML::CreateHTMLdbf GOTOBUTTON _Toc352014674 PAGEREF _Toc352014674 52 wwHTML::EnclosedText GOTOBUTTON _Toc352014675 PAGEREF _Toc352014675 52 wwHTML::HeaderText GOTOBUTTON _Toc352014676 PAGEREF _Toc352014676 53 wwHTML::HRef GOTOBUTTON _Toc352014677 PAGEREF _Toc352014677 53 wwHTML::SetAllowHTMLTables GOTOBUTTON _Toc352014678 PAGEREF _Toc352014678 53 wwHTML::GetAllowHTMLTables GOTOBUTTON _Toc352014679 PAGEREF _Toc352014679 54 wwHTML::List GOTOBUTTON _Toc352014680 PAGEREF _Toc352014680 54 wwHTML::ContentTypeHeader GOTOBUTTON _Toc352014681 PAGEREF _Toc352014681 55 wwHTML::HTMLHeader GOTOBUTTON _Toc352014682 PAGEREF _Toc352014682 56 wwHTML::HTMLFooter GOTOBUTTON _Toc352014683 PAGEREF _Toc352014683 57 wwHTML::HTMLRedirect GOTOBUTTON _Toc352014684 PAGEREF _Toc352014684 57 wwHTML::HTMLError GOTOBUTTON _Toc352014685 PAGEREF _Toc352014685 57 wwHTML::NoOutput GOTOBUTTON _Toc352014686 PAGEREF _Toc352014686 58 wwHTML::Table Functions GOTOBUTTON _Toc352014687 PAGEREF _Toc352014687 58 Class wwCGIProcess GOTOBUTTON _Toc352014688 PAGEREF _Toc352014688 61 Parent Class: Custom GOTOBUTTON _Toc352014689 PAGEREF _Toc352014689 61 How it works GOTOBUTTON _Toc352014690 PAGEREF _Toc352014690 61 wwCGIProcess: Exposed Methods GOTOBUTTON _Toc352014691 PAGEREF _Toc352014691 61 wwCGIProcess::Init GOTOBUTTON _Toc352014692 PAGEREF _Toc352014692 61 wwCGIProcess::Process (Virtual) GOTOBUTTON _Toc352014693 PAGEREF _Toc352014693 62 wwCGIProcess::Error GOTOBUTTON _Toc352014694 PAGEREF _Toc352014694 62 wwCGIProcess::ErrorMsg GOTOBUTTON _Toc352014695 PAGEREF _Toc352014695 62 Using Text Wrapper GOTOBUTTON _Toc352014696 PAGEREF _Toc352014696 63 What's New Here's a log of recent changes to Web Connection: Version 1.49 Fully debug ISAPI DLL. With the help of Microsoft's support fixed various serious bugs in the ISAPI DLL. Many thanks to Jim Schmidt for all of his help. Fixed memory leak on large input forms, temp file cleanup and proper WinCGI compliant server variable mapping on MS IIS servers. Add ability to embed FoxPro functions directly into HTML pages as code blocks. Using standard expression embedding with the wwHTML::ShowMemoPage() method it's now possible to create dynamic without creating corresponding Visual FoxPro functions/methods to handle the request. For more info see the updated docs on wwHTML::ShowMemoPage() and MergeText(). New CGIProcess DisplayFile method that display dynamic pages directly from HTML links without attaching code. These default methods are called simply by using wwcgi.exe?DisplayFile~Filename.wc from an HTML link. Version 1.45 ISAPI support in addition to WinCGI to support additional Web Servers like MS Internet Info Server and Purveyor. This version includes a DLL version of wwCGI that can run as an Web Server in-process DLL that does not fire a separate process on the Web server making for better resource usage. Beta Code - use with care. Known bug: Large text areas when filled with more than 300 or so characters can hose the DLL and possibly the Web Server. SMTP email support added with Ed Toupin's Email OCX. All you need is an internet connection and an email account on a mail server to send email with a single method. See wwCGIServer::SendMail()... Support for expiring MS Internet Explorer cache on GET requests off HREF links. Check out the new "Force Reload" option for the wwHTML::ContentTypeHeader and HTMLHeader methods. Miscellaneous fixes to the expression merging code in wwHTML::MergeText. Quick Start I know, I know. You want to get started quickly, so this section describes how to quickly set up Web Connection in a step by step manner. Unzip the wconnect.zip file with the -d switch to create the following directory tree: WCONNECT Main Web Connection Program Files This should be your startup directory to work from. \HTML HTML and images. Copy these to your Web Server HTML directory where you can access them with a browser. \CGI-WIN The CGI executables. Copy these into the Web Servers \CGI-WIN directory. If you don't have one, you'll need to set one up, so that the examples will work. You might have to set up a directory mapping to this directory in order for this directory to be accessible. \TOOLS Several Utility programs \DOCS This Word document and the Help file \WWDEMO The sample application and data wwCGI.exe or wwCGI.dll This is the CGI translation program that captures incoming requests and passes them on to Visual FoxPro to process. This program is what you need to call from all your HTML forms that process CGI requests (example URL address: \cgi-win\wwcgi.exe?TestPage with WinCGI or \cgi-win\wwcgi.dll?TestPage with ISAPI). WwCGI.exe is the required file for WinCGI Web servers (WebSite, Commerce Builder), while wwCGI.dll is used by ISAPI based Web Servers (MS IIS, Purveyor). For the examples to work the wwCGI files need to be copied into a CGI-WIN directory of the server's HTTP root. Preferrably set up a directory mapping for this directory as ("/cgi-win/" pointing it at the physical where the files are copied to). Wconn*.htm/Wconnect.gif/Whitwav.jpg A set of example forms and images that start up the example CGI requests processed by CGITEST.PRG and CGIMAIN.PRG. Copy these files into your HTML root directory on the Web server.Wconnect.htm needs to have CGITEST.PRG running, while Wconn1.htm needs CGIMAIN.PRG. WCONNIS.HTM works with the ISAPI DLL. Wconnect.app This is the Visual FoxPro application that contains the wwCGIServer, wwCGI, wwCGIProcess, Utils and wwHTML classes that provide the CGI handling functionality. This is only a loader program and should not be run directly. Note: Only applies to the shareware version. The full version calls the individual PRG files directly. CGITest.prg/CGIMain.prg These are the sample VFP programs that demonstrates how Web Connection works. The demo sets up the server process and handles the requests that are generated from the wconnect.htm sample page, which uses Time Trakker data to display various different queries. Check out the source code to see how easy it is to build interactive HTML forms and respond to requests. CGIMain.prg works off the examples on the WCONN1.HTM form showing a more sophisticated setup that provides error handling and basic server administration functions. Wconnect.h - A header file that contains all the #DEFINEs used by Web Connection internally. It contains several important status flags like DEBUGMODE which affect overall system operation and error handling. Start up the WebSite or other WinCGI or ISAPI compliant Web server. If you don’t have a copy of WebSite to use you can download a demo at http://website.ora.com/. Set up the server to use a Server Name that maps to an IP address (for example 205.106.005.1) that either matches the address that you have assigned to your machine in the TCP/IP setup section of the Control Panel or use the standard local machine address of 127.0.0.1 or Localhost. Most Web servers recognize the latter addresses as the local machine regardless of the entry you selected in the server setup. Once the server is installed you can run and access Web pages in local mode without an actual connection to the Internet. For example to access the Web Connect demo page you would type http://localhost/wconnect.htm into your web browser’s address window. Once your server is actually connected to the Internet you can use either the full domain name (if one is set up) or the IP address assigned to the machine as discussed above. For more detailed information see your Web server documentation. Startup Visual FoxPro. Move to the directory where you unpacked the Web Connect demo and DO CGITEST. This operation starts up the CGI server and makes VFP ready to receive CGI requests from the Wconnect.htm sample page. Start up your Web browser Move to your local WebSite home page by typing http://localhost/ into the address area to make sure your server is operating properly. This should bring up the default index page for the server. Once you are there, load the Wconnect.htm page (most likely http://localhost/wconnect.htm) and start exploring the sample . Startup Problems When using a non-WebSite server you'll likely have to make a few adjustment to your Web server configuration. Please see the section on running Web Connection with a non-WebSite web server for specifics. Using the examples with ISAPI Servers The examples are currently set up to work with WinCGI Web servers like WebSite. If you want to use the examples with ISAPI servers (MS IIS, Commerce Builder, Purveyor) you'll need to make a few minor modifications to the HTML and example source files. The only difference between WinCGI and ISAPI as far as calling CGI scripts from HTML is that instead of calling an EXE file, ISAPI requests call a DLL. It's a simple matter of changing the the wwcgi.exe calls to wwcgi.dll. If your Web Server supports both WinCGI and ISAPI use ISAPI for better CGI performance. A conversion program is included in the Tools directory. Run the following program from the WCONNECT root directory to convert the code and HTML pages stored in the directory tree between WinCGI and ISAPI versions: DO Tools/IsApiCvt WITH "ISAPI" && Convert to ISAPI DO Tools/IsApiCvt WITH "WINCGI" && Convert to WinCGI The parameter specifies which interface to convert to. This routine updates the sample files provided in the directory tree. You'll need to update the HTML pages in the server root after running this utility. The pages affected are WCONNECT.HTM and WCONN1.HTM. The conversion program also updates the dynmically generated links in CGITEST.PRG, CGIMAIN.PRG and WWDEMO\WWDEMO.PRG. How Web Connection works Using Web Connection with Visual FoxPro code is a snap. This product is designed to be easy to use and provides you with the tools to make connecting VFP to the Web as quick and painless as possible. The following examples are taken straight from the demonstration program which is supplied with this demo. Web Connection Components The essential purpose of Web Connection is to pass CGI requests from the Web server to your Visual FoxPro application and back. The following diagram shows how this task is accomplished: This diagram shows how CGI requests reach Visual FoxPro and your user code. Once your code has control it's responsible for creating an HTML document that gets passed back to the Web Server to display. Here's a description of the four software components that make up West Wind Web Connection: wwCGI.exe/.dll - wwCGI is the intermediary program that is called by your HTML forms and passes CGI request on the VFP CGIServer that is already running and waiting for requests. HTML forms never call your programs directly - every CGI request goes through wwCGI.exe (or a renamed version) first which routes the request to the wwCGIServer to process. This program file must reside in the Web Server's /cgi-win directory. wwCGIServer Class - The wwCGIServer class handles requests that are generated by the wwCGI program file. It is responsible for receiving incoming CGI requests, decoding them and passing a wwCGI object to a user defined procedure of your choice. wwCGI Class - This class encapsulates all the CGI information made available by the Web Server. This includes the contents of form variables and status information about the Web server and the browser that called it. Your processing routine receives a wwCGI object as a parameter for you to use in generating an HTML document in response to the server's request. wwHTML Class - The HTML class provides an optional highlevel interface to creating HTML documents by providing a variety of methods that output HTML formatted strings either directly to file or as string return values. This class can be used to either create entire documents, or as an assisting tool to create documents from the report writer or other HTML output mechanism. Setting up the VFP CGI Server Once the Web server is installed and running, the following code sets up Visual FoxPro to respond to CGI requests in Server mode. What this means is that VFP displays a status form and waits for incoming CGI requests, which are processed and passed on to a user defined function of your choice. Here's the code that accomplishes the task: ************************************************************************FUNCTION CGITEST********************* Author: Rick Strahl*** (c) West Wind Technologies, 1995*** Function: Web Connect demonstration program.*** Assume: called from WCONNECT.HTM form test.*** Website is running and calling*** \Website\cgi-win\wwcgi.exe?Optional_Parm************************************************************************#INCLUDE FOXPRO.H #INCLUDE WCONNECT.H*** Load the wwCGIServer class which retrieves CGI requests and passes*** them to a specified Fox Program/FunctionSET PROCEDURE TO CGIServ ADDITIVE*** Load the wwCGI class which allows accessing the CGI information*** passed by the server. Get variable information and server formats*** MIME headers etc.SET PROCEDURE TO CGI ADDITIVE*** Load the wwHTML class used to make creation of HTML documents easierSET PROCEDURE TO HTML ADDITIVE*** Starts up the server and gets it ready to poll*** for CGI requests.*** You can optionally pass the program name that*** is called, in this case Process() (further down in the code),*** and a number (-2,-1,0,1,2,15) to indicate the tasking priority*** of the CGI processing operation. Higher numbers mean faster*** operation, but affect other system processesoCGIServer=CREATE("wwCGIServer","Process",1)IF TYPE("oCGIServer")#"O" =MessageBox("Unable to load the CGI Request Server",; MB_ICONEXCLAMATION,"Web Connection Error") RETURNENDIF*** This actually puts the server into polling mode*** Displays a modal window oCGIServer.show()*** DoneRETURN The program starts by loading the appropriate class libraries and then loading the wwCGIServer class which is responsible for retrieving incoming CGI requests and passing them on to a program of your choice. When you run this code your program goes into server mode waiting for incoming CGI requests until you exit the server by pressing the Exit button. Web Connection will respond to any request that is generated from a form that calls the wwCGI.exe stub program. A sample link that calls your VFP CGI processor looks like this: Simple CGI Test
Receiving a CGI Request The particular request above is generated off a standard HREF link, but the method is similar when using HTML forms and the SUBMIT button. What happens with this request once activated by a click from the browser? The wwCGI.exe program is called and formats the request so that the wwCGIServer set up in the above code can see it and process it. The server kicks in and translates the request by internally creating a new CGI object from the wwCGI class. This CGI object encapsulates all the CGI information that the Web Server supplies as part of the Windows CGI protocol. It sounds fancy, but in actuality the CGI object simply translates the Web Server's commandline to find an INI file, called the ContentFile, that contains all the CGI settings. The wwCGI class interface simply returns the values contained in this file in a clearly defined method structure. The wwCGIServer now takes this wwCGI object and calls your user defined procedure with it. The called procedure looks like this: ************************************************************************FUNCTION Process********************* Function: This is the program called by the CGI Server that*** handles processing of a CGI request.****** This example creates a process class, which*** simplifies error handling and validation of*** success. However, you can use procedural*** code if you prefer.*** Pass: loCGI - Object containing CGI information************************************************************************LPARAMETERS loCGI*** Demonstrate how to get some CGI varslcParameter=UPPER(loCGI.GetCGIParameter()) && Optional CGI params following EXE namelcOutFile=loCGI.GetOutfile() && The HTML output file lcIniFile=loCGI.GetContentFile() && The CGI content File (INI) *** Now create a process object. It's not necessary*** to use an object here, but it makes error handling*** document and CGI handling much easier!loCGIProcess=CREATE("CGIProcess",loCGI) *** Call the Process Method that handles routes request types *** to methods in the loCGIProcess classloCGIProcess.Process*** Debug: See what the input and output files look like*RELEASE loCGIProcess && Must release first or file isn't closed*COPY FILE (lcIniFile) TO TEMP.INI*COPY FILE (lcOutFile) TO TEMP.HTMRETURN Note that your called procedure must accept a wwCGI object as a parameter. For demonstration purpose the first block of code copies the most important CGI parameters to local variables: The CGI parameter and the Output File. The output file name, extracted with the .GetOutfile() method is the most important piece of information you get from a CGI request. Your HTML output needs to be stored in this output file in order for the Web Server to complete the CGI request. Once processed and created the Web Server displays the output file to the Browser that generated the CGI request. You can use the CGI parameter string which is passed after the ? on an HTML commandline and retrieve it .GetCGIParameter(). This method identifies each request made on the Web Server. Since your VFP code is likely to process more than one type of request (for example you might display a customer form, a sales detail form, or an inventory item list) you usually end up with a routing program that contains a large CASE statement that uses the CGI method parameter you assigned to decide what type of action to take. Think of it as the method parameter - in the above request wwCGI?Test_Page everything following the '?' or ‘Test_Page’is returned to you. You can also stack parameters with special characters to pass keys and output text back to your CGI processing code that allow you to customize requests based on choices made on the previous form or query. For example you could use the following in a link to display a specific customer based on a selection: /cgi-win/wwcgi.exe?ShowClient~BGP+Productions The ~ and + signs are optional choices, but I use the tilde to seperate parameters past the first and the plus to indicate spaces. CGI parameters do not support spaces so translating them into another character is necessary. You can use the .aCGIParms() method of the wwCGI class to get all parameters returned to you in decoded form and then use .GetCGIParameter(x) to retrieve a specific parameter number. Processing CGI Requests Once the request is received a processing routine is set up to handle the different types of requests that your CGI service needs to handle. As mentioned above this code consists of nothing more than a large routing CASE statement with entries for each request to process. The code (in this case the CGIProcess class' Process method) looks something like this: ************************************************************************* CGIProcess :: Process************************** Function: This is the callback program file that handles*** processing a CGI request*** Pass: THIS.oCGI - Object containing CGI information*** Return: .T. to erase Temp File .F. to keep it************************************************************************FUNCTION ProcessLOCAL lcParameter, lcOutFile, lcIniFile, lcOldError*** Optional CGI parameters following EXE namelcParameter=UPPER(THIS.oCGI.GetCGIParameter(1)) DO CASE *** Simple Test Page CASE lcParameter = "TEST_PAGE" THIS.TestPage() *** Display results from Client Form Query CASE lcParameter = "SHOWHOURS" =THIS.ShowHours() *** Display Client List CASE lcParameter = "CLIENTLIST" =THIS.CLientList() *** Backfill the Client Name CASE lcParameter = "FILLQUERYFORM" =THIS.FillQueryForm() *** Drill Down from Query Result shows client info CASE lcParameter = "SHOWCLIENT" *** Show the Client Specified =THIS.ShowClient(lcParameter) *** Drill Down From Query Result shows Time Slip CASE lcParameter = "SHOWSLIP" =THIS.ShowSlip(lcParameter) CASE lcParameter = "REDIRECT" =Redirect() OTHERWISE *** Display an error message *** The error method creates an error document *** describing the error and overwriting any existing *** HTML output to the output document. *** Uses the HTMLError Message to create error doc THIS.ErrorMsg("The server was unable to respond "+; "to the CGI request."+; "Parameter Passed: '"+PROPER(lcParameter)+"'...",; "This error page is automatically called when a "+; "Visual FoxPro code error occurs while processing "+; "CGI requests. It uses the wwHTML::HTMLError() method to "+; "output two error strings and generic server information, "+; "as well as overwriting existing HTML output for this request.")ENDCASERETURN .T. As you can see this routine does not do much more than route the individual types of CGI requests that your code is set up to handle to the appropriate processing method of this class. As I mentioned above you don't need to use a class to handle this - this process routine could simply be your top level program file called by the CGIServer. Nevertheless, use of a class has a distinct advantage by setting up the CGI and HTML objects once and then always allowing access to it, as well as being able to handle errors with an error method that can properly shut down the class by displaying a special error HTML document. Finally, the routines called from the routing routine need to actually create the HTML document. There are many ways to accomplish this task from manually coding the HTML strings, to using the report writer to output ASCII text files or merging documents with embedded HTML strings. Whichever method you use, you'll find the included wwHTML class handy. The class provides for an easy mechanism of creating and outputting HTML text to a file, by providing a variety of methods to simplify generation of common HTML tags under program control. All class methods can either send their output to a file or return the individual HTML strings as string return values. The example code uses this HTML class in code to generate the output to illustrate the class' functionality, but you can use any method you see fit to create the document. In its simplest form you can simply use the Send and SendLn methods to output text to the file: loHTML=CREATE("wwHTML","TEST.HTM")loHTML.HTMLHeader("Visual FoxPro CGI Hello","Page Title","Back.gif") loHTML.HeaderText("H1",[Hello World Wide Web World!])loHTML.SendLn([
])loHTML.SendLn("This page was dynamically generated by the CGI request that you "+; " see in your browser's 'Location' or 'Address' line.")loHTML.HTMLFooter() To make it easier to create simple output pages like this, Web Connection includes wrapper.scx which allows you wrap text lines from the clipboard with a leading and trailing string. With this you can simply copy an existing page and generate code on immediately from it. The majority of forms only contain small portions of dynamic data, so this comes in quite handy. There's much more functionality in the wwHTML class to create links, images, tables, lists and manange memo formatting, merge text with table data etc. The following is an example from the demo, which generates a customer list containing hotlinks to another CGI request by querying the supplied TT_CUST customer table: ************************************************************************ PROCEDURE ClientList ******************** *** Modified: 11/11/95 *** Function: Shows List of clients and allows selection of *** Client to back fill query form by running another *** CGI request to redraw the original form. ************************************************************************* lcOutFile = THIS.oCGI.GetOutfile() loCGI=THIS.oCGI loHTML=THIS.oHTML *** Get all entries that have time entries (expense=.F.) SELECT tt_cust.Company, MIN(expense) AS HasTimeEntries ; FROM TT_CUST, TIMEBILL ; WHERE tt_cust.custno=timebill.custno ; GROUP BY 1 ; INTO CURSOR TQuery IF _TALLY<1 =THIS.Error("No Clients available.") RETURN ENDIF *** Create the document header loHTML.HTMLHeader("Complete Client Listing","Web Connection Client List") loHTML.SendLn("* --- Client has time entries to review.
") loHTML.sendln(loHTML.HREF("/cgi-win/wwcgi.exe?FillQueryForm~","No Selection",.T.)+"
")
SCAN
*** Create a HLINK to another CGI script for each client
lcCGICompany=STRTRAN(TRIM(Company)," ","+")
loHTML.sendln(loHTML.HREF("/cgi-win/wwcgi.exe?FillQueryForm~"+;
lcCGICompany,company,.T.)+;
IIF(!HasTimeEntries,"*","")+;
"
")
ENDSCAN
loHTML.SendLn("
formatted based on your browser) simply by calling it when a VFP table is open in the current workarea. All fields and and values are automatically displayed with a single line of code, including column headers and the ability to sum all numeric columns. Using the ShowCursor method looks something like this: SELECT SUM(hits) AS Hits, ; TRIM(lower(location)) as Location ; FROM webdetl ; WHERE &lcFilter ; GROUP BY 2 ; &lcOrder ; INTO CURSOR Tquery IF lcDisplay="H" *** Allow HTML Table to display if count is Ok loHTML.SetAllowHTMLTables(loCGI.IsNetScape()) ENDIF loHTML.HTMLHeader("Web Hits for "+lcBasePath,,BACKIMG) loHTML.ShowCursor(,,.t.) loHTML.HTMLFooter(PAGEFOOT) USE IN TQuery USE IN WebDetl RETURN That’s it. Create a query, set up a page header then simply show the table with ShowCursor and finally put a footer to the HTML document. Simple stuff. Note that you can embed links simply by having your SQL statement embed the HREF or other codes directly into the query result! The ShowMemoPage method allows you to store HTML pages containing Visual FoxPro text expressions either in a memo field of a special system table (wwHTML.dbf) or inside of text files. You can create your HTML output without writing any code, and send the HTML document to the output file with a single command. A sample page stored in wwHTML might look like this:Windance Item Profile
Windance Item Profile: Item # #con2.itemcode##
Item Code: ##con2.itemcode## Year: ##con2.year## Description: ##TRIM(con2.Descrip)## Size: ##con2.size## Condition: ##con2.condtn## Price: ##TRANSFORM(con2.askprice,"$$$,$$$.99")## Comments: ##TRIM(con2.Comments)## ##IIF(plAddUsedItem, THIS.SendLn([Item Added to this order],.T.), THIS.SendLn([ ],.T.) )## |
Windance 108 Hwy 35 Hood River, Or. 97031 Ph. (503)386-2131 Fax (503)386-3151 E-mail windance@gorge.net |