• What's new in 5.00
  

Don't know where to start? Here are links to get you on your way:

• Roadmap to starting out with Web Connection
  
• Setting up Web Connection
  
• Check out the demos
  
• Take a Step by Step Guide
  
• View a video walk through
  

Can't find it, or you're stuck? Try these support links:

• The West Wind Message Board support area
  
• The West Wind Message Reader
  
• The West Wind Wiki interactive Knowledgebase
  
• KB and White Paper Search (requires IE)
  

What's new

• New RenderAspScript function in wwUtils
  To further ease plain script execution tasks we've added a RenderAspScript function to the wwUtils library. This wrapper around the wwScripting class lets you execute ASP style script pages with a single line of code and return the output as a string.

• Embedded 'WebResource' support
  When building Web applications it's common to have the application have dependent files. Rather than distributing those files you can optionally choose to embed them into the application and have the application serve them for you now. A new wwServer::AddResource method allows adding resources to the running application. For example, you can add a .JS file a .CSS file or even images. AddResource takes a key, the content and a ContentType as a parameter. You can retrieve these added resources then via the WebResource handler in the process class. By calling WebResource.wwd?Resource=Hello you can retrieve that resource dynamically from the server. The Url depends on your application extension but WebResource.wwd (where wwd is your script map extension) or wc.dll?MyProcess~WebResource~&Resource=Hello both work to retrieve content.

• GetCaptchaImage function in the wwAPI/wwImaging library and Captcha Control
  Added a routine that creates an image file from a specified string with basic image futzing. CAPTCHAs are used for verification that a user is actually entering information as opposed to a an HTTP client or browser robot. Routines include raw image generation (GetCaptchaImage in wwAPI), a Process method that handles submitting a CAPTCHA String and retrieving of the CAPTCHA image generically (Process::CaptchaImage). There's also a new wwWebCaptcha control which is drag and drop and can be checked simply by looking at the IsValidated property on a postback.

• Web Control Framework Parsing Improvements
  Framework page parsing now allows for attributes that are split across lines. This fixes some issues where VS.NET sometimes generates long style tags over multiple lines of markup code. Specifcally absolute positioning gets generated across multiple lines and will now work correctly without adjusting the markup code. There have also been a number of small fixes to the main parsing routines. It is now possible to nest some controls of the same type inside of each other. For example, nesting a wwWebRepeater inside of a wwWebRepeater ItemTemplate.

• wwWebPage::SetFocus() to automatically set focus to a control
  Added a simple method that can be used to set focus to any control on a form that supports setting focus to. Simply call this page method and pass in a control reference and the control will then have focus when the page is rendered.

• Distributed Samples Updated
  The wwHttpDemo sample distributed application samples have been update to better demonstrate XML messaging rather than using the original cursor based transfer. While the original sample was little more lightweight using XML is easier and now more common. The samples have been updated to work more consistently and look a little more professional. Specifically the Customer List sample that allows browsing and updating of customers has a new look. The sample is accessible from the Enterprise demo page or by running wwHttpDemo.exe.

• wwWebRepeater::ItemChanged event
  The wwWebRepeater also gains an ItemChanged event that is fired whenever a new item is loaded into the repeater. This allows manipulating the data once it's been loaded but before it is rendered. This event can also be used when nesting child list objects. It's possible to nest a repeater inside of a repeater and you can use this event to load the child repeater's DataSource with new data.

• UPDATE NOTICE: This release changes the wwServer interface so the COM server Typelibary changes. When you update your server in COM mode make sure to completely unload the server and re-register the COM object with <yourserver.exe> /regserver.

Version 5.10

• Updates to wwScripting and ExpandScript and ASP style Script processing
  The way that ExpandScript() and generic script execution works has been completely revamped in this release. The codebase now uses the wwScripting class for all 3 modes of operation: 1 - Dynamic Execution (compiles and checks for changes), 2 - Precompiled Execution (FXP only), 3 - Interpreted (ExecScript Execution). All three models use the same functionality and so operation across the script modes are consistent. The new parser no longer uses TEXTMERGE to output results, so limitations on using TEXTMERGE functionality in your scripts have been lifted. Performance of scripts should also improve somewhat drastically. In debug mode improved error information is also available that shows the error in the relevant code context. The scripting engine now also uses an expanded Response object that allows for easy header manipulation and closer concurrence with the standard wwPageResponse object so you can use things like Response.AppendHeader() or Response.AddCookie() for example.

  Behavior change: The new behavior is the default and it might cause some problems with some existing scripts especially if you manipulated headers. wwVFPScript is no longer loaded by default. To switch back to the old behavior set the WWC_SCRIPT_PROCESS setting to wwVfpScript and WWC_LOAD_WWVFPSCRIPT .T. in wconnect.h/wconnect_override.h.

• New wwWebProgressBar Control
  There's a new wwWebProgressBar control that can be used to show progress information in a page. The control is AJAX enabled so it can be used to process progress information on the server with Page method callbacks. A new sample is provided that demonstrates the AJAX functionality for dynamic progress information.

• Web Control Framework enhancements
  There have been many small adjustments in the Web Control framework that fix a few minor problems and enhance performance in several areas. All of the issues addressed to the Web Control Framework by this release deal with internal behaviors so there are no outward changes in application.

• wwPOP3 fixes
  There have been a few small fixes to the wwPOP3 code that resolves a bug related to message parsing. The previous code could on occasion cause messages to lose their processing context and result in messages getting lost. Fixed.

• WebLog Sample Updates
  The WebLog application has a number of enhancements and added features that demonstrate additional functionality of the Web Control Framework. The WebLog application is meant to be a comprehensive example of a WCF application that uses best practices from use of business objects, to using page based code, consistent databinding and error display to using style sheets for most UI formatting.

• wc.dll Logging Improvements and Synchronization Validation
  The ISAPI extension now includes better logging support by assigning a unique request id for every request and passing that request ID to Web Connection as a REQUESTID Server variable. All logging information written to the wcErrors.txt file includes this request id. There's also a new LogDetail key option in the wc.ini that enables logging of every request (Note: this can generate huge files quickly so use with caution!). These features allow you to trace specific requests through the entire Web Connection processing cycle. There is also a new ValidateRequestId key in wc.ini which will explicitly check the request ID of the request and RequestId header returned with the Web Conneciton output. This feature checks input and output for the request id and if for whatever reason the two don't match the request is not served.

• wwHttp::lIgnoreCertificateWarnings
  New flag added that gets around the apparently frequent problem of connecting to servers that have invalid or expired security certificates. Although I don't recommend doing this (get the server fixed!) this flag will ignore most certificate errors and behave more closely like a browser.
  

Version 5.05

• Client to Server Event Support for Page events
  You can now fire __doPostBack() events against the page itself by specifying 'Page' or 'this' as the control Id for the event target. This makes it much easier to call page level events from things like data grid columns or other complex list controls that need to post back to the current page for actions.

• Web Connection Add-in now available from Context menu
  The Web Connection Add-in functionality is now available on the context menu in the Visual Studio .NET editor. Both design mode and Source View are supported. There's also a new View in Browser option that allows you to navigate to the current page in the editor.

• Web Control Framework Documentation Updates
  There's been a fair amount of new content added and existing content updated with content that's been gleaned from questions and comments on the message board. One specific new topic of interest is Creating Custom Web Controls which describes the full process of creating your own Web Control Framework controls including designer support.

• Many enhancements to the Web Control Framework
  There have been many small enhancements and tweaks to the Web Control framework that make it easier to do databinding and item templates for some of the list controls. Custom even firing has been rewired in the framework so it should be much easier now to fire events manually. Finally a few control naming and script loading issues have been fixed.
  

Version 5.03

• Web Connection Controls Auto Install in Visual Studio
  The West Wind Web Connection Controls now auto-install into Visual Studio when Web Connection is installed, so the controls are available on the toolbox immediately (note if SQL Server Management Studio was installed after VS2005 this auto-install may fail). Script extensions are now automatically installed into Visual Studio as well when you create a new project with a custom scriptmap. These enhancements in most cases will eliminate manual configuration in Visual Studio.

• Enhancements to the wwWebAjaxControl
  The wwWebAjax controls has added a few handy utility JavaScript routines to easily display tooltip and shadow behaviors on existing controls. The PageMethod callback functionality has also been improved to include easier call code from the client.

• Improved performance of the JSONSerializer
  The JSON Serialization routines for the wwWebAjax Control have been improved when serializing data to provide much improved performance for larger result sets. Cursor serialization should be many times faster than in the previous build. Thanks to Web Connection MVP Lauren Clarke for his help and feedback.

• Added automatic VS.NET WebForm Editor association with scriptmap
  When you create a new project with Web Control support enabled Web Connection automatically associates the new extension with the VS.2005 WebForm Editor so manual configuration is no longer required. If you add additional extensions manual configuration will still be required as outlined in the Configuring Visual Studio 2005 topic.

• Admin Page Login Information
  The Web Connection ISAPI DLL Status page now shows current login information as well as the underlying system account. The first value identifies the current Web login via BASIC authentication in the case of the Admin page. The second value shows the underlying system account that is hosting the Web Connection wc.dll - typically SYSTEM or NETWORK SERVICE. Added to frequent requests and confusion understanding which account the Web Connection DLL runs under.

• Many small bug fixes
  There have been many small tweaks and fixes to the Web Control framework in relation to databinding, containership and naming issues. All of these are minor in nature and have no effect on the syntax of existing applications.

Version 5.01

• Added support for multipart alternative email messages
  Multipart/alternative allows sending of both text and html content and has the mail client decide which to use to display the content to the user. A new cMessageAlternate and cContentTypeAlternate properties have been added to support this functionality.

• New wwUtils MailLink Function
  Utility function that embeds Mailto: links as a JavaScript function that's a little more difficult for a page parser to harvest. Pops up mail client if one is configured. You can pass mail link, Text, subject and body. Note this functionality is similiar to the MailLink control in Web Control Framework but can be used anywhere.

• Miscellaneous bug fixes
  Fixed bug with embedded quote characters in values when rendering controls. Updated the Core walk through to work with stock wwPageResponse class. Fixed various small rendering bugs in Web Controls. Changed ClientScript rendering order so general scripts render at the top, StartupScript on the bottom.
  

Version 5.00

• Web Connection Web Control Framework
  Web Connection 5.0 introduces a new Web Control framework that uses control and objects to represent HTML content. The new framework is capable of using ASP.NET style visual designers like Visual Studio 2005 and the free Visual Web Developer. This is a major addition to Web Connection that provides a much richer programming model to developers, visual designer support and provides an easy way to extend existing functionality of the framework by allowing easy extension with custom and user controls.

• Web Connection moved to VFP 8.0 and later codebase
  Starting with Version 5.0 Web Connection will only support VFP 8.0 and 9.0 and later. This has allowed removing of some fairly messy bracketing code, and integrate some of the newer VFP 8 and later features, particularily Exception handling which is crucial for the Web Control Framework.
  
  
• Server.lDebugMode is now a non compiled flag
  Server.lDebugMode which determines whether the server runs in DebugMode or Deployment mode is now a flag that is settable at runtime. The DEBUGMODE WCONNET.H flag has been removed from the core Web Connection engine so switching between debug mode can now be performed at runtime or more commonly via a simple INI file switch.

• New Exception based Error system
  The Error handling in Web Connection has been replaced with a TRY/CATCH based exception handling mechanism that provides much richer flexibility in error handling. This feature removes the Error method based approach that Web Connection previously used. This change made it possible to move to dynamic DebugMode management as Error Methods are no longer included/excluded depending on the DEBUGMODE flag. Instead TRY/CATCH handlers provide reliable error handling and returning to a stable point of origin when an error occurs.

• Overhauled Security System
  Web Connection now includes an extensible security system based on the wwUserSecurity class. The class provides basic login capabilities and user management. The class can be used for simple page based authentication with a couple of lines of code and works as a single line wwProcess::Authenticate() validation. The setup is configurable so you can use custom classes and implementations. The Authentication mechanism also carries into the Web Control Framework, which also includes a new wwWebLogin control that can be dropped on a page and provide control level Authentication on a form.

• New wwCollection Classes
  Web Connection now includes a set of custom collection classes. Classes include wwCollection, wwNameValueCollection and wwStack. The classes are custom because the native FoxPro collection class syntax is backwards, doesn't support case insensitivity and chokes in a variety of scenarios with various standards. The Page framework requires lots of collection support and it's implemented through these classes which use underlying arrays.

  wwWebAjax Control added
  There's new AJAX control that is part of the Web Control Framework that provides very easy AJAX integration into existing applications. The control supports hover window popups from URL content, very easy URL callback support and a simplified Page Method Callback Mechanism that makes it super easy to callback on the current server page and return values using a simple RPC style interface.

• wwCache Enhancements
  You can now use wwCache more efficiently on a URL based basis by not specifying a cache key. If you omit the Cache key Web Connection will automatically construct a current request id that consists of the URL plus the querystring. This makes it possible to easily cache the content of the same page based on different page parameter settings.

• wwRequest.Params method to retrieve values from Form, QueryString, Session or ViewState
  This new function automatically looks in the Forms, QueryString, Session and ViewState collections for a value and returns the one that it finds first. The order used is the order shown here.

• wwSession Update
  Fix: wwSession has been updated with wider fields to avoid any potential session id duplication in high volume scenarios. Although unlikely before the new wider Session Id value that incorporates a thread ID ensures that there are no duplicate ids generated.

• IIS 6 Kernel Caching support
  IIS 6 introduces a powerful feature called Kernel caching which provides dynamic requests to cache on the server the same way as static pages do. Web Connection now supports this feature simply by adding Expires and Last-Modified headers.

• ValidationErrors Member for wwBusiness
  The wwBusiness class now has a oValidationErrors member that can be used to hold validation errors as a collection which is a bit cleaner than the previous string only error. The ValidationErrors collection can also be added to the wwWebPage BindingErrors collection and participate in error display for page errors.

• wwPop3 Fixes
  There have been a few fixes that deal with reading the content containing delimination characters (.'s specifically). The code has been reworked to try and read the message buffer based on message size rather than parsed reading of the content dynamically.

  wwUtils.File2Var reads and writes in shared mode
  File2Var now always reads in shared mode meaning that files can be accessed at the same time. This might improve performance a little with template reads and the like. For writing there's an optional flag that allows shared writes as well although you should be very careful with this option and only use it in special situations. Unlike STRTOFILE and FILETOSTR(), File2Var doesn't cause a FoxPro error but instead returns a blank or .T. and .F. respectively.

• Logging and Request Security Context
  The Web Connection wc.dll now returns a unique GUID and ThreadId for every request which is accessible via Request.ServerVariables("REQUESTID"). wc.dll uses this id to track a request through the ISAPI extension. To ensure 100% that the output you generate goes back to the same user you can add a RequestId HTTP header to your request and the ISAPI DLL will double check that id on return. Should there be any discreprancy whatsoever between the header returned and the ID passed in an error page is displayed. This ensures that data cannot be compromised at any point from within the Web Connection ISAPI environment. This feature has been added to security concerns from several high volume customers who have experienced hardware Web Server problems and this option provides an additional layer of security to ensure that requests are consistent through the request pipeline. Web Connection now adds the Request ID header automatically if you call the default header functionality.
  There's also a new logging mode with a LogDetails INI file flag. If set to 1 this flag logs to wcError.txt out at the beginning and end of the request.

  wwRequest::lUtf8Encoding
  Added a flag that allows retrieving all request data in UTF8 format. When set both QueryString and Form variable retrievals are UTF-8 decoded into the current character set (STRCONV(,11)). This is required for any client page that posts data in UTF 8 format - such as any request data encoded using JavaScript encode or encdeUriComponent functions.

• ISAPI DLL Impersonation Changes
  Due to changing security environments and in order to simplify the ISAPI security environment for running COM objects, Web Connection has change the way that the ISAPI DLL handles impersonation internally. By default the Web Connection ISAPI DLL (wc.dll) now runs under the Web Servers user account rather than the impersonated user that is the default for ISAPI. For IIS this account typically is SYSTEM.

  This change greatly simplifies COM configuration and allows Web Connection in most cases to run in COM mode without any additional configuration beyond COM registration with /regserver. The change also mimizes and simplifies the security impact and gives Administrators control over the security environment that the Web Connection application runs under.

  The new operation is implemented by default but a new Impersonation switch in wc.ini allows switching back to the old style of Impersonation operation.

• wwCache Enhancements
  The wwCache class can now work with a fixed file that can be shared across Web Connection instances. The new optional cFixedFilename property allows specifying a fixed filename that is used to open a FoxPro table as opposed to the default behavior of opening a local cursor. We've also added support for Removal of cache items and cache expiration routines.

• wwRequest::FormVarsToObject - No object input required
  FormVarsToObject can now work without an input object in VFP 8 and 9. A new object is created with properties for each of the HTML Form variables with string values assigned for each of the values.

• PostBufferSize HTML Page key for Post Buffer Oversize errors
  There's a new flag for a PostBufferSize in the Html Pages section of wc.ini that allows assigning a custom message to oversized Post Buffers on input.

• New Utility routines
  There are a handful of new utility routines that have been added to wwUtils. GetXmlDomObject is a factory method for an MSXML object using a predefined Progid defined in WCONNECT.H. GetRegExObject does the same to retrieve an instance of the VBScript RegEx object. CopyObjectProperties does a shallow copy of properties of an object instance to another instance. Note this differs from the CopyObject routine which creates a new object.

• Miscellaneous Updates and Fixes
  This version update is relatively minor and rolls together a few errata that have come up since the release of 4.65 a couple of weeks ago.There are a few minor bug fixes and a few kinks in the setup routines that have been fixed and updated and supercede the update files posted previously.

• wwHTTP::HTTPGet adds a download to file capability
  To further reduce the need to use HTTPGetEx() for HTTP access the HttpGet() method now supports a 4th parameter to download HTTP content directly to file. This is useful for downloads of large content so that the output is moved into memory and returned as a string - useful for multi-megabyte downloads. This functionality was one of the last features that had to resort to using HttpGetEx(). HTTPGetEx() still is the low level interface to wwHTTP and HttpGet() delegates to it, but user code is recommended to use the easier to use HTTPGet() method.

• Documentation updates
  There have been a number of documentation updates to the Setup and Configuration topics. Specifically the 'troubleshooting' sections have gotten a big overhaul with topics rearranged and content adjusted for newer Web Servers. Among them: Troubleshooting Filebased Server Installs, Apache for Windows Manual Configuration, Deploying an application to a live Web Server, Manual COM Server configuration and Manual File Server Configuration.

• Improved Support for Apache 2.0 ISAPI
  A lot of people have been asking about Apache support and Web Connection now includes a custom Apache Module that works around some issues with the Apache ISAPI implementation. One of the things this module does also is provide Windows Authentication to Apache (optoinally) so it makes Apache behave more like IIS in terms of program driven (Basic) Authentication. The main reason this was done is to make sure that the wc.dll Admin functions can be locked down which otherwise would have been very tricky to setup with Apache script security.

• wwGhostScript
  The wwPDF classes now support the free GhostScript interpreter to generate PDF files. We've implemented a small wrapper DLL function for GhostScript that is part of wwIPStuff and can quickly and efficiently render PDF output from PostScript files. The functionality of this class will be identical to the wwDistiller class - you still need to install a PostScript Printer to print a PDF file first. Performance of this interface is much more efficient than Distiller.

• wwXFRX and a few other updates to wwPDF
  The wwPDF class also adds suport for XFRX to compatible PDF generators in Web Connection. XFRX is a VFP based PDF (and several other formats including DOC, XLS, HTML, RTF) generation tool that uses VFP reports natively. The wwPDF documentation has also been udpated to reflect the latest new drivers and a more extensive comparision between the supported drivers.

• InstallPrinterDriver Function in wwAPI and Console option
  In order to facilitate installation of a Postscript Printer driver that can be used with the wwDistiller and wwGhostScript PDF generation classes there are now a couple of easy ways to install a printer driver. The wwAPI library contains the InstallPrinterDriver function and the CONSOLE.EXE has a new command line option "INSTALLPRINTER" that can be used to perform this task. Useful for installers or quickly configuring a machine via a batch file.

• wwResponse.TransmitFile allows sending large Response output
  The new TransmitFile method of the Response object allows sending huge output from Web Connection applications without having to read this data into memory. Output can be sent to file which is then sent to the ISAPI DLL directly. DownloadFile has also been updated to use TransmitFile behind the scenes. This simple function makes it much more efficient to serve contents from files to your clients for applications like secured access areas of for pay content etc. This function has lots of implications from allowing large output (larger than 16 megs) to be created in Web Connection to providing lightning fast access to files without passing them through Web Connection.

• New wwServer::lUseRegistryForStartupPath property
  This new flag allows overriding Web Connection's default behavior of looking in the registry to find the startup path. This behavior is the default and used to allow remote machines to start an application in a specific directory rather than defaulting to the current directory. When set to .F. Web Connection now always starts in the current directory.

• wwSQL::ExcuteNonQuery Method
  Added a new method for running non-result set returning SQL Statements. Although EXECUTE supported this functionality before these methods have been isolated explicitly to allow for wwADOSql's customized routines that use different mechanisms to retrieve data and run commands.

• wwSql improvements and wwADOSQL Class
  wwSQL now has a AddParameter method that allows you effectively create parameters on your SQL statements and pass them around - this feature avoid hardcoding SQL parameter values and is a big help in sidestepping SQL Injection issues. wwADOSql is a new class that provides the same functionality as wwSQL but uses ADO. While slower than SQLPassthrough, ADO provides the ability to deal more effectively with Unicode data. This new class requires VFP 8 for basic operations and VFP 9 in order to take advantage of effective Unicode data access.

• New Unicode Language Sample Added
  We've added a sample that demonstrates how display content in Unicode format from VFP data. Sample demonstrates how to capture and display extended characters for upper character sets like Chinese, Korean and Russian and display multiple languages in the same page by utilizing binary fields to store the Unicode data.

• Automated HTTP Headers through wc.dll
  Web Connection now feeds standard Web Server headers for every request while running through the ISAPI extension. The ISAPI DLL now adds common Web Server headers as configured in the Web Server configuration. In IIS these include user configurable headers as well as the Web Server name and request date time stamps. The DLL now also adds the Content-Length on every request that doesn't explicitly provide it automatically. As before the DLL also adds a default content type header if none is provided at all. All header creation calls now are routed through the standard ServerSupportFunction() ISAPI API which provides better compatibility with non IIS Web Servers (see Apache support above).

• Several enhancements to wwIPStuff's Email handling
  wwIPStuff now adds the cExtraHeaders at the top of the email message which means that the extra headers take precedence over any default headers wwIPstuff adds later on. A new AddHeader() method has also been added to make it easier to add custom Headers to emails. This in turn means you can override wwIPStuff's default headers and should alleviate, in most cases, any restrictions on headers used that existed before. wwIPStuff now also handles return receipts with new lReturnReceipt property which sends a receipt to the sender. The cMailServer property now supports port numbers as part of the mail server address (mail.myserver.com:2525) which overrides the nPort property.

• Response.ExpandTemplate() now defaults to Request.GetPhysicalPath()
  The first parameter of Request.ExpandTemplate and Response.ExpandScript() now defaults to Request.GetPHysicalPath which looks to a file on disk that maps the current URL to the local disk.The physical path is a very common parameter choice and therefore makes a good default value.

• wc.dll Updates for handling long Server variables
  wc.dll previously used a fixed buffer size for retrieving server variables that conformed to common standards for lengths of various strings returned. However, many applications these days easily overwrite these limits. wc.dll has been adjusted for this so that now values of any length are accepted. This is especially important for Cookie Handling of extremely long cookies or multiple long cookies which could fail in previous versions.

• New WWC_EXTENDED_LOGGING_FORMAT #DEFINE in wconnect.h
  There's a new flag in wconnect.h that allows specifying additional information to be logged in the Web Connection Log file. The extended format logs POST data and the Browser string in addition to the script name, querystring and IP Address that was previously logged. This is primarily meant for improved debugging features and tracing of spam, or malicious access to the site. By logging POST data you can potentially get a better idea of what people are doing if you know there's a problem. Please be aware though that logging this additional data will result in potentially larger log files, so make sure you frequently adminster the file lest it get too large and fill up your disk.

• Installer and Wizards now set directory permissions automatically
  The Web Connection Wizards now set permissions on the any of the install directories automatically. Web directories are set with IUSR_ rights and the Web Connection temp directory selected is automatically set with read/write access rights for IUSR_. All permissions are set on private directories. The installer and Wizards now also create a all script maps as local scriptmaps rather than global scriptmaps. This should avoid one of the most frequent 'getting started' SNAFUs in Web Connection. This functionality is provided in the Setup, Create Project and Configure Server Wizard.

• Programmatic Server Configuration Docs updated
  I've updated the docs for programmatic Server Configuration due to many requests recently. This topic should point people who want to build automated Web Connection installs into the right direction. Web Connection includes all the functionality to fully self install including creating virtuals, script maps, setting directory permissions and registering COM servers and setting DCOM permissions automatically.

• Console.exe gets DCOM configuration command line options
  You can now execute CONSOLE.EXe with command line options to set DCOM impersonation and permissions for COM Servers. The new DCOMIMPERSONATION and DCOMPERMISSION options let you automate automate this process a bit easier.

• wwAPI CreateProcess and CreateProcessEx functions added
  We added API level CreateProcess functions that allow more control over executing external processes than the run command. The plain version supports executing another process, waiting for completion, hiding the window. The Ex version adds the ability to redirect output to a file which is very useful for console applications. Provided to reduce the 'flicker' of flashing command windows when running the various Web Connection Administrative routines (SetAcl, DCOMPermissions etc.).

Licensing

For current pricing for both developer and runtime licenses please check our product pricing page.

Single Developer License

Runtime and Additional Developer Licensing

Runtime licenses may also be applied against additional developers on a team with one license per developer required.

A runtime license allows distribution of a compiled Web Connection application and distribution of any of the binary files included with Web Connection. No portions of the Web Connection framework may be re-distributed as source code without a full developer license. Runtime applications can make use of any of the framework classes supplied by the Web Connection framework including the HTML rendering classes and support tools as long as distributed in compiled form (APP/EXE).

Applications built with a distribution license must add significant value and cannot be in competition with the Web Connection development product. The Message Board and Offline Reader applications of Web Connection are excluded from any runtime agreement and may not be re-distributed in volume. A separate license agreement and pricing applies to redistribution of the message board application.

You may modify the source code and visual appearance of the Visual FoxPro Web Connection framework. Regardless of any changes made to the framework itself, it remains copyright of West Wind Technologies. Modification of any non Visual FoxPro binary files is not allowed.

Warranty Disclaimer: No Warranty!

Upgrading from Version 4.0

Response.ExpandTemplate Eval Recursion no longer supported

<%= Version() %>

<%= lcInputValue %>

<%= MergeText(lcValue) %>

loEval = CREATE("wwEval")
loEval.lAllowEvalRecursion = .T.
lcResult = loEval.MergeText( FILE2VAR( Request.GetPhysicalPath() ) )
Response.Write(lcResult)

DEBUGMODE and Error Handling Changes

FUNCTION OnError(loException as Exception)
* ... your custom error code here
ENDFUNC

FUNCTION OnError(loException as Exception)

*** Shut down this request with an error page - SAFE MESSAGE (doesn't rely on any objects)
THIS.ErrorMsg("Application Error",;
   "An application error occurred while processing the current page. We apologize for the inconvenience. " + ;
   "The error has been logged and forwarded to the site administrator and we are working on fixing this problem as soon as we can.<p>" + ;
   "<p align='center'><table cellpadding='5' border='0' background='whitesmoke' width='550' " +;
   "style='font-size:10pt;border-collapse:collapse;border-width:2px;border-style:solid;border-color:navy'>" + CRLF +;
   "<tr><td colspan='2' class='gridheader' align='left' style='font-weight:bold;color:cornsilk;background:navy'>Error Information:</th></tr>" + CRLF +;
   "<tr><td align='right' width='150'>Error Message:</td><td>"+ loException.Message + "</td></tr>" + CRLF +;
   "<tr><td align='right'>Error Number:</td><td> " + TRANSFORM(loException.ErrorNo) + "</td></tr>" +  CRLF +;
   "<tr><td align='right'>Running Method:</td><td> " + loException.Procedure + "</td></tr>"+CRLF+;
   "<tr><td align='right'>Current Code:</td><td> "+ loException.LineContents + "</td></tr>"+CRLF+;
   "<tr><td align='right'>Current Code Line:</td><td> " + TRANSFORM( loException.LineNo) + "</td></tr>"+ crlf +;
   "<tr><td align='right'>Exception Handled by:</td><td>" + THIS.CLASS + ".OnError()</td></tr></table></p>")

*** Log the Request
IF TYPE("THIS.oServer")="O" AND !ISNULL(THIS.oServer)
   this.LogError(loException)
ENDIF

*** We've completely handled the error!
RETURN .T.
ENDFUNC

Change Process Class Process() methods to OnProcessInit()

1. wwProcess::Process() called
   
2. wwProcess::OnProcessInit() called
   
3. wwProcess::RouteRequest() called
   
4. wwProcess::OnProcessComplete() called
   
5. if an error occurs OnError is called (default implementation exists)
   

This behavior still exists, but the recommended hook point now is OnProcessInit().

Action Item: Rename Process() to OnProcessInit
In most cases you can simply rename your Process() method if you even have one to OnProcessInit() and you should be good to go. The only rare exception is if you need to create PRIVATE variables visible further down the call stack. For more info see the OnProcessInit() topic.

Action Item: Add PRIVATE defines at the top of the Process PRG file
If you use the new Wizards, Web Connection automatically generates a set of PRIVATE vars for the 'known' server objects like Request, Response, Server etc. at the top of the PRG file so that they are always visible. This makes it possible to make assignments to these classes at any time without worrying where you are in the FoxPro call stack.

LPARAMETER loServer
LOCAL loProcess
PRIVATE Request, Response, Server, Session, Process
STORE .null. TO Request, Response, Server, Session, Process

Using the new wwPageResponse Class

Response.AddCookie("TestCookie","MyValue","/wwstore")
Response.Headers.Add("Expiration","-1")
Response.AddForceReload()

Log and Session File Structure Updates

CREATE TABLE (THIS.cLogFile) FREE ;
     (    ;
     TIME        T ,;
     REQID       C(20),;
     Script      c(50) ,;
     QueryStr     M ,;
     REMOTEADDR  C(16) ,;
     Duration    N (5,2),;
     MemUsed    C (8) ,;
     ERROR        L ,;
     REQDATA     M,;
     Browser     M,;
     Respone    M )

CREATE TABLE [dbo].[wwrequestlog] (
   [time] [datetime] NOT NULL ,
   [reqid] [varchar] (20) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
   [script] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
   [querystr] [varchar] (254) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
   [duration] [numeric](7, 3) NOT NULL ,
   [memused] [char] (8) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
   [error] [bit] NOT NULL ,
   [reqdata] [text] COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
   [browser] [varchar] (156) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL 
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

CREATE TABLE ( THIS.cDataPath+THIS.cTableName ) FREE;
  (SESSIONID    C (14),;
   USERID      C (15),;
   FIRSTON     T ,;
   LASTON      T ,;
   VARS        M ,;
   BROWSER     M ,;
   IP          M ,;
   HITS         I )

CREATE TABLE [dbo].[wwsession] (
   [SessionID] [char] (14) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
   [UserId] [char] (15) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
   [firston] [datetime] NOT NULL ,
   [laston] [datetime] NOT NULL ,
   [vars] [text] COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
   [browser] [text] COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
   [ip] [text] COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
   [hits] [int] NOT NULL 
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

Acknowledgements

West Wind Most Valuable Professionals
We're acknowledging the support many of the people in our community have given back to others on the message board and around shows and other events. We here at West Wind Technologies and the community at large thanks these individuals by awarding MVP awards. To find out more visit the MVP site.

Randy Pearson
Randy Pearson of Cycla Corporation has been an extremely active member in the Web Connection user community to the point that many people visiting the message board think he's a West Wind Employee, which he is not. His valuable contributions and thoughtful comments and suggestions can also be found in many aspects of Web Connection and had an impact on many of the features found in the product. Finally, Randy was in charge of the Migration topics found in this help file along with with the Migration Tool utility to move 2.x projects to 3.x. Randy is also co-author of the WebRad Web Connection book.

Lauren Clarke
Lauren has become one of the top resources on the West Wind Message Board and has been a huge help in testing various new developments in Web Connection. He's also been instrumental in a number of ideas and tossing around brainstorming ideas for new features in the product.

Markus Egger
Markus (EPS Software) and I have been business and development partners for some years now and Markus although not directly involved in this product has always been a great help in bouncing ideas and concepts off of. Many of these have found their way into Web Connection.

James Murez
For all of his help related to pushing Web Connection harder as a product and improving visibility both for WWWC as well as Visual FoxPro in general. He's also been very actively testing several not so often used components of Web Connection and provides tons of feedback both on the documentation as well as on bugs/inconsistencies.

Erik Moore
Erik has worked on some technologies that have been silently integrated into Web Connection and he's had valuable feedback and discussions on several topics ranging from XML, SQL and ADO to the WinInet functionality in wwIPStuff.

Ken Levy
Ken's been big help in providing info on XML and a link to Microsoft for bugs and odd behaviors. Even though he cut his hair and doesn't work in the Fox team anymore, he's still one of us. Ken's been invaluable in helping isolate a number of bugs in the DHTML and XML object models that have been fixed since.

Microsoft Visual FoxPro Team
For the obvious: Providing us with a tool that is so powerful and lets us do things so easily that it simply boggles the mind that you can't do many things in other more visible Web products. I want to specifically thank Calvin Hsia for his help on many COM related issues on the road to providing the scalability in Web Connection. Also, Randy Brown for his support and help with various WinDNA related issues in VFP.

The frequent Message Board Crew
Yeah, that's all of you who frequent the message board and help out others or ask pointed questions about features and (gasp) bugs. Without this feedback this product would not evolve as much as it does.

I thank all of you for your help and support of making this product such a success in the FoxPro market!

+++ Rick ---

Rick Strahl
West Wind Technologies

Shareware version limitations and issues

CANCEL
CLEAR ALL
CLOSE ALL
RELEASE ALL
CLEAR PROGRAM
CLEAR
SET CLASSLIB TO
SET PROCEDURE TO

Recommended system downloads

http://office.microsoft.com/downloads/2002/owc10.aspx?HelpLCID=%HelpLang%1033

System, software and hosting requirements

If you plan on working with the Web Control Framework you'll want to use Visual Studio 2005 or the free Visual Web Developer 2005. Web Control Framework pages are plain text, but in order to get the full design experience a ASP.NET 2.0 compatible environment should be used. Click here for more info on whether you need Visual Studio.

Otherwise plain HTML editing tools like FrontPage and Dreamweaver can also be used for editing standard templates or even Web Control Framework templates (although you won't get full designer support for the controls). Of course you can edit any HTML templates including script and Web Control Framework templates with any text editor like Notepad or even the Visual FoxPro text editor.

Hardware

For development we recommend the max amount of memory you can afford as it will make your dev environment work more smoothly. With memory under $200 a gigabyte, it's easy to justify running with a 1 gigabyte of memory or more. Web development is very memory intensive especially if you use Visual Studio or Visual Web Developer. Also a fast machine won't hurt for development as you spend a lot of time flipping back and forth between different applications (VFP, Web Browser, HTML Development Tool etc.).

Web Hosting

The latter option tends to be the cheapest but unfortunately it's not likely that you will be able to use it for your Web Connection applications as a WWWC application requires binary executables which are usually not allowed by low end Web hosting services. However, there are special providers that specialize in hosting binary based application services and you may be able to talk to your ISP to get them to host you in this fashion.

Co-location lets you have your own machine or one provided by the ISP at their facility. The big advantage here is that you have full control over the server and can configure it as you choose. This usually includes the ability to add custom user accounts, set the security permissions for the server, add remote access services for pcAnyWhere or the like. It also makes sure that your application is the only one running on the server so that there's no interference or problems from these potentially dangerous applications running on the server at the same time. Co-location tends to be more pricey but for the piece of mind and control can save you lots of headaches. Pricing varies, but typically runs $200 a month and up.

Finally your company may already have an internal Internet connection and you can hook your server application into that network. In this situation you probably have to deal with your network administrator and any of the security policies configured for the company network. If your application is completely internal to your company (an Intranet) then a public Internet connection is not required. If your application is used both internally and externally (an Extranet) you will still need with the security issues of an open Internet connection through your IT staff.

For a list of providers that are Web Connection and Visual FoxPro friendly and provide related services, see http://www.west-wind.com/webconnection/webhosting.asp.

Documentation in Word Format

Documentation in Word Format

You can use Word to print the document into hard-copy. If you don't own Word 97 or Word 2000 or Word XP you can download the Word viewer from:

Word Viewer 2003

Note: The Word documentation may not be the very latest version as we only periodically update the Word docs. The Word file is also very large and you'll likely want to print only selected sections.

Web Connection WebLog

What is Web Connection

Another option for existing standalone applications is to build a distributed application that use the Web as a data transfer mechanism. If you go this route your UI code can potentially be reused using data pulled down from the server using tools in the wwIPStuff library. See the Online Distributed Application Demo for an idea of what you can do.

If you're new to the Web take a deep breath and read on - there's lots of info in this document that will clarify the way the Web works. Web Connection makes it easy to leverage your FoxPro skills. Once you understand the basic flow of information over the Web things will fall into place and allow you to be productive very quickly. You can crank out quality high performance applications without having to learn all of the Web technology up front and you'll learn about Web technology as you use Web Connection to build applications.

Roadmap to starting out with Web Connection

Setting up Web Connection

Checking out the demos

Go to the demo page

Most of the examples on the demo pages have links to show you the source code required to create that request by clicking on the [Show Code] link on the bottom of the page. At this time you can also start poking around in the code, making a few adjustments, maybe creating a new method and stepping through the code to get an idea what's involved in writing code for Web functionality.

There are two sets of samples: Core samples and Web Connection 5.0 samples, which sit on a separate page. To get started it may help to look at a few of the core samples first and see how Web Connection works in 'raw' code mode. Once you get the basic idea of how the Request and Response objects and the wwProcess class work, then you can take a look at the Web Control Framework samples, which are a little more complex and utilize a lot of the base functionality.

Take the Step By Step Guide

Digging a little deeper with the Framework Walkthrough

This step is optional, but if you want to get the most out of Web Connection this topic tree will be well worth the time to read easpecially as you get more experienced with Web Connection.

Use the Web Connection Management Console to create a new project

The new project will set up a new VFP application for you that you can start to write your own requests with. Now it's time to write access your business logic from within these Web requests and create some output to display back in the browser. As you start writing code you likely run into a few situations where you don't know how to do something. I suggest you go back to the demos and see if you can find something there that demonstrates what you're trying to do. Again, the message board is a great resource to post questions to if you get stuck or even if you want to bounce some ideas of other developers who have been down the path.

Use the Help File, Luke

The User Guide provides you with general discussion while the Class Reference (Framework Classes, Framework Support Classes, Utility Classes) provides detailed information on the actual classes in the framework. The class reference is laid out to provide an overview in the class header topic with examples and things to look out for with the actual class detail following class reference format showing the actual mechanics.

Configuration and Installation

You can also resort to the Management Console and the Server Configuration Wizard to help you with configuring your Web server with the appropriate virtual directories and script maps as well as copying and registering the Web Connection components for your application.

Setting Up Web Connection

wconnect
	classes*	-	VFP source and direct support files for the framework (required for development)
	html		-	HTML sample pages
	scripts*	-	The Web Connection ISAPI DLL and CGI executable file
	templates	-	The Management Console File templates
	tools		-	several useful support tools and classes
	wwdemo		-	VFP source for the demos that ship with WWWC
	wwThreads	-	VFP Source for the Message Board
	wwReader	-	VFP Source for the Message Board Offline Reader application
	WebControl	-	The Web Control Framework Samples
	WebLog		-	The WebLog sample application

In case of problems

Checking out the demos

Most of the examples on the demo pages have links to show you the source code required to create that request by clicking on the [Show Code] link on the bottom of the page. At this time you can also start poking around in the code, making a few adjustments, maybe creating a new method and stepping through the code to get an idea what's involved in writing code for Web functionality.

Unzipping the self extracting Zip file

Once unzipping is complete the program will automatically launch into the Web Connection Setup program. If this didn't occur automatically you can start the SETUP.EXE program from the Web Connection installation path. This program is required to configure Web Connection for your current Web server installation. Press F1 at any time for detailed instructions on the available options during the install process.

Understanding Directory Structures

The files unzipped are the Web Connection framework files and your starting point for the installation. Web Connection requires two sets of directories:

• Application directory
  This is the Web Connection install directory and can also include additional directories you set up or point your custom application to. This is where the VFP code runs from. THis path should be anywhere away from the Web directories.

• Web Directories
  This is where the Web (HTML, ISAPI, and script) files live. THis is typically a directory underneath the Web root of the Web server and is mapped as a virtual directory so you can access it through the Web like http://localhost/wconnect/ for example.
  

These two paths should be completely separate - the Web path underneath the Web root and the application path whereever you choose to install it. Under no circumstances should these point to the same locations.

Other than first installation you don't need to know how this works. Use the defaults and all of this will be set up for you. If you change the defaults and you don't know what these values mean you can run into trouble, but then the issues are described for the help topics for the Setup Wizard.

The Setup program

Go to Step 1

• Creates the wconnect script directory
  This directory contains the wc.dll ISAPI extension and also the default Admin page that allows you to administer the server remotely. This task can also be performed manually in the IIS Management Console by selecting the directory and creating a virtual.

• Configures the directory with Execute rights
  Execute rights are required in the script directory in order for wc.dll to be able to be executed directly or through script mapping. This can also be configured manually by selecting the directory in the IIS management console and clicking on the Execute rights (or selecting Script and Execute combo in IIS 5).

• Configures a temporary directory
  A temp directory for Web Connection message files are required when running file based messaging. In this mode message files are exchanged between the Web Server and the Visual FoxPro server. The directory holds these files. Directory must allow FULL access to the annonymous Web user account( IUSR_ <machinename> on IIS) or Everyone account.

• Creates scriptmap entries to allow direct execution of WC, WCS, FXP files
  Web Connection supports scripting as part of the framework so you can create HTML pages that contain embedded script or template code. These script maps point at wc.dll and let the framework parse the requests. You can also configure scriptmaps manually by selecting the Web root in the IIS Management Console, Home Directory, Configuration. The dialog allows you to add and remove script map extensions. Add WCS, WC, FXP and point them all at the full path of wc.dll installed in the Web directory (ie. after installation was complete).

• Copies Sample Files
  The setup program also copies the sample pages and images to the Web directory you created. The main files are default.htm which is the main demo page and admin.asp which is the administration page. admin.asp is important and should be copied for every copy of wc.dll.

• Sets up the configuration files
  Set up also configures wc.ini and your wcDemo.ini where wcDemo.ini will be you main application's configuration file which will vary by name depending on the project name. The most important settings in these files are the Path (wc.ini) and TempFilePath (wcDemo.ini) and Template (wc.ini and wcDemo.ini) which must match in both files so that file based messaging can find the message files.

These settings are the basic settings that must be performed for a Web Connection installation. The Setup program as well as the Web Connection Management Console New Project Wizard perform these task for you automatically, but it's important to understand what happens behind the scenes in case these settings do not work or are accidentally changed. If you or your administrator needs to know what happens with Microsoft Web servers or you want to manually configure settings check out the topic manually configuring Microsoft Web Server.

Step 1 - Picking the Web server

Next Step

The first step in configuring Web Connection is to pick the Web server to run on. This choice is very important as it will determine how to configure the server as well copying the appropriate files.

The server selections are straight forward. Web Connection should work fully with an ISAPI compatible Web Server and using file based operation with CGI based Web servers. It's highly recommended you use ISAPI for much improved performance. All Microsoft servers as well as Apache and Website are automatically configured - all other Web servers require manual configuration as outlined in the Setup Program step.

West Wind Web Connection works best Microsoft Internet Information Server 5 or later as well as Peer Web Server (also called Personal Web Server) on Windows NT Workstation. Other platforms and tools also work well, but the development of this product is focused on Internet Information Server and there may be features that don't fully work on other platforms. It's also highly recommended that you use Windows NT rather than Windows 98 to develop your application, both for stability of the dev environment as well as consistency between development and deployment environments.

If you're using IIS you can also select a Web site to install the Web Connection installation on. By default Web Connection uses the default Web site which should serve most situations. Advanced users or ISP's that have multiple sites can use the Advanced IIS Site Selection link to select a Web Site and domain to configure the site on:

The drop down will list all sites installed on the selected domain name or IP address.

Step 2 - Configuring the temp path

Next Step

When Web Connection runs in file based messaging mode it uses temporary files to pass messages between the Web server and the Visual FoxPro application server. These messages are picked up by the VFP server polling for the files in the temporary directory and it's important that both the ISAPI extension and the VFP server agree on this path. This option writes Path and TempFilePath values to wc.ini and wcDemo.ini (which is the demo application) respectively.

IMPORTANT

This directory must have FULL access for the SYSTEM and IUSR_ (on IIS) annonymous Web Server User Account. When a request comes in in file based messaging the Web server/wc.dll needs to create and write and read the temporary message files. This request runs under standard Web server security so this will typically be the IUSR_ account.

Step 3 - Configuring the virtual path

Next Step

Script File Path
You're asked to provide a physical disk location which can be anywhere. This should be a path that's part of the Web directory structure (ie. this is an HTML path not a Code path). The default will be the server's Web root plus wconnect and this is a consistent choice for this location.

Note
If you see 'Web Server not installed' in the script file path field, make sure that you have indeed selected the correct Web Server on the first page of the Wizard. If you are using IIS4 or 5 and you see this message, you can try explicitly selecting the Web site to install to on the first page by clicking on the Advanced tab and selecting the site.

Virtual Directory Name
This will be the virtual (logical) name for this directory in server relative terms. A virtual is similar to a drive mapping that logically describes an underlying path. It's highly recommended that you do not change this value from its wconnect default. If you do change this value the demos may not work since they use /wconnect as the server relative path to access the Web Connection DLL.

Step 4 - Finish and test the Server

Next Step

Important note for PWS on Windows 98
If you installed for Personal Web Server on a Windows 98 or 95 machine be sure to reboot your machine, since the registry settings made during install will not take until PWS is completely restarted. Rebooting is the only 'official' way to restart PWS, although you can also kill the process and then restart it.

Starting up the server

If you do this manually when you start up next time follow one of these steps:

• Use the WC Desktop Shortcut
  Web Connection creates a shortcut on your desktop to start Web Connection. I highly suggest you use the shortcut or if one wasn't created (if you don't have the Windows scripting host installed) that you create one manually as it sets the appropriate paths to find the support libraries. Create a shortcut to VFP and have it start out in the Web Connection startup directory.

  Note
  If you have VFP configured to start up in a specific directory in your VFP Tools|Options settings the shortcut will not do the trick. In that case follow the manual instructions for startup. You can verify your startup path by typing CD into the command window - it should display the Web Connection Install path.
  

• Manual Startup
  If the shortcut didn't make it or you're the kind of person that likes to type paths you can also do the manual steps:
  
  
  
  1. Start Visual FoxPro
     
  2. CD <WebConnectionInstallPath>
     
  3. DO .\classes\wconnect (Shareware version: DO WCONNECT)
     
  4. DO PATH WITH ".\classes"
     
  5. DO wcDemoMain
     
  
  

Once you do this the server form pops up:

Click on the Status button to see the status information of the server that should display some of the information that you specified during the Wizard operation:

You can make additional configuration changes on this status form later on as well as retrieve information about individual requests.

Accessing the Web Connection Demos

http://localhost/wconnect/default.htm

and access the Web Connection demo page. If this doesn't work please check the Troubleshooting section.

Scroll down to the first request Hello World with Web Connection.

If everything is working OK you should get a response page almost immediately that says Hello World from Visual FoxPro! followed by additional information about some of the server variables exposed by the server.

If this didn't work please see the setup troubleshooting topic.

Otherwise you're in business! Go ahead and browse around the demo page and check out some of the links. Note that most requests have a Show Code link on the bottom of the page that lets you quickly review the Visual FoxPro code that drives the request.

Back at the Web Connection Server

00:07:33   wwDemo~ShowImage  - 0.022
00:18:26   wwdemo~TestPage~&Name=Rick&Company=West+Wind  - 0.040

Each request that hits the server shows in the main window along with the time that it took to run. At the same time the request gets logged into a log file where you can review and summarize the incoming requests. You can access this log file from the admin page at http://localhost/wconnect/admin.asp and the Show Web Connection Request Log request.

The admin page allows a number of administrative tasks from server monitoring to setting configuration options remotely over the Web to changing operational modes of the server. It's a good idea to shortcut this page in your Favorites list.

Step 5 - Checking out the code

1. Shut down the Web Connection Server by clicking on the Exit button.
   
2. Open up wwDemo.prg with MODIFY COMMAND wwDemo.
   
3. wwDemo.prg contains a large class called wwDemo with methods for each of the request links from the Web page.
   
4. Find the ShowHours() method in the class (right click in the editor- Procedure|Function List and find wwDemo.ShowHours).
   
5. At the very top add SET STEP ON into the code.
   
6. Save the file.
   
7. Restart the server with DO WCDEMOMAIN.

8. Flip over the HTML Demo page
   
9. Find the Simple Data Query Example and enter B to search for and a date range that's reasonably recent.
   
10. Click on the Show Hours button
    

If you go back to Visual FoxPro now you should find the debugger popping up on the SET STEP code that we just inserted:

You can now happily step through the code line by and see the operation of each request as it happens. For example, you can now see the content of the request variables

lcOrigClient=Request.Form("Client")
lcDate1=Request.Form("StartDate")
lcDate2=Request.Form("EndDate")

being filled and the SQL WHERE clause being built and then rendering the code with ShowCursor().

As you just saw making a code change is very easy - you simply change the PRG file, save it and start up the server again. You don't need to recompile (although you could recompile the WCDEMO project everytime) and the changes take immediately.

Error Handling in Web Connection

o=CREATEOBJECT("NonExistingObject")

Guess what will happen here? The code will fail because this object doesn't exist and a VFP error occurs. VFP pops up an error dialog ontop of the editor with the code highlighted:

This is great for debugging - certainly beats typical COM debugging that doesn't allow you to debug a compiled object at runtime, right.

While this is nice for debugging if this occurs on your live Web site, this would be a problem though. I know you don't make coding mistakes ever <s>, but there are system circumstances or typos etc that do slip into production code. A stop error as we're seeing above would lock the Web Connection server dead in its tracks - it wouldn't be able to take any more requests until the dialog is closed.

In order to work around this Web Connection has a configuration setting that allows you to switch between debug and live modes. You can find this flag in WCONNECT.h:

#DEFINE DEBUGMODE      .T.

By default Web Connection ships with this flag set to .T. which makes errors basically stop on the offending line of code, since this is great for debugging. In order to switch this flag into deployment mode set the flag .F. and recompile your project. It's very important that you recompile the project completely with:

BUILD EXE <projname> FROM <projname> RECOMPILE

or by using the Recompile All option from the Build dialog.

Rerun the program now by running the EXE file:

DO WCDEMO

Now re-run the request. You'll find that Web Connection now handles the error and passes back an error page that describes the error on the Web page:

This is obviously much nicer than the server crashing and hanging situation we encountered before. What happens behind the scenes is that the Web Connection error methods kick in and generate this HTML output page. The page can be customized by overriding the wwProcess::ErrorMsg() method in your subclass of it. In fact you can also override the error behavior to perform other tasks on errors, but there's not a lot you can do but display some error info. Once the error page is generated the code returns back to the mainline and the error page is returned to the Web browser.

Note: The Shareware version is precompiled, so the #DEBUGMODE flag cannot be set and recompiled. The Shareware version will always stop on any VFP errors in your code.

Setup troubleshooting

Troubleshooting a Filebased Server Install

Is your Web Server working?
First of all make sure that you can indeed get to the Web Connection demo page by typing http://localhost/wconnect/default.htm (or use the IP address or machine name instead of localhost). If this doesn't work your Web server is not functioning correctly. Check your Web server install docs to get the server working first.

Temp Directory Permission
If you get an error that states that you don't have permissions for your temp directory immediately, make sure that the temp path you've chose supports FULL access for the IUSR_ anonymous Web account. wc.dll requires this in order to write temporary message files when running in file based messaging.

Is the Web Connection Server running?
Next, make sure that the Web Connection server is running in a Visual FoxPro session. The demos are set up to run file based and they require that the Web Connection server is manually started and running in the background. You can do so by starting Web Connection from the desktop or start menu shortcut and using the Web Connection menu to click on Web Connection Demo Server. See Step 4 of the Setup program for details.

Is the ISAPI DLL firing?
If the server is running and still no requests are hitting the server try the following URL:

http://localhost/wconnect/wc.dll?_maintain~ShowStatus

If this URL is not working there's a fundamental problem on the Web Server in accessing the DLL. Follow this link to Manual Server Configuration for more details.

It's still not working - now what?

Start by running your Web Connection Server with Do <yourAppMain.prg> and bring up the Status form as shown in the image below. Make sure that the startup path shown in the form matches your actual startup path - if for some reason it doesn't change it to the install directory and Save Settings.

Next bring up the Admin page for your the demo or your application by going to:

http://localhost/wconnect/admin.asp

(or go to your application's admin.asp page). Click on Show and Manage ISAPI settings. We can now compare settings between the Web Connection server and the wc.dll setting the Web Connection DLL is running.

Pay attention the Temp File path and Templates - they should match in both places. Case won't matter, but make sure they are otherwise the same. If they are not we need to sync them.

Changing the your server's settings
To make changes to the application's INI file simply change the value on the Status form and click the Save Server Settings button. When you exist the form these settings should be live. These settings are written into your application's ini file (<yourApp.ini or wcDemo.ini for the demo app).

[Main]
Tempfilepath=d:\temp\wc\
Template=WC_

Changing the wc.ini settings
To make changes to the Web Connection ISAPI INI file find wc.ini in your Web directory or the bin directory. Open the file with a text editor or the Visual FoxPro editor.

[wwcgi]
Path=d:\temp\wc\
Template=wc_

You'll want to change the Path and Template keys to match the value from the server.

Once this change has been made, go back to the ISAPI DLL Admin page and click on the Re-Read Configuration button, which loads the new settings. Verify that the settings are changed in the status display.

Authentication Dialog with NT and Windows 2000

Request does not support this method... Error Page