What's New - September 2016


September 20, 2016

CHT HTML Document Builder

We're kind of excited about how this latest revision of a new application called CHT HTML Document Builder, aka HNDDOCUMENTBUILDER.APP, is turning out.

We've integrated CHT Code Documentation Editor so that users can be editing an XML document template file, and press the F5 Key, and a browser preview of the HTML version of the finished document appears or refreshes to reflect any changes you just made.

This is like an active HTML preview of what you're writing at the push of a button.

CHT Code Documentation Editor saves the document and signals CHT HTML Document Builder to regenerate the HTML document from the XML template file. At which point the previewer, CHT HTML Previewer Utility, aka HNDPREVIEWER.EXE, is started or refreshed in order to reflect any changes made by edits in the XML source file, since you last pressed F5.

For the fourth quarter build, on or about October 1, 2016, we'll be revising also the operation of HNDBULKMAILBATCHER.APP and HNDBULKNETMAILPROMO.APP to work the same way, providing an always-on active preview of your document as you write.

HNDBULKMAILBATCHER.APP and HNDBULKNETMAILPROMO.APP, as you know by now, are designed to help you create HTML mail with embedded style sheets that are email-client friendly. Both of these apps have built-in bulk mail sending and list management. These two apps use a common XML template file.

HNDDOCUMENTBUILDER.APP is also able to use this same template file but, is not intended to also send HTML email. It's primary purpose is to make for easy HTML web page creation, and easy HTML document creation of all kinds, even book chapters that can be displayed on a website or printed to PDF.

As time goes on we will expand upon the number of available built-in page designs, via alternate XML template files, that trigger the application to insert one of a selection of page layouts based upon the template file being used.

XML template files are simply tagged files containing section and head tags that act as guidelines for the various sections in your documents.

The first image below is a raw XML-Template file. This is generated by HNDDOCUMENTBUILDER.APP and consists of simple tags that indicate sections between which you type your page information.


This next image below, is the same file in the editor after we've begun typing information between the tags and adding simple HTML markup such as bold, italic and so on.


The following image, appears in the previewer when we push the F5 KEY in the editor.


Note that both the editor and previewer are on-screen at the same time so as you make changes a single click of the F5 key generates HTML from the XML template you're working with, and causes the previewer to refresh the finished document.

This is extremely productive and will be even more so when we begin, in subsequent versions, to introduce a wider variety of pre-designed page layouts from which to select.

That's all for now. Talk to you soon.

Gus Creces
The Clarion Handy Tools Page
September 20, 2016

September 1, 2016

Build Update 20C.03.00 Now Available (Part #1)

We've finished posting our third 20C Build update (i.e. 20C.03.00).

In this series of postings, we want to provide a brief overview of CHT's across-the-web installer technology as shipped with this 20C.03.00 update.

The underlying philosophy behind this recent work, is eCommerce.
The assumption is, you have developed something (software, documents, videos, etc.) which you wish to distribute and install onto windows machines. You are, Clarion developers, after all, and with Clarion you develop presently, only windows software.
Perhaps you are an independent developer, writing apps that you sell to a broad general market or vertical market. On the other hand you may be a corporate developer who has to deliver and update his work to a dedicated corporate group or division.
Regardless of your situation, we think with these installation servers and their matching installer applications included in this build you will find an eCommerce operating model that suits your needs for digital product distribution and documentation delivery.

In the next three posts, we will outline three pre-built servers and five matching pre-built installers that illustrate five different installation models ranging from free-distribution, to one-time installation, to updatable one-time installation, to renewable subscriptiion-model distribution.

This work is all done in APP format, via CHT Templates and Classes, in the standard manner that you're familiar with. We will introduce parallel XSA-PROJECT kits that provide this same work in a template-less manner, but with this build release we're providing Clarion applications, not Clarion projects.

The servers (pick one) are ready to run. You shouldn't have to do more than compile them, configure the IP and PORT, and run them on your Windows hardware, attached to a viable high-speed internet connection. Servers can be internet-public or internal-WAN only, depending on the IP address and port you ask them to monitor and deliver to.

The installers are ready to run and test also. Since the installer portion of your delivery system is going to be visible to your customers, obviously you'll want to make some cosmetic changes to suit your brand. The servers are IP pre-configured to deliver and test via IP ( which you'll recognize as localhost IP on port 88.

We suggest you test them by setting the matching server to the same IP:PORT and run this pair as often as it takes to understand what's going on before customizing the installer and setting up the server on your own delivery-hardware platform.

The IP:PORT are declared in the first few lines of the installer MAIN procedure as below:


All installers deliver an HZO container named hndxsainstallexample.hzo. To run your test you need to place this container into your server root. We've even provided the above named pre-built container in your install (find it in your /HNDAPPS/) directory. Then build your own and modify the Installer Template prompts to match names and titles etc. of what you're delivering.

Get the server-installer pair delivering reliably before you attempt to move the server to a new IP on other hardware. Only then, reconfigure the installer IP:PORT (and recompile). Get that working, and then modify the cosmetics, since that won't impact functionality.

In the next post, (part #2) we'll describe in text and pictures the operation of the first server-installer pair (HNDSLFSV.APP and HNDSETUPMKR.APP).

In the following post (part #3) we'll describe in text and pictures the operation of the second server-installer set: HNDSLFSVXSA.APP, HNDSETUPMKR_XSA_HC.APP and HNDSETUPMKR_XSA_LOOKUP.APP. This set provides two different installers which you can read about in that post.

In the post following that, (part #4) we'll describe in text and pictures the operation of the third server-installer set: HNDSLFSVXSA3PART.APP, HNDSETUPMKR_XSA3_HC.APP, HNDSETUPMKR_XSA3_LOOKUP.APP. This set provides two different installers also, which you can read about in that post.

Continued in Part #2 below.

Gus Creces
The Clarion Handy Tools Page
September 1, 2016

Build Update 20C.03.00 Now Available (Part #2)

This informataion deals with server app HNDSLFSV.APP and installer app HNDSETUPMKR.APP.

This installer/server pair performs an unsecured install, not protected by a password. Two other servers and four other installers provide various forms of install-protection either by password or by user identity. You can read about these other server/installer implementations in parts #3 and #4, below.

Now back to server app HNDSLFSV.APP and installer app HNDSETUPMKR.APP...

Compile both apps as-is and test locally in the following manner (server image next).


Set it up as pictured. The IP in use here is otherwise known as localhost, using port 88. (i.e. This IP is not available in the IP dropdown. You need to type it into the Server IP field followed by the tab key.

We've set this server's root directory to c:/web/. This just happens to be where we keep a local copy of our website, so there's plenty of stuff to display from there. We always develop our new and revised web pages locally and then post them up to our web server's root directory. Remember, this server also acts as a web page server, where your company advertizing and help pages can be placed.

What directory name you use here is up to you, the minimum you need to make the installer work is to place the hndxsainstallexample.hzo file in this directory, even if you don't plan to serve pages. The installer is configured to pick the file up from the server root, but it's easy in your own case to have the file picked up from a subdirectory of the root, if for no other reason than for organizational purposes.

(Installer Image Next):


This installer is encoded to the above localhost IP address and port. Use the IP:PORT settings as-is in order to test against the above server.

(Template Settings Images Next):



(Other images related to this installation):


From the construction of the installation container you can control where in the root expansion folder the contents of this container will be expanded. Since from our template setup the installation root folder is HPROP:HNDAPPSROOTC10 (in our case c:/clarion10/ that means the installation app HNDPREVIEWER.EXE is going to be expanded into c:/clarion10/hndapps/. This is also the case for the .CER file. It is designated in this case also for the same directory. (see next image).









Get the server working and delivering using the configured local IP:PORT before you change the location of the server and the IP:PORT embedded in the installer.

Continued in Part #3 below.

Gus Creces
The Clarion Handy Tools Page
September 1, 2016

Build Update 20C.03.00 Now Available (Part #3)

This discussion is about an installation server application called HNDSLFSVXSA.APP and two related installers called, HNDSETUPMKR_XSA_HC.APP and HNDSETUPMKR_XSA_LOOKUP.APP.

This server uses our new XSA security protocol, introduced last update with CHT-XSA-PROJECT-KIT-01. This security protocol passes a USERNAME:PASSWORD string to the server via the HTTP header. This string is encrypted by the client and decrypted by the server. Once the server decrypts this USERNAME:PASSWORD string it is compared against the USERNAME:PASSWORD configured on the server via the configuration dialog. (see next image)


If the USERNAME:PASSWORD string sent from the installer matches that which has been configured on the server, the installation is allowed to proceed. If it fails to match, the installation is terminated such that the installation container is never sent to the installer.

The two installers are configured identically internally as to what they're downloading and where it will be placed. The only difference is the "Authentication Model" switch configured on either installer. The _HC.APP (with "HC" for hard-coded) is configured as follows (see next image)


The second Authentication switch from the left, indicates that the USERNAME:PASSWORD string will be HARD CODED into the installer application. As you can see two fields have been provided on the template where these two values may be entered.

This HNDSETUPMKR_XSA_HC.APP application may be "turned off" or invalidated by changing the server-side USERNAME:PASSWORD configuration. This type of installer does not/can not distinguish between users. All users with an identical copy of this installer are "turned on" and "turned off" by the simple adjustment of the server-side security configuration.

The second installer for this server, HNDSETUPMKR_XSA_LOOKUP.APP refines this situation somewhat as it allows the installer user to change the USERNAME:PASSWORD string submitted to the server. This installer's "Authentication Model" settings are configured as follows (see next image).


The HNDSETUPMKR_XSA_LOOKUP.APP sets the third Authentication switch from the left. The USERNAME:PASSWORD strings are not hard, coded, they're looked up in the registry. If these do not exist in the registry, or if the values currently in the registry are incorrect and result in a failed connection to the server, this installer pops up a two-field dialog which gives the installer user a chance to add, or update the USERNAME:PASSWORD string required for a successful connection. (see next image)


If/when the server-manager changes the master USERNAME:PASSWORD on the server once again, all previously correctly configured versions of this HNDSETUPMKR_XSA_LOOKUP.APP installer are invalidated.

However, users who will continue to install, and who have renewed or paid for an update (whatever your policy dictates) can be re-connected by sending them the latest USERNAME:PASSWORD string. Hence the installer does not have to be replaced, just reconfigured on the installer-user-side.

While this second installer for server HNDSLFSVXSA.APP is more flexible, it still does not provide INDIVIDUAL USER control. When the server USERNAME:PASSWORD are changed, all installers are disconnected simultaneously. The "XSA_LOOKUP" installer version however, does provide an easy way for users to re-configure their installer to the latest server settings.

This server-installer combination is probably most useful when you're providing a common installer to employees of a company, all using the same set of your apps.

The configurable installer in this installer pair, can be a useful when rolling out a new update to groups of these employees at a time. First, change the server password to invalidate all installations and then send password updates only to that part of the employee group which must update first, and so on, in waves until all are again up to date.

Gus Creces
The Clarion Handy Tools Page
September 1, 2016

Build Update 20C.03.00 Now Available (Part #4)

This discussion involves an installation server called HNDSLFSVXSA3PART.APP and two related installers called, HNDSETUPMKR_XSA3_HC.APP and HNDSETUPMKR_XSA3_LOOKUP.APP.

This server provides individualized control of user-installs. The server uses a user-lookup table, which in this case is an SQLITE table called "Customer" located in a SQLite container file called HNDSLFSV.SQLITE. The "3PART" component of the server name has been added to remind you that this server's authentication method uses a 3-part login string consisting, of emailaddress,serialnumber,lastname.

While the 3 components in the login string do not really need to consist of an email address, serial number and last name, developers using other real-world values must make sure that at least, the first two of the 3 components in this string are unique to the individual.

Uniqueness is a requirement for correct identification at login, since a fetch on one or the other of these unique keys (or both) is used by the server to authorize or reject the installation.

We've provided, with this CHT update, a new maintenance app called HNDSLFCUS.APP which can be used to maintain the server-user data table. In the next image is a snapshot of the update form from that app to give you some insight into the user's configuration.


You can find this HNDSLFCUS.APP in your /HNDAPPS/ directory alongside the server and installer apps being discussed here.

More needs to be said about server-user configuration as the server can be made to react to the values in the user-account record, but this is not the place for a detailed discussion of that. Suffice to say, in the current set of installers, the server reacts to the "Locked" field set to "checked" by refusing installation as well as to the expiration date.

This single feature allows you to invalidate one user's installation privileges without affecting other users. This model is best suited for an across-the-web type of business where users do not necessarily belong to a group or company.

The first of two installers matching this HNDSLFSVXSA3PART.APP server, is an installer application called HNDSETUPMKR_XSA3_HC.APP. It hard-codes the 3-part login string on the template. The next image illustrates how that was accomplished.


The second of two installers matching this HNDSLFSVXSA3PART.APP server, is an app called HNDSETUPMKR_XSA3_LOOKUP.APP. It looks up the user's login string in the registry. The next image illustrates how that was accomplished on the template.


This installer looks up the 3-part login string in the user's registry. If not found or if found to be invalid, the installer pops up a dialog asking for the correct values to be entered. (see next image).


It's clear that this last server-installer pair most closely resembles CHT's subscription model, in that it allows the selling-devloper to control, the operation of each customer's installer separately and yet still provide everyone with the SAME INSTALLER exectuable.

Our subscription model really is no different than that of any other software vendor's "one year free upates with every purchase" model. If you provide a period of time after purchase for the user to update his/her software without charge, you're really in the subscription business, whether you like the term "subscription" or not. In which case, this server-installer authentication model is for you.

As we said at the outset, in POST #1, test the server-installer pair that's right for you, locally on your development machine first using the IP:PORT first, until you have it working correctly. We've supplied a copy of the HNDSFSV.SQLITE data base container file. And don't forget to look into HNDSLFCUS.APP to experiment with a user-configuration of your own.

Gus Creces
The Clarion Handy Tools Page
September 1, 2016

The Latest Docs

The latest template docs are here: CHT Template Docs

The latest demo application docs are here: CHT Application Docs

The latest utility application docs are here: CHT "Utility" App Docs

The latest "Batch Bot" application docs are here: CHT "Batch Bot" App Docs

The latest classes docs are here: CHT Classes Docs


Gus Creces
The Clarion Handy Tools Page
September 1, 2016