WebHub Release Notes for v2.058-v2.064
This file was last updated 13-Jun-2006

Skip to: WebHub Object Pascal Components    The Hub    WebHubAdmin    WebHubView    Runners   
 

Installing onto a computer that already has WebHub

Before upgrading an existing system from WebHub v2.051..v2.057 up to WebHub v2.058..v2.062
Do these steps ONCE before you run the WebHub Runtime installer
  1. Stop IIS (net stop w3svc)
  2. Stop the hub (net stop hub)
  3. Control Panel > System > Advanced > Environment Variables: make ZaphodsMap point only to a folder not a filename. End the path with a delimiter (backslash on Windows).
  4. Delete your WebHubInstallation-Config.xml file
  5. Delete WHAppRestorer.xml files if you have any (will be recreated for you with new syntax)
  6. Delete webhub\config\WHConfig.xml (will be recreated for you as WHMaster.xml with new syntax)
  7. Delete webhub\config\WHLicense.xml (will be recreated for you)
  8. Stop/restart the web server software (from control panel > services) or reboot. A reboot is not strictly needed, but it will help in many cases. (The problem is that Delphi applications inherit the previous environment variable values, so your change may not be visible to all programs without a reboot.)
  9. Then run "WebHub Runtime System v2.062 Setup.exe"
You do not need to repeat these steps once you have done them for a given machine and installed successfully. None of these steps are required on a new installation. None of these steps are required for a system running a version of WebHub prior to v2.051.
If you have problems during installation, look for a file installation.log in the same folder as the installer. If you see error messages about ZaphodsCentralKeybox.xml then the env var is not correct yet. Please consider rebooting, or send the installation.log to HREF tech support for interpretation!
The best first test is http://localhost/scripts/runisa.dll?echo because, when run on localhost, that will give you status information about your configuration. If there are any errors, they will be listed.
When upgrading any existing system to WebHub v2.062
These are the steps AFTER installing the RUNTIME.
  1. Stop the Hub. (it will have been started by the runtime installer)
  2. To convert existing INI settings to XML, use WHZMConverter (available to customers on FTP). The WHZMConverter wizard will tell you to exactly which files to backup, and which files are obsolete. The wizard will not touch any files until the last step. It will treat INI files as readonly; it only writes to XML files. Important tips:
    • For v2.062, focus on converting on restorer and hub settings. Do not worry about any app settings.
    • This means, tpack.ini, hub.ini (or hubmain.ini) and href.ini are the only files that you need to convert. You can ignore any errors reported in other files.
    • Please feel free to ask for advice regarding any errors that you do get.
    • When you get to the wizard page with all the checkboxes, uncheck the 3rd checkbox.(If you accidentally use the 3rd one, that is okay; you can ignore the resulting XML files because they will not be used.
    • You should be able to delete tpack.ini after converting. Do not delete any other ini files yet because parts of them are used by your WebHub applications in v2.062.
  3. Restart your web server software
  4. Test http://localhost/scripts/runisa.dll?echo
  5. Test http://localhost/scripts/runisa.dll?hubvers:pgversion (you should get an error message about the hub not running)
  6. Start the hub
  7. Test http://localhost/scripts/runisa.dll?hubvers:pgversion (you should see a normal reply)
  8. Install the components, rebuild your apps
  9. Delete windows\href.ini, windows\tpack.ini.
Sync version of Hub, WebHubView, WebHubAdmin, runner and components v2.059
We strongly advise that you use the same version of all aspects of WebHub once you get to v2.059.
The fine print: WebHub EXEs built with components v2.050- are compatible with runtime v2.059+. WebHub EXEs built with components v2.051...v2.057 are generally NOT compatible with WebHub v2.059+. The reason behind this has to do with the ZaphodsMap subsystem, which is used by the TPack Restorer component as of v2.051. If you do not use the standard WebHub forms (i.e. do not use the Restorer unit anywhere in your project), then your WebHub EXEs will be compatible with runtime v2.059+.
Your patience is very much appreciated; we are trying to keep rules like this to an absolute minimum.

WebHub Object Pascal Components

Warning: bug in this build v2.064
JUMPs (and other generated links) between 2 different AppIDs yield the wrong result in WebHub v2.064, if the application handle was in use.
In particular, the links did not include a - before the AppID, and therefore, the surfer was routed back to the current AppID.
Resolved in WebHub v2.088
Developers: check your env path v2.051...v2.059
If you have any trouble loading the WebHub packages into Delphi, exit Delphi then check your Control Panel > System > Advanced > Environment Variables > Path setting for your user account.
The path should include webhub\pkgD06 (or pkgD07, pkgD09, pkgD10 as appropriate for your compiler).
Having this on the path enables Delphi to find and load your WebHub packages, and enables you to keep the WebHub packages out of windows\system32 and separate from any other libraries in the Borland...Projects...bpl folder.
The more logins you may have on a given development computer, the more important this is.
The installer takes care of this in v2.060.
Building with Delphi 7 update 1 v2.058
As of 23-May-2006, the WebHub Components for Delphi 7 are being built with Borland's update 1.1. You may need to install the same update, if you have not already done so.
To check whether you have already patched your copy of Delphi, look at Help > About. It should say Version 7.0 (Build 8.1).
Unit whRegisW is obsolete v2.059
This unit was used to write to the registry and is no longer required by any part of WebHub.
WebHub App System Messages significantly improved v2.059
The WHSystemMessages.xml file should point to the location of your desired system message files.
By default, the messages will be taken from files in webhub\config\sysmsgs\.
You may now customize the system messages by EXE, by domain, and by AppID. Instructions are summarized below.
If you have a customized main form (not whMain.pas) v2.059
... and you have a Restorer component on that form, you should consider adding a protected .Loaded method to your main form. Use the code in whMain.pas as your example. The more WebHub instances you run on a given computer, the more important this is (if you care about avoiding the creation of lots of AppRestorer.xml files).
Essentially, you can now control where the restorer values are saved. Previously, they were saved to TPACK.INI in the Windows folder, or to HREF.INI, or to your web application INI file.
We recommend that you either use the same value as in whMain.pas, or come up with your own standard for Branch and KeyGroup for your own applications. Either is fine. This is just a reminder that you should make a decision.
Delphi Help menu fix v2.060
In v2.059, the Delphi help menu wanted to link to webhub.hlp. This was due to the tpMenu and webMenu units being included in the WebHub packages.
The issue has been fixed within TtpMenu and those units have been removed from the WebHub packages.
WebInfo.PickSetupID is obsolete v2.061
This verb is no longer supported.
Please see the context feature of ZaphodsMap, which replaces SetupID.
Code ported and moved out of ucWinAPI v2.061
The following has been ported and moved out of ucWinAPI:
Issue with COM resolved v2.062
There was a problem with WebHub EXEs with TWebCommandLine.SyncMode set to something other than the default (SyncCall). The symptom was that after some hours or days, the WebHub EXE would disconnect from the hub and would only reconnect if a message were sent to the app, e.g. user would mouse-over the tray icon.
Runner name forcing AppID: fixed v2.062
The feature where the use of a particular runner will always force a certain AppID is now working. It was definitely not working in v2.061, and possibly for quite some time before that.
As of v2.062, this feature is configured through the WHMaster.xml file, under RunnerMapping.
NativeXml interface v2.064
The file webhub\lib\NativeXml.int provides the interface to the TNativeXml component used throughout ZaphodsMap and other parts of WebHub.
The full source is available from the author.
This XML component compiles in Delphi for win32, Delphi for .Net and Kylix.
Delete key in WHTEKO editor v2.064
In v2.063, the [Delete] key deleted nothing when nothing was selected. Now it deletes a single character (as is normal in Windows applications).
brwsrcap.ini is obsolete v2.064
Delete this file if all your apps are WebHub v2.064+.
(top)

The Hub, WebHubAdmin, WebHubView

Hub v2.064 uses cv003 with WHMaster.xml v2.064
Here are the keys that were used to look up configuration values.
const
  cWebHubKeyGroupName = 'WebHub';
  cWebHubMasterKeyName = 'Master';
  cWebHubCentralRootName = 'MasterConfiguration';
  cWebAppConfigRootName = 'WebApplicationConfiguration';
  cWebHubInstallKeyName = 'Install';
  cWebHubInstallConfigRootName = 'InstallationConfiguration';
  cWebHubLicenseKeyName = 'License';
  cWebHubLicenseConfigRootName = 'WebHubLicense';
Nonetheless, the WebHub application loaded its configuration from an INI file, and the location of that INI file was defined in the hub.ini file.
This was a hybrid version, where the Hub was using XML and the App was still using INI files.
Hub System Messages significantly improved v2.059
The WHSystemMessages.xml file should point to the location of your desired system message files.
By default, the messages will be taken from files in webhub\config\sysmsgs\.
See below for info on how to customize the messages.
WebHubAdmin: error handler added v2.058
WebHubAdmin is now being compiled with EurekaLog exception handling. If an exception is raised, you will have the opportunity to describe the preceeding actions and to send the full report to HREF's technical support department.
To help us, please checkmark [x] Send via Internet. This will cause the relevant .ELF file to be emailed to techsupport at href.com.
The report will include information about your computer operating system, loaded DLLs, CPU status and a partial memory dump. If you would like to preview the ELF file before transmitting it, please either contact HREF support for a copy of the viewer, or download the trial package from eurekalog.com because it includes the viewer.
NTDLL errors in WebHubAdmin fixed v2.059
Earlier versions of WebHubAdmin gave NTDLL errors when the program started, and when the user navigated to some panels. Those errors have been fixed.
License details loaded from WHLicense.xml v2.061
The Hub and components load your license details from the WHLicense.xml file. Earlier versions of WebHub loaded the license details from the registry.
The default location for the WHLicense.xml file is under Documents and Settings, All Users, Application Data, HREFTools, WebHub.
This registry key is obsolete and may be deleted *after* running the Runtime Setup program: \HKEY_LOCAL_MACHINE\SOFTWARE\HREF Tools\WebHub\License.
Hub settings loaded from XML not INI v2.061
The following settings are now loaded from WHMaster.XML
If you have already run WHZMConverter and you want to simplify your copy of hub.ini, and you have upgraded all WebHub EXEs to be used on the given computer, you may delete these settings.
Sessions panel moved from WebHubAdmin to WebHubView v2.062
The reason for the move is that we will be replacing WebHubAdmin with a complete new utility for maintaining configuration settings under ZaphodsMap, and it seemed to make more sense to have "Sessions" (which are dynamic) visible from the viewer (which already responds to changes in real time).
Hub no longer responds to /? nor /Help command line v2.064
 
 
(top)  

Runners

Runner System Messages in new location v2.059
The WHSystemMessages.xml file should point to the location of your desired system message files. By default, the messages will be taken from files in webhub\config\sysmsgs\.
See below for info on how to customize the messages.
Obsolete registry key v2.058
This registry key, and everything under it, is obsolete: HKEY_LOCALMACHINE\SOFTWARE\HREF Tools\WebHub\Runner Please delete it from existing systems.

Installation Program

ZaphodsMap expects folder root v2.058
Now the ZaphodsMap environment variable is expected to point to a folder, e.g. d:\AppsData\ZaphodsMap\.
WebHub v2.059 uses ZaphodsMap v1.017. WebHub v2.060 uses ZaphodsMap v2.018. WebHub v2.062 uses ZaphodsMap v2.019.
WHLicense.xml uses XSD v2.063
The installer is supposed to create a WHLicense file for you, and that license file is supposed to reference an XSD for structure. In v2.062, the WHLicense was created without the XSD reference.
WHMaster.xml has AppPath variable adjusted v2.063
The default WHmaster.xml file is supposed to have a variable named AppPath and that is supposed to be set to point to your installation folder. In v2.062, the variable was not adjusted during installation.
WHSystemMessages.xml has correct SysMsgRoot variable v2.064
The SysMsgRoot variable is supposed to point to the webhub\config\sysmsgs\ folder. In v2.063 it was pointing to the webhub\config folder and therefore would not work.
ZaphodsMap env var should have trailing path delimiter v2.064
In v2.063, if you did not have a trailing path delimiter on your ZaphodsMap environment variable, then your installation configuration file would end up in the wrong folder. This is now fixed.
Nonetheless, you *should* have a trailing path delimiter.

Customizing WebHub System Messages

Explanation of system message names
The following refers to webhub\config\WHSystemMessages.xml v2.061
Messages given by the runner
Hub
Components
Situations that can arise within Hub.exe or your WebHub EXEs
Simplest Approach
Copy the webhub\config\sysmsgs\ files to another folder, ideally one that is outside the webhub directory tree. For this example, imagine the target folder is c:\NewSysMsgs\.
Edit the webhub\config\WHystemMessages.xml file. Find the Variables section. Change the variable named SysMsgRoot to have a value of c:\NewSysMsgs\.
One option at this point is to simply modify the contents of the c:\NewSysMsgs\*.whmsg files -- this is a perfect solution for a production server with one WebHub application, running on one domain name. For other options, keep reading...
To use a static html page
Imagine that you want to customize the look of the HubNotFound message. If the hub is not running, you want to display http://www.href.com/HubNotRunning.html
In the WHSystemMessages.xml file, edit the HubNotFound line and set the value to the URL instead of to a filename.
Example 1: <HubNotFound AppID="" value="http://www.href.com/HubNotRunning.html" />.
The URL can be relative to the current domain. If you support multiple domain names on the same web server machine, you might want to omit the domain name as shown in the next example:
Example 2: <HubNotFound AppID="" value="/HubNotRunning.html" />.
Stop/restart the web server software to make the runner notice the changed configuration.
To use a specific .whmsg file for a given AppID
These ideas apply if your production server runs more than one AppID.
Imagine that you want to customize the look of the NoSuchApp message.
In the WHSystemMessages.xml file, copy the NoSuchApp line to the clipboard, and then duplicate it within the XML file (just below the original). Fill in your AppID in lowercase.
Example 1: <NoSuchApp AppID="demos" value="{SysMsgRoot}nosuchapp-demos.whmsg" />.
You may point to any filename with a .whmsg extension, in any folder. You do not have to use the {SysMsgRoot} variable.
Example 2: <NoSuchApp AppID="demos" value="c:\path\demosnotrunning.whmsg" />.
Stop/restart the hub service to make it notice the changed configuration.
To use a specific set of messages for a given runner or WebHub EXE (Advanced)
If the above ideas do not yet provide enough flexibility, there is a final technique to which you may avail yourself.
This ZaphodsMap configuration technique is called "using a local keybox to override the branch keybox." The branch keybox is ZaphodsMap\HREFTools\WebHub\cv002\ZMKeybox.xml.
Imagine you have two runners on your server, isapi01/runisa.dll and isapi02/runisa.dll. It is essential that two separate folders be used. The runner filenames are arbitrary.
Copy the branch keybox file to the isapi01 folder.
Edit isapi01\ZMKeybox.xml as desired for the first folder situation. Only the entries under ConnectionLayer are relevant to the runner.
Copy the branch keybox file to the isapi02 folder.
Edit isapi02\ZMKeybox.xml as desired for the second folder situation.
Stop/restart the web server software.
The same approach applies to customizing messages based on WebHub EXE, as long as each EXE is in its own folder. (i.e. copy the branch keybox to the same folder as the EXE, then customize it.
Syntax within .whmsg files
The .whmsg files are essentially HTML files. A very short list of macros is expanded within .whmsg files, and the list depends on which part of the system is generating the message.
In .whmsg files, the text-substitution macro keywords must be UPPERCASE and surrounded by parentils.
The runner is able to expand the following macros (case sensitive, surrounded by parentils) when they are contained in a .whmsg file: WHERE, TIMEOUT, QUERYSTRING, APPID, APPINSTID, PAGEID, SESSION, COMMAND.
The WebHub Components are able to expand the same list, but not TIMEOUT.
The Hub is able to expand the same list, but not TIMEOUT.
Obsolete files v2.058
These files are obsolete and may be deleted from your system once you start using runisa.dll v2.058+
If you have any other .txt or .htm files in the sysmsgs folder, you may delete those once you start using Hub and WebHub EXEs v2.059+.
 
 
(top)

FYI: Valid DTDs on w3.org
FYI: The Firebird Book: A Reference for Database Developers, by Helen Borrie.
FYI: Reasonable source for Kylix licenses: Kylix 3 Pro
Copyright © 2006 HREF Tools Corp. All Rights Reserved. TPACK and STREAMCATCHER are registered trademarks of HREF Tools Corp.