CHT (Clarion Handy Tools)
Templates, Classes, Utilities, Apps, Projects

APRIL 28, 2022

Build 26B.00.00 Release Date
May 22, 2022

Some time early 2019, we reported a problem to SV about the WHAT() function in the newly released Clarion 11, in conjunction with the BIND() function, in order to bind variables from a VIEW underlying a browse, process or report to give these variables "friendly" names for easier querying.

Back when we first reported this problem, we found that under certain circumstances, some data BIND() calls were causing the Clarion RUN-TIME to choke (i.e. GPF) in C11, though not in 91 or c10, using identical code and identical data structures.

We found some notes recently, that we'd made at the time, in one of our libraries to the effect that BIND() could cause a GPF in C11 and we have just reviewed the problem in both C11 and C11.1.

The notes were written before C11.1 but, having just checked, the reported problem still exhibits in C11.1.

Our conclusion, at the time, was that there are low-level differences in the implementation of BIND(), between the Clarion (C9.1 and C10) vs (C11 and C11.1) run-time libraries.

The problem, however, is not with BIND() per se, but with some ambiguity as regards the use of WHAT() returning a REFERENCE TO A FIELD in some cases and a VALUE FROM A FIELD in other cases.

CHT successfully made a workaround to our filtering classes as regards our implementation of AUTOBIND, to BIND() data table variables with friendlier names for use in CHT queries.


By way of example, a backend field name, such as "CUS:Funky_Field_Name" can be made easily queryable as, ACCOUNT, or CUSTOMER, and so on, depending on the purpose of the field and how you therefore title it in the header of your browse.

To accommodate the run-time differences in C11/C11.1, as noted above, we made some changes to our data filtering library for this CHT template AUTOBIND feature in its use of BIND() statements affiliated with WHAT() queries on table data structures.

Our library code had up until then always automatically called BIND() for a field name such as CUS:ACCOUNT and would AUTOBIND it as "ACCOUNT", without the prefix, so it could queried using simply "ACCOUNT" rather that "CUS:ACCOUNT".

The code changes we made at that time solved the BIND() related GPF's in C11, by not performing any automatic binding on backend variables under circumstances and with data structures that would result in likely C11 GPF's.

It turns out that data structures without "EXTERNAL" names, are good candidates for C11 data inspection issues involving use of the WHAT() function with Clarion11, Clarion11.1.

Hence, we were able to continue (as we are today) using identical CHT class-library code in all versions of Clarion for which CHT develops. (C91, C10, C11, C11.1).And since then, those changes have been perfectly fine and safe, as regards the disappearance of the GPF problem in C11 and C11.1. Problem solved, right?

Yes, the GPF problem is solved, but at the expense of some automatic binding of VIEW structures in browses, processes and reports. That's why we ask you to familiarize yourselves with the information that follows.


So the C11, C11.1 version of WHAT() is still funky today and returns sometimes a reference to the field (expected) and sometimes a value from the field (bad when not expected) depending on the variable type and naming convention in the table structure, which is generated by ABC into a data VIEW structure for browses, reports and processes.

The problem that arises, can be understood as the difference between binding CUS:ACCOUNT to the friendly query word "ACCOUNT" (expected) and the VALUE in the CUS:ACCOUNT field, say, "BARNEY's BAR AND GRILL ON THE RIVER STYX" (not expected and not friendly).

Our automatic binding operation happens in CHT when "AUTOBIND" is set "ON" in any of our templates. In other words, CUS:ACCOUNT becomes "ACCOUNT" for querying via Clarion "NAME BINDING".

No problem there, at all, except for the WHAT() glitch in C11 and C11.1. The one for which we performed a workaround.

As already stated above, our workaround at the time we reported this, was to not call BIND() when the result of a WHAT() inspection of the VIEW field returned anything suspect, like a field VALUE instead of a field NAME.

That resulted, of course, in our AUTOBIND feature not having any effect under certain circumstances, due to it having carefully avoided binding suspect back-end variables, depending on the complexity of the data structure in the file layout and/or the lack of "EXTERNAL" field names in the dictionary.


We have ALWAYS provided alternate means to BIND friendly names to your table fields, (this has been the case for years) in order to provide easy querying on our CHT template browses and with CHT template processes and reports.

The AUTOBIND feature that we've always provided, while useful, is of limited value depending on dictionary data table field names and types.

It can BIND() CUS:ACCOUNT to "ACCOUNT" (a good thing). However, it's of limited value to bind "CUS:Funky_Field_Name" to "FUNKY_FIELD_NAME" for easy querying.

When for whatever reason, you encounter a field name like "CUS:Funky_Field_Name" in your data tables, we provide a "QUERY HOT FIELDS" dialog with which a sensible name like "ACCOUNT" or "CITY", or whatever the field actually represents, and thereafter you can query the field by that more friendly name.

This can happen in plenty of real-world circumstances when you inherit data tables designed with say, DANISH field names and want to query a browse addressed at an ENGLISH audience or vice versa.

In other words, all of our templates involving querying and filtering provide a means for CHT users to BIND friendly query names to less-than-friendly back-end field names.


For example, you have a browse, and you need to send a data-limiting query from that browse to a process so that only the data matching the query is handled by the process.

It is the developer's responsibility to see that the BINDing of friendly names which works effortlessly in the BROWSE procedure, is reflected in the PROCESS or REPORT to which you are sending the query. To do that you must complete the "QUERY HOT FIELDS" dialog on our template for the report or process.


Our PROCESS template HANDYQUERYPROCESSLIMITER, for example, provides a dialog with which to establish the same BIND() name for "CUS:Funky_Field_Name", as you might have established in the browse. This dialog draws its name from Clarion's "HOT FIELDS" concept. We call it "QUERY HOT FIELDS" since that's more-or-less what Clarion "HOT FIELDS" represent, fields for which a BIND() action, of one sort or other is being performed.

As any Clarion developer worthy of calling himself a "Clarion Developer" knows full well that BIND() has procedural scope. So a perfectly viable query word like "ACCOUNT" for CUS:ACCOUNT works fine in your CHT browse procedure, but doesn't work in a your CHT process, to which you may be sending the very same query. That's BECAUSE IT'S A SEPARATE PROCEDURE, and BIND normally has procedural scope when binding is handled at the procedural level, as it is with most browses.

And that's why we provide a "QUERY HOT FIELDS" dialog on our process and report filtering templates, so that you can establish binding, THERE, that matches the binding taking place in your browse.

Clarion's working "SMARTER NOT HARDER" mantra is true BOTH in the sense that SMART means the opposite of SLOW or LAZY, but also in the sense that SMART can imply "PAIN" like when something that "bites you in the ass" can "SMART" due to a basic lack of Clarion "SMARTS".

The point, is, you will end up working "HARDER NOT SMARTER" unless you intimately get to know and understand how Clarion works, and also how CHT works at leveraging the things that Clarion DOES WELL, and filling in the gaps, for things Clarion CAN'T do or DOES LESS WELL.



This template will now automatically populate on all window procedures from CHT Global template ApplicationImagesEx.

The presence of EmbedWindowFunctions on a window procedure makes visible quite a number of CHT Control and Extension templates that otherwise might not have been visible unless you manually inserted the template on your window procedure beforehand.


This template always self-populated on your window procedures from our global template ApplicationImagesEx. But wait, some of you never actually bothered to go to the ApplicationImageEx template to enable it. So, in effect, it did nothing on your application because while disabled, ApplicationImagesEx does not auto-populate ProcedureImageEx.

As of the last build update, 26A.01.00, ApplicationImagesEx is fully enabled by default. There is no longer a "Disable" setting on this template. This continues of course, in 26B.00.00. We have however, given you global control over the three local settings being exercised on the window procedure by ProcedureImagesEx.

While ProcedureImagesEx is now present on your window procedures you still can fully control from our global ApplicationImagesEx template, which of the three outcomes listed below is excercised locally.

ApplicationImagesEx and ProcedureImagesEx have styling effects (images, fonts,and colors) on your application windows using the following rules-of-thumb.

1) ProcedureImagesEx can pass through global styling from ApplicationImagesEx

2) ProcedureImagesEx can provide local-window styling on its template interface

3) ProcedureImagesEx can skip doing anything about styling, images, fonts and colors

APRIL 2, 2022

26B.00.00 Update Coming May, 2022

As we make edits to CHT templates for the next CHT release, (April 17th approx) it becomes immediately obvious that it is important to keep an eye on the size of your Clarion template registry file "TemplateRegistryXX.TRF".

Because we're editing and constantly reregistering changes, it took only a day or two for our registry .TRF to grow from approximately 12.5 MB to 250MB. We could feel Clarion slowing down incrementally as these reregistrations took place.

Since the Clarion template development system has no window previewer, template coders like ourselves cannot view the layout of a template interface (although intuition, and experience are helpful) without closing the template file and opening an application. This, of course causes the currently registered template chains to reregister and that triggers .TRF growth. The rate of growth depends on how many templates are registered, but the rate of growth is exponential.

Obviously, the rate of growth on our development machine is probably considerably faster than on yours, unless you too have a personal template chain that you are maintaining and changing, or you're regularly updating or changing your selection of registered templates. Growth is not by what's new and changed, unfortunately, its by the total number and size of templates already registered. That's why we're saying that growth is exponential.

When any template set is changed, or a template chain is added or removed, in fact, any action that causes template reregistration causes the template .TRF file to grow. It never shrinks, even when a template chaine is unregistered.

To that end, we've given you an app in /accessory/bin/ called HNDTPLREGISTER.EXE to assist you with quick template chain full, from-scratch, template registration. The app shows you the size of your current .REG file, deletes it and registers the selected template chains (.TPLs with their .TPWs).

So, the difference between a small, fast, .REG file and a huge, unweildy one, is in the operational methodology implied in these words: "Reregistration" and "Registration". The former implies adding to, or changing, an existing .REG file while the latter implies deleting the .REG file and re-creating it from scratch. HNDTPLREGISTER.EXE does the latter. It recreates the .REG file using the selected template (.TPL) chains.

There is a video available via HNDVIDEOJOURNAL.EXE called "FEB 8, HANDYVERSIONRESOURCE TEMPLATE REVIEW" which near the end discusses the use of HNDTPLREGISTRY.EXE, some time after minute 45 (approx) of the video.

MARCH 10, 2022


There are two new templates, "CHTAddGlobalsFirstControl" (Control Template) and "CHTAddGlobalsFirst" (Extension Template). These two templates are guideposts, effectively, since their sole purpose is to appear alone in the IDE's control and extension template selection dialogs when you do not yet have our global master template "AACHTControlPanel" and its associates installed.

So let's assume you have an application in which there are no CHT templates of any kind installed.

Poking around, you open the Extension Templates selection dialog looking for any CHT extension templates. All of our Extension Templates, as of this March 9th update, are invisible to any app which does not have AACHTControlPanel installed. If that condition applies, the only Extension Template you will see from CHT is: "CHTAddGlobalsFirst". Template instructions are below.

Poking around some more, you open a window and want to add CHT Control Templates to your window. All of our Control Templates, as of this March 9th update, are invisible to any app which does not have AACHTControlPanel installed. If that condition applies, the only Control Template you will see from CHT is: "CHTAddGlobalsFirstControl". Template instructions are below.

In previous builds, all local control and extension templates which were dependent on AACHTControlPanel, ApplicationImagesEx and HandyVersionResource, would simply install these three required global templates into the app for you in the background, as soon as you installed any local template from the Extensions Selection Menu or from the Control Templates Selection Menu.

Work Smarter Not Harder


That was introduced as a convenience for developers following the old Clarion adage "work smarter not harder". The idea was, that any template which is dependent on other, higher order, templates simply installed those higher order global templates for you first, automatically. Before installing itself.

The problem with that "easy peasy" approach is that it only IMPLIES and doesn't DEMAND that the developer go first to the higher order, global template interface to configure THAT, before proceeding with the implementation of the local Extension or Control Template being added, and which to varying degrees, has dependencies in the correct configuration and setup of the higher order template to which it connects.

So, the whole point of "CHTAddGlobalsFirst" and "CHTAddGlobalsFirstControl" is to draw attention to the fact that the correct use of MOST CHT TEMPLATES in your app is dependent on THREE CHT GLOBALS --FIRST-- being present in your app, --SECOND-- being configured to certain minimum requirements.

The text instructions on "CHTAddGlobalsFirst" and "CHTAddGlobalsFirstControl" point out the need to deal with "AACHTControlPanel", "HandyVersionResource" and "ApplicationImagesEx" BEFOREHAND.

CHTAddGlobalsFirst Template

This is the only CHT EXTENSION TEMPLATE that displays in the CLARION EXTENSIONS SELECTION list from the IDE when CHT Global template AACHTControlPanel and its associates, are missing from your Application.

And while "CHTAddGlobalsFirst" template does offer to include all required CHT Global templates into your application automatically, those auto-added templates still need to be configured FIRST.

It is therefore recommended that rather than using this "CHTAddGlobalsFirst" template when it appears in the IDE extension selection list, that you cancel out at that point and proceed instead to your application's "Global Extensions" area to select "AACHTControlPanel" and include it into your app.

Three other required CHT Globals are added to Global Extensions by inserting AACHTControlPanel. These are: "AACHTControlPanelClose", "ApplicationImagesEx", and "HandyVersionResource".

Three of these four CHT Global templates require a degree of pre-configuration. See the CHT Help file CHTTEMPLATES.HTML or CHTTEMPLATES.PDF and search for the template names given above.

CHTAddGlobalsFirstControl Template

This is the only CHT CONTROL TEMPLATE that displays in the CLARION CONTROL TEMPLATES SELECTION list from the IDE when CHT Global template AACHTControlPanel and its associates, are missing from your application.

And while "CHTAddGlobalsFirstControl" template does offer to include all required CHT Global templates into your application automatically, those auto-added templates still need to be configured FIRST.

It is therefore recommended that rather than using this "CHTAddGlobalsFirstControl" template when it appears in the IDE extension selection list, that you cancel out at this point and proceed instead to your application's "Global Extensions" area to select "AACHTControlPanel" and include it into your app.

Three other required CHT Globals are added to Global Extensions by inserting AACHTControlPanel. These are: "AACHTControlPanelClose", "ApplicationImagesEx", and "HandyVersionResource".

Three of the four CHT Global templates added require a degree of pre-configuration. See the CHT Help file CHTTEMPLATES.HTML or CHTTEMPLATES.PDF and search for the template names given above.

MARCH 3, 2022

BUILD 26A.01.00

We posted a new CHT Build, numbered 26A.01.00 yesterday evening, March 2, 2022.

This update adds some significant color control to all of our CHT browse templates:

Explorerbrowse, HandyMarkerBrowse, ListBoxBrowseExtender.

To see CHT browse templates in action in any of our example applications:





To test HNDPEOPLE_LBX.APP and HNDPPLLBX_REMOTE.APP, both of which have remote test servers based at CHTHQ, send an email request to asking for a set of login parameters for these remote apps.

You can, of course, test them yourself locally or remotely against the two server apps provided, rather than against our remote servers.


The "Sort Column Color" dialog (identical on all three templates) introduces a "Selection Row Back Color" feature which gives you control over the selection row background color from our template.

From this dialog now you can control:
•  Column text or background color
•  Selection row background color
•  Header bar background color
•  Header bar text color

As before, the "Reverse" switch setting causes the sort column to "reverse" the color applied in #1 above. The text and background colors are swapped.

And, as before, you can save your settings applied on one procedure and recall them into another procedure. To experiment, you can "Insert CHT Default Colors" as a starting point.


While in recent years we've built our application color scheme around a RED, BLACK and DARK SLATE GREY color scheme, we've introduced with this build an example application called HNDSQL1_SEA.APP.

This application is identical, functionally to "red-theme" HNDSQL1.APP, listed above under ExplorerBrowse, except that it uses a "SEAGREEN" color theme. Hence the name HNDSQL1_SEA.APP.

With this application, we've replaced the "Sort Column Color" dialog colors with green-theme colors, derived experimentally to co-exist compatibly on the application window. Both ExplorerBrowse procedures on this application apply a "CHT Query Control" from the "?" button on the tool bar. Note that both the dialog colors and the dialog icons match the green-theme established on the app. Other CHT internal dialogs, (if they were used with this app) would also conform to this new green-theme configuration.

Examples of these other CHT dialogs are:
•  HNDDATES (CHT calendar),
•  HNDCONFIG (Configuration screens)
•  HNDBRWFL (CHT Query Builder screen)
•  HNDDISK (CHT File selection dialogs)


Navigate, if you will, to the global template ApplicationImagesEx on this "green-theme" HNDSQL1_SEA.APP. Click the "Image Settings Stylesheet" dialog from the ApplicationImagesEx template main interface.

Note that the first two "Styles" tabs insert a number of "green-theme" images which we've provided with this build in the CHTSETUPCxx_3.HZO container with all other required images.

Then on the next two "Internal" tabs we've inserted a selection of default icons such as "cht_ggl_check_sea.ico" and "cht_ggl_uncheck_sea.ico".

By inserting these "green-theme" icons globally on the "Images Settings Stylesheet" all of the CHT internal class-based dialogs will conform icon-wise to the newly established "green" theme. You need to do nothing else, programmatically to achieve this CHT dialog icon color match.

Of course you need color-matched icons but we've provided a set of "_sea.ico" icons with this build. In future CHT builds we'll provide other sets of color-matched icons which could be inserted here, besides _red.ico, _sea.ico.

Other icon/image sets already in the works are _white.ico, _black.ico, _grey.ico, _blue.ico. Once a few of these have been introduced, we'll provide a "color-theme" selection dropdown on the "ApplicationImagesEx" template which will instantly switch to the correct icon/image sets for you depending on the selected color theme.

Of course, in all cases, manual icon/image selection control will continue to be available, as always. Many of you have your own sets of preferred icons which can be saved as defaults on our template, from the template interface just discussed.


Navigate once again to the global template ApplicationImagesEx on this "green-theme" HNDSQL1_SEA.APP.

This time, click the "Display Settings Stylesheet" dialog from the ApplicationImagesEx template main interface. You will encounter a set of dialog tabs which cover font and color settings that then can apply in your app if you want them to.

On the final, right-most dialog tab, called "Class Dialogs" we have inserted "0071B33CH". This is the text color applied on the "CHT Query Control" that you see from the "?" (Query) buttons in HNDSQL1_SEA.APP.

Further on this "Display Settings Stylesheet" under "Controls" there are some fields that can speed up your browse list box design. Take particular note of the following three: "List Box Backgnd Color", "List Box Text Color" and "List Box Line Height".

With these simple, saveable global setttings you can further control the background color of your CHT Browses, the text color of your CHT Browses and the line height of your CHT Browses. If you do nothing we have default values here which are: COLOR:White (background) COLOR:Black (text) and 11 (Browse Line Height).

All settings in ApplicationImagesEx are (and will continue to be) saveable in one app and recallable in another app, so that application image and color settings worked out in one application can be instantly transferred to another.


We've made the "Developer Set Version Configuration" optionally readable from the CHT Configuration file created by our installer in your BIN directory.

These config files are: HND91TPL.INI, HND10TPL.INI, HND11TPL.INI or HND111TPL.INI, depending on which Clarion version you happen to be using, and they are located in your /accessory/bin/ directory.

Watch the FEB 8, Journal Video called: "HandyVersionResource Template Review" to get the background on how this works.

The new "Developer Set Version" switch called "Read Version Number From Config", if checked, reads the version number you've inserted into the Config file at app generate time. Turn this switch off to maintain a fixed, version specific to the app you are working on.

Default for this "Read Version Number From Config" setting is OFF.


Below are example entries touched by HandyVersionResource. The entry read by the "Read Version Number From Config" switch being checked, is "FIXEDVERSION=" shown below. The other settings are discussed in the video. Any further questions, drop a question on the CHT Forum using our pre-compiled forum app HNDCLIENTCL.EXE.

•  USERSERIAL=12345678 (not our actual value)
•  COMPANY=CHT (Clarion Handy Tools)
•  TRADEMARK=©CHT (Clarion Handy Tools)
•  SLOGAN=©1996-2022 - Let`s Build Something New!
•  COPYRIGHT=Copyright ©CHT 2022
•  VERSION=26A.01.00

Contact Us

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

Click To Contact Us