Clarion Handy Tools

News - October 2017

October 13, 2017
Installing Our SSL Server Certificate
For Full HTTPS Access

We've worked out a methodology using OPENSSL to make self-created server SSL certificates free of charge, instead of paying $100-300 per FQDN (Fully qualified domain name) from some certificate mill. And we're planning on creating an app like HNDSIGN.APP to easily create server certificates as readily as you now can produce self-created code-signing certificates.

For background on using HNDSIGN.EXE watch two short videos on that topic by selecting them from our CHT VIDEO PAGE.

The international internet governing body, has made some specification changes that come into effect end of this month (Oct, 2017) which change considerably how these certificates work. And it will invalidate the wild card SSL certificate we're presently using with "".

In the past, one could create a certificate with "wild card" access so that all versions of a domain root name would qualify under that name. For example, we could create a certificate for "" and all versions of that name, for example,,,, would pass as valid.

The new regulations require a certificate to use what is known as an FQDN. This Fully Qualified Domain Name requirement means we have to spell out the full name, for example: "" not just the domain name root "".

As we mentioned at the beginning of this post, we've worked out a methodology, using the OPENSSL tool set, to create these newer FQDN certificates for use with any and all CHT servers. This will make it easy for you to run your CHT servers fully HTTPS encrypted and protected with SSL protection.

Since we're spending a good deal of time and effort to make the CHT tool kit a viable entity in the mobile and e-commerce spaces, we've installed one of these new certificates for the following FQDN servers: "", "", "", "" with other FQDN's to come as needed.

These self-created server certificates work the same way that our self-created code-signing certificates work, in that it requires the "public key" portion of that certificate to be installed on the machine accessing the FQDN site.

Next Time You Update CHT

Next time you update CHT, we'll have WebupdaterC10 install our new FQDN SSL certificate to your machine, the same way that we now install our Code-Signing certificate to your machine. That requires you to do nothing special, just a standard CHT update. And of course, by now you're all running our WebupdaterC10 "As Administrator" aren't you? Sure you are.

Installing The Certificate Manually, Right Now

In the meantime, if anyone would like to test this new FQDN certficate by manually installing it right away, the following set of images provide a complete set of instructions on how to perform a manual certificate installation using built-in Windows tools like CERTMGR.EXE. You can pick up the certificate packed in a .ZIP file (i.e. CHTSERVERCERT.ZIP) from our installation server which you can access here: CHT Installation Server.

By the way, we don't expect that the certificate creation application mentioned above will be ready by Oct 22, 2017 when build 21D.00.00 is to be released, but it will be be completed by Dec, 2017, along with a video, like the code-sign videos linked above.

Installing CHT's HTTPS-SSL Certificate Manually
Using Pictures














October 3, 2017
Universal Mobile Device Data Server
Receipts Procedure Added

We've modified the new server demo we recently created, called by adding a receipts procedure.

The Subscribers browse now links by a click on any name to a new UCR$ procedure that creates a sample payment receipt. That looks like this:


Four UCR$ Procedures Now In Use

The application presently implements four server-side procedures which may be accessed from any HTML page using what we call a UCR$ request, which is an acronym for (U)ser (C)ustom (R)equest, a term we've coined and attributed to user-customized remote procedures.

The following is a screen snap from that application:


Example Remote Procedure Call

Below is an example UCR$ call, that returns a receipt for a user identified by id number parameter 85727344.


The data comes back packaged as a complete pre-designed web page named:


Using CHTSNAPEDIT.EXE + HNDPREVIEWER.EXE we created an XML design template that contains the receipt design. That receipt design file is called 000serversidereceipt.xml.

Our server-side UCR$ procedure opens a copy of that receipts file, inserts request data into the tagged area between <MessageArea1A> and </MessageArea1A> and sends the file through a procedure in the server called:


Inside this "AutoGen" procedure, named above, the XML file now containing data tagged with HTML table tags is processed into viable HTML that will display in any HTML5-capable browser. As soon as the finished HTML file is fully-generated, it is returned to the requesting browser by the server using a server internal procedure called SendFileThread().

Changing the design of any web page or web form becomes then, only a matter of tweaking the CHT XML template file into which the server inserts data. Thus, when the data fields being displayed don't need changing or expansion, the page design can be changed by merely giving the server a different CHT XML design template on which to build the page.

A Look Inside The Server's UCR$ Procedure

When a request is formatted with the UCR$= tag as shown above, it is routed by the server into a server function area called: ProcessUserCustomRequest().

Inside this procedure the UCR$= command to the right of the equal sign, is intercepted and the user's code is executed. CHT calls these User Custom Requests, for a good reason, since a UCR$ request command can be anything the user/developer requires to communicate into his/her own server.

The command after the UCR$= is just a convenient way of routing into a back end procedure, like the four UCR$ procedures pictured above.

Below, is an illustration from inside the procedure, where some work is performed, a file is generated, after which the file is sent back to the calling browser.


More will be said about server method ProcessUserCustomRequest() in our next posting.

Now Point your Phones at One of These Addresses

Note that "PDE" in the first web address, below, is an acronym for Phone Does Everything. Which is appropriate for what we're trying to achieve here!

To run a test, point your phones at one or both of these addresses. Each resolves to a different server instance of the same, listening to a different IP and PORT. (HTTPS-SSL) (HTTPS-SSL)

October 2, 2017
Point Your Phones at These Addresses
Universal Mobile Device Data Server

The two links provided below, at the bottom of this dated section, point to an entry page that calls some remote procedures on a new server demo we recently created, called This is a demonstration server from which we are serving up example browses read from SQLITE data tables located in sample data base HNDSLFSVCUS.SQLITE, attached to this server and converted into "Flex-Port" HTML pages using a CHT XML2HTML template called 000newslinkslist.xml.

This demo was created by loading into the Clarion 10 IDE and saving it back under the new name, and by adding a dictionary hndslfsv.dct to that, into which we added some new tables, for example: NEWSLINKSLIST and SUBSCRIBERS.

NEWSLINKSLIST is an SQLITE table that we're presently editing and adding data to, with a demo desktop app, modified for this purpose called HNDSLFSVCUS.APP.

SUBSCRIBERS is an SQLITE table that we created by importing the PEOPLE file from HNDO.TPS. This is a fictitious list of people's names, that we've shipped with our toolkit for years with which to build sample CHT browses. We added some random values into the Serial Number field and some random expiration dates, and also, we added a fictitious email address and set of totally made up purchase-receipt information.


As we expand the experiment, we'll be adding data into the tables via across-the-web techniques using both Clarion-app-Client-to-Clarion-app-Server methodology as well as Browser-app-Client-to-Clarion-app-Server technology. All that will come in good time and will be thoroughly documented in good time.

The four "Web Browses" in this example are intended to demonstrate browsing data tables from any browser on any device that's new enough to have an HTML5 capable browser.

In the example web browses provided today, we'd like you merely to look and explore the four browser-based "web apps" on as many devices as you're able to find, preferably smallish portable devices like smart-phones and "phablets".

Note as you browse with your phone held vertically that the browse table is narrowed to fit your phone's viewport, though it can still be scrolled left-right with your finger. Note also, that when you turn your phone into the horizontal position that the browse table displays extra columns though it can still be scrolled left/right easily with a finger motion if the entire width of the table is not already displayed in the device viewport.

In these first two NEWSLINKSLIST examples we're listing articles, web pages, and discussion papers available on our site and pointing to them. Click on any item in the "Title" column to be taken to that article, page or paper.

We are expanding the NEWSLINKSLIST browse table by a record or two on a regular basis so it's obvious that the data table underlying it is changing and you're not seeing a static page.

In the next two SUBSCRIBER examples we're listing our sample "subscriber" table described above. The two example browses are created by the same back-end UCR$ procedure. So the back end code is identical for both browses. The SUB:Expire_DATE information varies as we're passing a date range parameter into the UCR$ from the calling web page.

If you visit either of these browses over successive days, it will be obvious that the data displayed is changing as the records with expiration dates not in the required date range fall out and other records, previously not in the correct range are now included.

We hope, as this work develops, that you'll take some time to look at the server application, and even test it out yourself. All the pieces to make this work from your desktop computer or any web-connected Windows PC will be in our toolkit starting with the Fourth Quarter Build 21D.00.00 slated for release by October 22, 2017.

You can pick up the source components for this and all required components, at any time before or after the next major update - since these components and any related how-to documents will continue to evolve over the coming months. So if the information you're reading about does not match what you see when you open the app, it will be necessary to update your toolkit using CHTWEEKLIES_1.EXE installer available to all subscribers from our CHT Installer Donwload site.

All the pieces required to run a test, to modify the tables, to modify the browses and the remote procedures (UCR$ procedures) in the application are there for you to study.

Now Point your Phones at One of These Addresses

Note that "PDE" in the first web address, below, is an acronym for Phone Does Everything. Which is appropriate for what we're trying to achieve here!

To run a test, point your phones at one or both of these addresses. Each resolves to a different server instance of the same, listening to a different IP and PORT.

October 1, 2017
Recent Update Changes Review

Revised Previewer: HNDPREVIEWER.APP

This application is called from various other CHT tool applications including the one described below, namely, HNDTPLDOCGEN.APP.

While we're generating HTML with our XML2HTML technology, and previewing as we work, it's important to be able to adjust the viewport by which we're previewing the HTML so generated. This gives us immediate feedback about how the HTML document will look on various small, portable format devices, including phones and smallish tablets, or as we've come to call them, "phablets".

To that end, there are several new menu items, marked in the image below by number tags. These viewport settings and sizes are based on actual dimensions of the viewports (** i.e. usable screen size **) of phones we're using presently. This selection of choices, based on real devices, will be expanded over time, though the present selection is already pretty useful and covers a broad range of viewport sizes.



This HNDPREVIEWER.EXE is also called by CHTSNAPEDIT.EXE from the "Preview" menu, as well as from other applications in the "CHT Document Builder" suite. We'll discuss at least some of these other applications in later sections of this document or in future discussions on the topic of CHT Document Builder.


The job of generating our templates documentation has now been taken over by an application called HNDTPLDOCGEN.EXE. This application replaces HNDTPXHTNEXT.APP, which has been retired.

At the heart of this new application is a procedure called AutoGenHTMLFromXML_VER02 which is responsible for translating a CHT XML template file called: 000TPLDOCS.XML into viable HTML. That happens, of course, only after HNDTPLDOCGEN.EXE reads through our .TPL and .TPW files to extract commentary embedded there between XML tags, and inserts it into a temporary copy of 000TPLDOCS.XML.

This temp copy of 000TPLDOCS.XML is then processed via the procedure named above and that results in several HTML documents described and linked below.

The application generates the following:

Since we're constantly changing and adding to the XML-tagged documentation embedded in our .TPL and .TPW files, we'll continue to make a point of running HNDTPLDOCGEN.EXE as we did in the past, with this application's predecessor, to bring our documentation up to date.

The HNDTPLDOCGEN.EXE application also calls CHTSNAP2PDF.EXE in order to create a .PDF version of each of the generated HTML files. This is for anyone who prefers their documentation in the .PDF format.



Contact Us

If you have any thoughts or impressions to share, feel free to get back to us via email using the hot link provided here.

Click the link below. It will start your email client with our email address inserted:

Click To Contact Us