WebHub Object Pascal Components

Fixed: problem with accented characters in email-merge v2.120
ONLY Delphi 2009 and Delphi 2010 had this problem.
WebHub v2.118 and v2.119 have a problem when sending some mail-merge emails: when there were accented characters involved and there was an attachment.
Reference: htem demo (whSendMail.dpr); retested fully with v2.123, all features confirmed ok.
Removed compiler warnings v2.120
Removed compiler warnings relating to string type conversions in Delphi 2010.
EMail attachments v2.121
Fixed issue where attachments from one email would be repeated with the next one if it had no attachments of its own.
Reference: whSendMail demo
New: SendA, Send8, SendStringA, SendMacroA v2.121
For D07 to D11: if you want to hard-code Ansi symbols in your PAS file and send them to WebHub pages, either convert them yourself using UTF8ToString, or call the "A" method. For example, instead of calling pWebApp.SendString('Fran├žais') (which will result in a garbage character), call pWebApp.SendStringA('Fran├žais').
For D12 to D14: you do not need to use the 'A' methods unless, for some reason, you have Ansi data handy, for example, from your database or COM interface.
If you need MORE "A" methods, please let us know.
The methods available in WebHub v2.121 are: pWebApp.Response.SendA, pWebApp.Response.Send8, pWebApp.SendStringA, pWebApp.SendMacroA.
Limited sharing of VAR files v2.121
If you compile all apps for a given server with the same version of Delphi: you are all set.
If you have a mixture of apps compiled in Unicode and non-Unicode versions of Delphi: possible problem. Specifically, you may have a problem if you use any characters above ASCII 127. That means, if you use only English, you are all set, but if you or your surfers prefer another lingvo such as French or Russian, then you will have a problem trying to share VAR files across those applications.
Combinations among Delphi 7 ... Delphi 2007 are not a problem because they all share the same definition of string.
Combinations among Delphi 2009 ... Delphi 2010 are also fine, for the same reason.
Decode panel now contains Count tag with diagnostics v2.121
You can enable the Decode panel using ZMAdmin. It is a standard GUI module.
At runtime, the new diagnostic panel appears under HTML > Decode > Count. To display the counts, click on the small thin panel above the memo, where it says Count of Pages, Droplets, Macros.
The diagnostics feature looks for discrepancies between the number of tags actually parsed versus those listed in your files, and it highlights any cases where you have opened tags but not closed them. In earlier versions of WebHub, it was permissable to open-but-not-close tags, but that is no longer supported. Two completely separate techniques are used: "webRead" which is the WebHub parser, and "regex" which is the ldiRegEx regular expression engine.
Source for the Decode panel ships to lib\whpanel_Decode.pas, in case you want to check the syntax of the regex patterns.
The FuzRegex utility uses exactly the same ldiRegEx code as this panel. This means that you can copy the patterns into FuzRegex and run them against your own files, to help look for specific issues.
If any errors are found, they will be listed after the basic counts, as "Diagnostics:".
Slight improvements to this panel are in v2.122 as well.
Decode panel: checks for chars > 127 in English projects v2.129
Warning for customers upgrading old WebHub projects: if you have content in .whteko files which was pasted in from Word or other sources likely to contain characters over ASCII 127, you will probably need to fix those characters. Common examples are the special quotation mark symbols that Word uses. To help you find those symbols, the Decode > Count panel now reviews all files (when Project.Lingvo is English, which is the default when Lingvo is blank, 'eng' or 'en'), and reports any characters that might need attention.
If you have encoded your .whteko files as UTF-8, with a BOM, and you want to use accented characters, etc., that is perfectly okay. The above warning is for people with content that unintentionally used > 127.
There are some great editors available, which can help you see your characters, and easily convert to and from UTF-8. Some recommendations: Dreamweaver, EditPlus, UniPad, TedNPad. Hint: use a font which can display a wide range of symbols. Use 'Lucida Sans Unicode' on Vista, Win2008 and Windows 7; use Code2000 on older versions of Windows.
Tag mismatch errors reported when app refreshes v2.122
Tag mismatch errors (in the *.whteko files) now lead to specific errors that you can view on the Html > Errors panel. Those errors will also be logged to disk if you have logging turned on.
Fix of INPUTSELECT with a macro containing Unicode v2.122
Reference: all WebHub demos, option page, list of human languages. That list was working in D07 but not in D14. Fixed now.
Removed from MultiTypeApp v2.123
The following were removed from MultiTypeApp.pas.
function EnableGUI: Boolean; deprecated; // use {M}Application.IsUIEnabled
procedure ForceEnableGUI; deprecated; // does nothing
procedure ForceForceGUI; deprecated; // does nothing
Recap of GUI units v2.128
Here is the list of GUI units, which are linked in when you build with a GUI and can be excluded completely for a non-GUI version of your program. These are listed as being in the D15 folder, and are available in all the other compiler folders, e.g. D07 for Delphi 2, as well.
  • MultiTypeAppGUI.pas
  • ucDlgsGUI
  • webBrowsGUI.pas
  • D15\apiCallGUI.dcu
  • D15\cgiServGUI.dcu
  • D15\htmlCoreGUI.dcu
  • D15\tpActionGUI.dcu
  • D15\tpApplicGUI.dcu
  • D15\tpListGUI.dcu
  • D15\updateOKGUI.dcu
  • D15\webBaseGUI.dcu
  • D15\webCollGUI.dcu
  • D15\webIListGUI.dcu
  • D15\webInfoUGUI.dcu
  • D15\webListGUI.dcu
  • D15\webSendGUI.dcu
  • D15\webSplatGUI.dcu
Html > Errors panel reports detail about serious syntax errors v2.123
When WHTEKO files are loaded (upon refresh), errors are listed on the Html > Errors panel. In v2.122 those errors reported line numbers, which corresponded to the internal representation of the file, not the line numbers as you would count them in an external editor. As of v2.123, the error also lists the name of the relevant droplet or page so that you can find the problem with a simple search.
This is important for large WHTEKO files where it is otherwise non-trivial to find syntax errors.
There is now a much clearer error for the mistake where a one-liner translation spans multiple lines. Within a whtranslations_tag, each line should be one definition and there should be no CRLFs within a definition. Use a whtranslation_tag if you need more than one line.
If you support MANY WebHub applications, you may find it helpful to syntax-check all of them at once with this utility project: webhubdemos\Source\DelphiApps\WHSyntaxTest\WHSyntaxTest.dpr. This is a very simplistic program which reports ALL on-refresh errors for ALL AppIDs defined in WHCentral.xml on the machine where it runs. It was created for WebHub v2.125 but you can compile it from the source and use it with older versions of WebHub if you wish.
Better loading of whtranslation tags v2.123
There had been a long-standing problem loading whtranslation tags if they were AFTER a whtranslations tag. The symptom had been that many erroneous errors were reported about the syntax of the subsequent whtranslation tag(s). That is now fixed.
Recap: recommend using Delphi 2009+ with v2.123+ for multi-lingvo web applications.
D07..D11 Latin-1 versus UTF-8, etc. v2.126
We have been back and forth on ideas for how best to support European customers who wish to keep using Delphi 7 a while longer.
Strongly recommend using Delphi 2009+ for any content outside of Latin-1 encoding.
Within the old non-unicode Delphi's: the default encoding is Ansi -- for stringvars and the content of strings that you Send to the output document. Your *.whteko files should still be in UTF-8. Your web pages will still end up encoded as UTF-8, and forms (if made with INPUTFORM) will be set to UTF-8 encoding. The difference is that as you manipulate any strings prior to sending them, e.g. with Copy, Length, Pos, PosCI, etc., you can assume that you are working with Ansi data -- by default.
The WebHub Demos do not use Ansi, internally. They use UTF-8 (for various reasons). This is accomplished, within Delphi 7..Delphi 2007, by setting a new boolean flag Very Early, e.g. before Application.Initialize. In the demos, the flag is set within the initialization section of one of the shared units. If you only have one project, set the flag in the DPR before Application.Initialize. To set the flag: whConst.isDelphi7UTF8 := True;.
To see a real-world WebHub app that includes complete Japanese, Russian and Chinese translations, please visit Earth Wave Records. This app was converted to D14 in July 2010.
To see a WebHub app which as of August 2010 is compiled with Delphi 7, visit my-next-home.de
If you have old WebHub apps that you want to have running with a new Hub and runner, you can force the encoding to Latin-1 by adding a header, example %=HEADER|Content-Type: text/html; charset=ISO-8859-1=%
If you have Ansi cookies (above 127), you should use new cookie names with UTF-8 (or Base64) values as soon as possible. If you have converted, but continue to have surfers coming in with those old Ansi cookies, consider using IIS to force the old cookie value to blank via iis. Otherwise, you are likely to crash the runner. Right now (September 2010), this is considered a true "corner case" and we are not planning to modify the runner.
SendA, Send8, etc. respect whConst.isDelphi7UTF8 v2.127
In htWebApp.pas, ProcessIncludeCommand respects the flag and can INCLUDE Ansi or UTF8 in all situations. The code was changed slightly compared to v2.126 but the result is the same.
In htmlBase, Send8 and SendA were changed to make them respect the flag.
In webSend, SendStringA, SendString8 (new), SendMacroA and SendMacro8 (new) are now all consistent and all respect the flag.
When does this matter: in Unicode Delphi, if you have content in a variable that is NOT a string, you should call these special methods to avoid compiler warnings or messy typecasts. In non-unicode Delphi, if you have set whConst.isDelphi7UTF8 one way and need to use the opposite technique for a subset of your work, you can. So, if you are working in Ansi in Delphi 7, but need to send out UTF8 occasionally, you would call Send8, SendString8 or SendMacro8 in those cases.
The recommendation remains, if you are working with content that is not Latin-1, you should use Delphi 2009 or higher.
INCLUDE command reports MISSING FILE if the file does not exist (v2.128).
No temporary file written to d:\ v2.123
In v2.121 - v2.122, there was a temporary file written to d:\ to test the parser. Please use v2.123+ to avoid having this file written when you refresh the app.
Default font supports Unicode v2.123
In TPack and WebHub, when the Font.Name is set, it is now set to Lucida Sans Unicode, which on recent operating systems yields a very complete set of symbols.
Reference Microsoft Typography Details for Lucida Sans Unicode Font
The font size has been set to 9 point everywhere, except TtpMemo uses 11 point and the Html > Errors listbox uses 10 point for readability.
On computers which do not have version 5 of this font, consider using the Code2000 font.
120 PixelsPerInch instead of 96 on *.DFM v2.126
Thanks to some excellent advice on an old JEDI forum, all the DFM files are now coded to use 120 pixels per inch. This still works with Delphi 7 and on Windows XP. And, it makes the forms look reasonable on Vista, Windows 7, Win2008 Server, etc.
New: pWebApp.Traduko v2.123
Example: ShowMessage(pWebApp.Traduko['~gallery']);
The Traduko function translates the given expression, for the current surfer, and defaults appropriately if there is no translation available for that lingvo.
The Traduko method is faster than calling pWebApp.Expand(MacroStart + '~gallery' + MacroEnd), which is what you could use in earlier versions of WebHub.
IBObjects supported from D12, D14 v2.125
The lib\whibds.pas unit now supports Delphi 2009, Delphi 2010, with IBObjects v4.8.6, v4.9.5 and v4.9.9
There had been no issue with support in D07..D11; was fine; still fine.
webRubi supports D12, D14, and Rubicon v3 v2.125
Minor changes to webRubi.pas make it work in Delphi 2009 and 2010. This was basically waiting for IBObject support and had been overlooked.
ucPipe fixed for Delphi-Unicode v2.125
This unit has been part of TPack for years and was just updated to work within Delphi 2009 and 2010. In some cases it had not been able to correctly return the output from a DOS console application.
OnEncodeResponse event v2.125
This event had been on the Response.Stream object, which did not work conveniently because the Stream is created and destroyed too often.
This event MIGHT not even be needed, now that the overall multi-lingvo situation is so much better.
While we are deciding on that point, it is available on the TwhApplication object.
AppProcessID support: fixedv2.126
Previously the ProcessID was not being appending to the AppID in the URL, as requested through the application-level config file. Fixed. Reference: webhub\lib\whcfg_App.pas
INCLUDE command: Ansi and UTF-8v2.126
The INCLUDE command can now send Ansi and/or UTF-8 data files as part of any WebHub page. Previously there were some restrictions in D07..D11 as to the encoding that was supported.
New property: pWebApp.Session.PriorCommand v2.127
This gives the command string from the prior page request. Note that Request.Referer can be different from the combination of PriorPageID and PriorCommand when the surfer moves around with the browser's back and forward buttons onto cached pages. PriorPageID and PriorCommand are always precisely the most recently-prior-requested dynamic pages.
Fixed htWebApp.pas to support AddAppEventMacroHandler v2.127
Error on line 139 fixed. You can easily patch this into prior versions if needed. In procedure AddAppBeforeLoadSessionHandler, change if not Assigned(AppEventMacroHandlers) to if not Assigned(AppBeforeLoadSessionHandlers).
This problem had meant that you could not call AddAppEventMacroHandler without causing an access violation during startup of the project.
Remote Refresh works with AutoPageHeader and Footer v2.129
Unit webSend.pas fixed.
The problem had been that sites that specified AutoPageHeader (or footer) to be something other than 'None' were unable to respond with more than a page header after doing a refresh of the app object.
This had been a problem for a long time; many thanks to Peter Hyde for testing this feature and providing a reproducible test case.
SendRedirection301 v2.129
This had been sending status code 301 out from the app, but the status code was changed to 302 by the runner. To resolve this, use a runner v2.129+.
New-Form Wizard, whsample_DMProj v2.129
If you have older WebHub projects and would like to add in a datamodule with TtpProject, you can use the wizard (File > New > Other > WebHub Form). Select whsample_DMProj.pas as the unit, COPY it into your project, and [x] Auto Create. You can then move old custom code out of your DPR and into the appropriate events on TtpProject.
If you need any help, please feel free to ask for tech support. We will gladly help you upgrade your projects.
JUMPs to #sections of exported pages v2.129
JUMP, GO, etc. have been fixed so that a double ## is avoided, during export, when jumping to a page with a #section command.
Reference Showcase demo; enter showcase, click Help, click Navigating, click Alphabetical. That should put you on page pgIndex and the page footer contains at least one link with a #section specifier. The Showcase demo can be exported; the following pages will generate static HTML files: pgIndex, pgHelp, pgNav.

The Hub, WebHubAdmin, ZMAdmin

Hub stops without errors v2.122
Some people were seeing errors when trying to stop the Hub service on some platforms, e.g. v2.116. Confirmed okay with v2.122.
Runtime Setup: default location for config changed v2.124
For ZaphodsMap root folder, from: $APPDATA\ZaphodsMap\ to D:\AppsData\ZaphodsMap\
For WebHub Configuration data, from: $APPDATA\WebHub\ to D:\AppsData\WebHub\
The expression '$APPDATA' was interpreted by the install system (NSIS) depending on the version of Windows, e.g. C:\Documents and Settings\All Users\Application Data\
The issue is that, due to Windows Junction Points, the logged-in user and the IIS worker process (the runner) may have completely different ideas of where "All Users\Application Data" actually exists on disk; and the runner may not have permission to get the files. The easily solution is to use any fixed path (no junction points!) that is outside of Windows' area, so you can easily grant permissions for the runner. Information about Windows Junction Points is available through google, and you may find this summary particularly useful.
This issue is critical when installing onto a new, clean machine, especially onto Vista, Windows 7 and Win2008. Use WebHub v2.124+ or be extra careful when answering the Setup questions about folder locations. There is a Quick Start Guide available for installation; request from Customer Service.
NB: this installer fix is the only change, from WebHub v2.123 to v2.124.
Delphi XE Supported v2.126
This is the first version of WebHub to support Delphi XE.
Setup of both Runtime and Components has been refactored v2.127
We have been transitioning EVERYTHING from a myriad of different version control systems into SubVersion. The installation procedure was one of the last pieces to move across.... now done. We can now build WebHub on the official "installation builder machine" as well as in a VirtualBox, and all the details are fully versioned.
If you notice any strange things during installation, please advise Tech Support asap. Thanks.
Fewer Access Violations on-exit; Restorer should work v2.129
There had been various intermittent on-exit access violations in WebHubAdmin, generally related to clicking around on the panels in such a way that the Restorer is triggered to write to the XML file.
All reproducible ones were fixed; you should be able to customize the size and location of WebHubAdmin and have that remembered for the next time you run it.
For the restorer to work on a WebHub application, the main form's Position must be poDesigned. This is now the case for whMain.pas.

WebHub Runners

Match runner, Hub and component version v2.121
Please install the matching WebHub Runtime when you upgrade your components, even if you are testing pre-release versions. The reason is that your app and the runner need to agree precisely on the string encoding, and as that very thing is changing (back and forth between Ansi, UTF-8 and RawByteString) right now, it is important that you install both at the same time.