Class wwServer

The Web Server Interface and Application Host

wwServer is your FoxPro application's entry point - when a Web request comes in wwServer is the first bit of FoxPro code that interacts it.

wwServer is:

  • The application entry point
  • A 'server' waiting for requests
  • Accepts COM or File based requests
  • Point of server and FoxPro configuration

Multiple Server Instances

You can run multiple wwServer instances simultaneously in separate processes. In File based operation multiple EXEs can be started, in COM the COM instance pool can be set to load multiple instances.

File based or COM based use the same Server

The server supports both file based and COM based through the same server implementation. In file based messaging the Web server request data is sent via message files that the server picks up and processes and then writes out results to files. In COM based messaging the Web Server directly instantiates and calls the wwServer class and Web Connection returns a string based HTTP response as a result.

For your code the mode should have no direct impact other than perhaps permissions and the execution environment in terms of location. Web Connection always sets the server's execution path to the EXE's startup folder.

Startup Sequence

It's useful to understand how the startup order of events works in Web Connection.

  • OnInit
    The initial server initialization. Fires once when the server is started, very early before Web Connection configures the Web Connection server. Use this method to set low level properties that are later used by Web Connection to configure the server. This includes paths to configuration files and any other global configuration settings. Typically you don't have to put code into this as Web Connection generates a default version of this method. - This method only fires once when the server starts up

  • Onload
    The initial server configuration. Fires once after the Web Connection server has gone through its internal configuration. Use OnLoad() to configure your own application startup requirements for things like setting paths, setting FoxPro environment settings, loading class libraries, loading static SQL connections and so on.

  • Process
    Fired on every incoming request from the Web Server. This generated method contains the routing logic that routes request to the appropriate wwProcess class that house your Web processing logic. This class contains logic that parses the URL and based on the URL parameters or script extension route the request to the wwProcess class. Typically you don't have to change code in this method unless you manually change your scriptmaps.

  • ProcessHit
    Process() is the application level entry point, but ProcessHit() is the low level entry point for the application. When requests come in ProcessHit() is the inital point of contact and the method gets passed the raw HTTP request data. The method processes this data into a wwRequest object that is user in later processing. This method is internal, but mentioned here in case you decide to step through the server code as this is the lowest level entry point for a Web Connection server request.

Think of OnInit() and OnLoad() as your one time configuration methods. Process() is a static handler for every request that comes into Web Connection. The only method you typically change and add code to is OnLoad() where you configure your application startup environment.

Use OnLoad() for Configuration

The main Web Connection start program contains a small bit of non-class FoxPro code that is used to bootstrap the Web Connection server when running in file mode. It may be tempting to put configuration code there, but you should not put configuration code into the startup code. When running under COM that code is not fired, so if you switch between COM and File based you won't get the same behavior.

Always use .OnLoad() to configure you Web Connection application to ensure that the startup code always runs.


When you create a subclass of wwServer you should implement the following methods:

  • OnInit()
  • OnLoad()

The code looks something like what's outlined below - this should change very little with a few adjustments for your server environment.

Class Members



The event is called when the server is released it's called explicitly but also from the destroy. If you have any references you've created that might be circular or otherwise need cleaning up it's recommended you override this method and clean up the code.

Make sure to call DODEFAULT() to call the base class code.







o.ErrorMsg(lcHeader, lcBody, lvHeader, lcStatus)


Called by the ISAPI extension to finalize the initialization process.

This method returns the current process's ID. It also doubles as a startup hook that is called when the server is created by the ISAPI DLL when running COM.

It also handles cascading the server windows.



Logs an exception into the error log stored in the database (typically in wwRequestLog in the app folder).



o.LogRequest(lcParameter,lcRemoteAddress, lnSeconds, llError)








Sends an admin email to the specified recipients.

This is the main method that is used to send system emails from Web Connection, and it is called for error handling operations and admin send operations. Forwarded to by wwProcess::SendAdminEmail() with the same signature.

o.SendAdminEmail(lcTitle, lcMessage, lcRecipients, lcSender, llHtml, llAsync, lcRefErrorMessage)


Loads the server form for display. The server form is a separate object that gets created by this method. Pass an optional parameter of .T. to release an already running form.

When the server starts it reads the ShowServerForm key from the startup ini file to determine whether to display the server form.



Shuts down the server in File Mode.

Internally issues a CLEAR EVENTS followed by QUIT. This method is internally called from Windows WM_CLOSE message calls initiated when FoxPro or your Application is closed from the Task bar, Close box or via 'Close' operations in Task Manager etc.



o.Trace(lcMessage, lcFileName)


This is the name of the INI file that the application will lookup to read configuration values from. This value is pre-set in the Initialization of the server, prior to accessing SetServerEnvironment. You can modify this value in SetServerEnvironment as needed. The value is then used by ReadConfiguration() to actually read the data from the INI file.


The application's name. This value typically will be the server's class name, which is used in the INI file as the root reference. Note this should be more of an ID type value rather than a descriptive name, although either will work.



In order to release a WWWC COM object from a visual form the request has to run over HTTP to release the server. When you click on the server's Exit button for example the code actually launches an HTTP session (via wwIPStuff) and then releases the server via this link.

Default: /wconnect/wc.dll/maintain?release


An error message that is sent when an error occurs in the server's error method. This value is valid only when wwServer::lError = .T.


Determines the filename where requests are logged to when lLogToFile is set to .T. Default file is RequestLog.dbf.


This property receives the HTTP output from your code when operating under COM. The wwProcess class handles assignment of the HTTP output to this property when the wwProcess object is released in its Destroy. For this reason, if you decide to write to this property it must occur outside of the process object.


The class that Web Connection creates when to do request processing. Keep in mind that this may vary depending on whether you use ASP or plain Web Connection processing.


This flag determines whether the component is running under Active Server Pages. If so the server changes its behavior to use a different request class and sets up the appropriate Request and Response objects that map to the ASP objects.


This flag determines whether the server is running under COM based messaging as opposed to file based processing.


Determines whether the server is running in DebugMode or 'release mode'. When this flag is set to .T. error handling is disabled and errors stop in code. When .F. errors are handled and managed to various handlers that by default display error messages.


Error flag set to .T. if a request fails. You can check cErrorMsg to see what error actually occurred.


Determines whether every Web request is logged to a request log file. Data is logged to the
file set in cLogFile.


Determines whether Web Connection tries to hide the VFP desktop and runs as a Desktop window application.


Flag that can be passed forward to a wwProcess object to determine whether to show the current request data at the end of the current request. Note that this flag is not automatically respected in wwProcess - it's only used as a 'global' guideline.


Determines whether the server form is displayed on the desktop.


Determines whether the server form displays status information.


When set causes the COM server to be run in VFP unattended mode (SYS(2335,0)) which prevents any user interface operation from firing. This will prevent accidental file open dialog boxes (which are not trappable) and generate errors for any modal UI operations (like an accidental MessageBox somewhere).


Flag that allows you to bypass TRY/CATCH error handling and instead implement your own Error() method on the Process class for error handling.


This property can be set to force Web Connection not to look in the registry for the startup path. This might be useful if you have multiple separate applications that use the same wwServer derived class names as the registry stores the wwServer classname as the registry key.


Determines how Web Control Framework Pages are parsed by Web Connection.


These modes determine how the ASP style (WCS scripts) scripting files are compiled and executed. This flag affects how Response.ExpandTemplate() works and how generic WCS scripts fired through the wwScriptMaps Process class operate.


Determines how pages are run when the WebControlFramework operates. Runs either in compiled mode or in 'always' parse mode.


A global wwCache instance that can be used to cache string data. Useful for caching responses for a period of time so it doesn't have to be re-generated.


Object that holds all of the configuration values stored in the YourApp.ini file.

The top level properties are the values from the [Main] section, each of the other sections are mapped to "oSectionName" properties beneath the oConfig.

In Process classes this object is available as: Config



Assembly: wwServer.prg

See also:

Class wwServer

© West Wind Technologies, 1996-2020 • Updated: 06/02/17
Comment or report problem with topic