Some of the sample programs use a server-based control named WCCFinance.dll. This is included with the samples in the main download zip file - in the Chapter02\WCCGetPayments subdirectory. However the setup instructions given in Appendix A of the book omit the details about installing this control. Because the control does not run inside MTS, it is not automatically registered like the components within a package are when you install the package. Instead, you must register the component manually.
You can do this in the same way as described for the other Library components, because we've supplied a file named FinanceRegister.bat (and the corresponding file FinanceUnRegister.bat) that you can use to register the component on your server. You can also use the regsvr32 program instead, with: regsvr32.exe WCCFinance.dll.
Some of the samples use an unsigned client-side ActiveX control which is downloaded from our server and used to perform the finance payments calculation in the browser using scripting code. To be able to install and instantiate it you must have your browser set to 'Low' security the first time you view the pages that use this component.
The component (WCCFinance) is described in Chapter 2 of the book, and is written using Visual Basic version 5. For it to work you must have at least the runtime support files from VB5 installed on your machine. The 'Active Download' automatic installation does this automatically by installing the support files direct from Microsoft's Web site if you don't have them installed already.
Alternatively, you can download just the DLL and install it on your machine yourself using the regsvr32 program, with regsvr32.exe WCCFinance.dll, or by using the FinanceRegister.bat program described in the previous section.
In Chapter 3 of the book, we develop the existing WCCFinance component to work in MTS by adding some specific code and recompiling it. This replaces the existing Chapter 2 component. In order to allow both the Chapter 2 and Chapter 3 examples to be run live on our site, we have changed the project name of the second component, and compiled it with a different class ID. This allows both components to be installed simultaneously. The code that you can download from our site incorporates these changes. The second component is named WCCFinanceMTS.dll.
In Chapter 6 of the book, we develop a Web-based order monitoring component. This uses RDS within a scriptlet to build tables of confirmed and unconfirmed order details. Unfortunatley the code shown in the book omitted both the Server property setting code within the scriptlet, and the code that set this property in the main monitor page. The samples included in the download zip file, and those that run directly on this site, have the correct code. The changes are shown below.
In the file WCCTableMonitor.htm, we added:
Function public_put_Server (strServer)
'Purpose: set the ado data store server name
'Arguments: strServer. The server name to connect to
Document.All("adcO").Server = strServer
End Function
In the file WCCOrderMonitor.asp, we added:
tblUnconfirmed.Connect = sShowroom
tblUnconfirmed.Server = "http://<%=Request.ServerVariables("SERVER_NAME")%>"
tblUnconfirmed.SQL = "usp_OrdersUnconfirmed"
tblUnconfirmed.Start
tblConfirmed.Connect = sShowroom
tblConfirmed.Server = "http://<%=Request.ServerVariables("SERVER_NAME")%>"
tblConfirmed.SQL = "usp_OrdersConfirmed"
tblConfirmed.Start
This will only work, of course, if the data store is on the same machine as the ASP page. Instead, you can hard-code the Server name into the ASP script if required.
The code for handling the registry has changed slightly from that described in the book. One of the problems with using the Visual Basic registry routines (GetSetting and SaveSetting) is that they save the registry keys into the local user path (HKEY_CURRENT_USER\Software\VB and VBA Program Settings). But what happens if the components are installed in MTS and there is no user currently logged onto the server? Well the simple answer is that the local machine setting is used (HKEY_LOCAL_MACHINE), but using the VB routines there is no way to write to this area of the registry. That means we couldn't just move the existing keys from one area of the registry to another, as the setup routine would then not work.
So what we've done is introduce another registry routine that uses the Windows API functions directly to read and write to the appropriate place in the registry. This routine is called from the existing code in the same way as the GetSetting and SaveSetting routines were in the original version (as documented in the book). So there's not much change in the components, and it's pretty simple to understand. We've put the new code into the Common directory in the samples download zip file.