The StandardForm Class Template

The StandardForm Class Template

The StandardForm class template is shown in Figure 5.1.

Figure 5.1. The StandardForm class template.

I've included in the following snippet the code changes you'll need to make in order to use Internet support:

 -End- 

That's right. There aren't any code changes.

When we implemented SQL in Chapter 2, we created a cursor to hold the records that we bring back from SQL Server, or the records we add before sending them to SQL Server. These cursors are created in the forms' Load events, before going for data.

An Internet server works exactly the same way, except that now the program goes to the Internet server instead of to SQL Server for the data. It also goes to the Internet server for table structures because that's how cursors are built.

The Internet Server

First let's start building the Internet server. Web Connection installs in a directory structure named \wconnect , typically on the C: drive. If you installed it on another drive, substitute the correct drive letter wherever you see C: . Beneath \wconnect , there are six or seven directories depending on the version. I'm using Web Connection version 4.25 for this book, and at this time the directories are these:

 Classes Console FoxCentral HTML Scripts SoapSamples Templates Tools Wwdemo wwDevRegistry wwIPStuff_Samples wwReader wwThreads 

The shareware version doesn't install all of these; however, the important ones are Classes and wwDemo . The main directory contains about 15 files, but the one you'll want to look at is called WCDEMOMAIN.PRG . Open it up and take a look. About 225 lines down, you'll find a section that looks like Listing 5.2. (I added the last two lines.)

Listing 5.2. Modifying WCDEMOMAIN to Look for Our Web Server Process Class

 CASE lcParameter == "WWTHREADS"     DO wwThreads with THIS CASE lcParameter == "WWDEMO"    DO WWDEMO WITH THIS CASE lcParameter == "MYDATASERVER"    DO MYDATASERVER WITH THIS 

Web Connection organizes tasks into class libraries written as PRGs. There's a wwdemo.prg , a wwthreads.prg , and so forth. Each one of them has pretty much the same structure ”a DEFINE CLASS statement, then some housekeeping, and finally a bunch of FUNCTION s and PROCEDURE s.

You're required to write a process class that contains your own functions. wwDemo.PRG is a sample process class that you can use as a pattern.

How Web Connection works

When a program needs data, it sends an HTTP call to the server using a syntax like this:

http://www.lespinter.com/wconnect/wc.dll?wwdemo~Function1~Param1

which means ">go to www.lespinter.com , look in the wconnect virtual directory for a program called wc.dll , and use it to go to the wwdemo class library and run function1 using the value Param1 as a parameter."

In a client application, you use an instance of a class called WWIPSTUFF to make this call. Within that class, a function named HTTPGETEX with three parameters will send the URL and wait for the result. The first parameter is the URL string, the second parameter is the returned string, and the third parameter is a numeric value containing the number of characters in the returned string. It looks like Listing 5.3.

Listing 5.3. Attempting to Connect to the Server

 lnReturnCode = oIP.HTTPGetEx ( lcURL, lcReturnedString,lnStrLen) IF lnReturnCode <> 0    MessageBox ( [Error connecting to server], 16 )    RETURN ENDIF 

lcURL contains the URL, typically an IP address or Domain Name System (DNS) name (for example, 64.68.235.102 or www.lespinter.com ), the wconnect virtual directory name, the wc.dll reference ending with a question mark, the process class library name (a .prg file), a function name, and zero or more parameters. The class library, function name, and parameter names are separated by tildes, and are referred to positionally within the server program. That is, QueryString(1) is the class name, QueryString(2) is the function name, and QueryString(3) is the first parameter. The "http://" prefix is not included. Every single call you make to your Web Connection server will look like this.

The process class library is derived from Rick's wwProcess class. You start with a small skeleton and then add your own functions and procedures. wwDemo.PRG is a sample that ships with Web Connection to show you what a process class is.

How do you set up one of these class libraries? One way is to copy wwdemo.prg to another name, erase most of its contents, and start writing your own using the original wwdemo as a guide. But a utility program that comes with WebConnection will build your empty shell class library for you. Run console.exe and follow the instructions. I named mine MyDataServer, so pick a similarly descriptive name.

After you've added your class library, add two lines to wcDemoMain that direct URLs that reference your process class to the corresponding object by adding the two lines of code shown in Listing 5.2, and you're ready to start writing functions.

I've found two peculiarities in using Web Connection that might also give you a few anxious moments: First, before typing DO WCDEMOMAIN , you need to type the following in the command window:

 Set path to wwdemo;classes;tools 

Second, all of Web Connection is quite dependent on wconnect.h , an include file with named constants representing enums (lists of integer codes) used by various Windows components like the WinSock DLL. It has a specific location, and SET PATH doesn't help FoxPro find it. So if you move anything and then start getting messages that HTTP_ WHATEVER is undefined, try copying WCONNECT.H to wherever you're working. That usually does the trick.