Clarion Handy Tools
February 2017

February 24, 2017

Build Update 21A.03.02 Posted

At 3:00 PM Friday February 24th, 2017 we completed posting an update to CHT Build 21A.03.02.

We hope you will read the following essay posted a few days ago:


That essay will help you set up HNDCLEAN.EXE as a utility available from the Clarion IDE's "Tools" menu. In a few words, HNDCLEAN.EXE will solve the the problem of how developers can guarantee that when they use the IDE's "Generate and Make Current Application" menu, their application will actually regenerate fully, not partially.

We have internally logged, with the current clarion 10 IDE, many situations where template interface settings were changed that were not reflected in the finished application on our first execution of "Generate and Make Current Application". This situation occurs when the .CLW file targeted for the template setting change that you made, was not regenerated when it should have been.

Our essay, linked above, explains how HNDCLEAN.EXE can help you truly "Clean" up the previously generated files created by your application so as to "force-regenerate" the application from scratch.


HNDCMP.EXE - CHT Clarion Project Builder
Revised To Incorporate HNDCLEAN.EXE Config

We've provided a new configuration field on our HNDCMP.APP to configure HNDCLEAN.EXE input parameters 2, 3, and 4 in a manner similar to the above settings applied to HNDCLEAN.EXE setup for the Clarion "Tools" menu. [Image 1 Below]


Note that only parameters 2, 3, and 4 are used in this configuration because HNDCMP.EXE already knows what application you're compiling and in which directory it is located, so in it's call to HNDCLEAN.EXE it adds the first parameter (P1) automatically, and appends your (P2 P3 and P4) parameters from your configuration on the pictured HNDCMP.EXE dialog.

All the other rules and behviours apply as explained in our HNDCLEAN.EXE: How To Set Up document, including the use of relative or co-relative paths and the correct configuration of your CLARION100.RED file as explained there.

When the HNDCMP.EXE "Perform Clean First?" switch pictured above, is checked, the application's compile log now contains also output from HNDCLEAN.EXE in the same manner that the IDE's output window does. [Image 2 Below]



HNDBACKUPCONFIG.EXE - CHT Auto-Backup Configurator
Revised For Easier Restore

CHT's Global Template AACHTControlPanel has a setup tab called "Global Auto-Backup" which will trigger your applications to be backed up periodically, on a configurable time interval, as you're working on them and changing them. [Image 3, Below]


The backup directory configured on this "Global Auto-Backup" tab is managed from a CHT utility application called HNDBACKUPCONFIG.EXE or CHT Auto-Backup Configurator. From here you can browse, search, archive, and restore .APP and .DCT files that were backed-up automatically as you worked on them.

Each backup retains the original name plus a date-time stamp to help identify it for easy temporal identification when the day comes to want to locate an app saved prior to its having been changed or damaged.

From this utility's interface you can browse, recent backups, still in date-stamped .APP and .DCT format or browse and search older, archived backups packed in zip files. [Images 4,5,6 Below]




CHT Auto-Backup Configurator
Set Up On The Clarion IDE "Tools" Menu

Your backup-archives are always readily available when you attach HNDBACKUPCONFIG.EXE to the Clarion IDE's "Tools" menu. We'll review how to do that here. You probably already know how to do this, so we'll make it brief in the form of a two images. [Images 7,8 Below]



CHT HTML Document Builder
Print Your CHT Subscription Receipt Via The Web

In our recent document JANUARY 2017: CHT TOOLKIT FACTS SHEET we talked about one of our goals for 2017 was to illustrate various ways of merging real-world data with HTML documents which are then, optionally printed to .PDF.

We've revised HNDDOCUMENTBUILDER.APP to illustrate one way this can be done and to provide you with a practical example of live, web-acquired data being merged into a payment-receipt document based on an .XML template we've provided in your \accessory\hnd\xml\ directory called 000chtreceipt.xml.

We've set up a CHT file and page server -- like HNDFILSV.APP -- and attached it to an SQLLite data table extracted from our accounts and subscriptions table. This table when we're done with it will contain the payments portion of your CHT Subscriber account.

To the server we added a single procedure which, is called after authentication, and returns your subscription payment details. Also on the server we added a single, ProccessUserCustomRequest template. This template upon receipt of a UCR$ request (i.e. "User Custom Request" or Remote Procedure Request) from HNDDOCUMENTBUILDER.APP.

Locally, HNDDOCUMENTBUILDER.APP merges the receipt data with 000chtreceipt.xml to produce a HTML receipt displayed in CHT HTML Previewer, from where you can save it to disk as HTML or print it to a .PDF file also saved to disk.

Here in pictures are the steps to viewing and printing your own CHT Subscription Payment receipt. [Images 9, 10, 11]




At time of writing, not all receipt accounts have been fully established. If receipt information is not available for your account when you try this, you'll be presented with partial information and along with a "not yet configured" message. Designated CHT Testers, you know who you are, all have their receipt information up to date. All others active subscriber accounts will follow.

Gus Creces
The Clarion Handy Tools Page

February 24, 2017


February 22, 2017

And Use The Latest Version

This version of HNDCLEAN.EXE (Version or later) lets you configure it in such a way, that it KNOWS about redirection locations (alternate gen-file output directories) that you may have configured in our Clarion .RED file.

When you configure HNDCLEAN.EXE for your normal RELEASE operations, it's necessary to tell it where your template-generated output is going. Even with a default .RED, HNDCLEAN.EXE will not assume anything about how you're configured unless you tell it explicitly.

Sample Setup With Co-Relative Subdirectories

HNDCLEAN.EXE takes up to four input parameters. These are as follows:

PARAMETER 1 -- REQUIRED ---  [P2 OPT]   [P3 OPT]     [P4 OPT]
${TargetDir}\${ItemFileName} subdir1 supdir1\subdir2 subdir1\subdir2\subdir3

All parameters require at least a single space between them. All directories provided are rooted in ${TargetDir}. Hence, they are relative directories -- relative to the value in ${TargetDir}. When directories in P3 and P4 are chained as shown, these become co-relative sub-directories meaning that each of the "subdir" parameters places itself below the prior one.

Given an input for ${TargetDir} of "c:\test" the full set of clean directories as configured above resolves as follow:

c:\test\  (This is ${TargetDir} which comes up from the IDE)
c:\test\subdir1  (Passed in, optional Parameter 2)
c:\test\subdir1\subdir2  (Passed in, optional Parameter 3)
c:\test\subdir1\subdir2\subdir3  (Passed in, optional Parameter 4)

Sample Setup With Simple-Relative Subdirectories

HNDCLEAN.EXE takes up to four input parameters. These are as follows:

${TargetDir}\${ItemFileName} subdir1 subdir2 subdir3

All parameters require at least a single space between them. All directories provided are rooted in the ${TargetDir}. In this case, because P3 and P4 make no reference to P2 or P3, respectively, these paths are "simple" subdirectories, all rooted in ${TargetDir}.

Given an input for ${TargetDir} of "c:\test" the full set of clean directories as configured above resolves as follow:

c:\test\  (This is ${TargetDir} and comes up from the IDE)
c:\test\subdir1  (Passed in, optional Parameter 2)
c:\test\subdir2  (Passed in, optional Parameter 3)
c:\test\subdir3  (Passed in, optional Parameter 4)


CHT HNDCLEAN.EXE Setup With Co-Relative Paths



CHT Test "CLARION100.RED" File Setup To Match Above Image



How The IDE Determines The Value of ${TargetDir}

The secret to successful CLARION100.RED configuration is knowing how the default output directory is determined. This is the value that's inserted into the IDE MACRO ${TARGETDIR}.

In fact TARGETDIR is the directory in which the .APP file being worked on is located. If you wish to refer to this HOME or TARGETDIR in the .RED configuration, you do so with a DOT. Our sample .RED configuration set up for [Release], allows six file extensions to be generated into the ${TargetDir} location, indicated simply by a DOT.

That's why we use an IDE MACRO ${TargetDir} as the first half of our first (P1) HNDCLEAN.EXE input parameter. The second half of our first parameter is ${ItemFileName}. This is the name of the application currently loaded for Generate-Compile activity. Note that in Image 1 above, we've separated ${TargetDir}\${ItemFileName} with a backslash to provide a full legal path to the application.

Where your app is located, then, comes up from the IDE and the value provided to ${TargetDir} depends on where the application that you're working on is located. The remaining output sub-directories are RELATIVE to that one ${TargetDir} location.


Locating Test Application HNDVIDEOPLAYER.APP
Into C:\TEST

To test the viability of our setup we placed three files into a directory called "c:\test". Since this application requires no dictionary, the files used are:


We loaded the application into the Clarion 10 IDE and forced a full Regenerate/Compile on the freshly loaded application as using the Generate and Make Current Application menu as in the next image.



Into C:\TEST

The next image provides the files created by the execution of the "Generate and Make Current Application" menu against our test application HNDVIDEOPLAYER.APP.

Remember we're starting with only 3 files, enumerated above. Some of these files (eg: .CLW, .INC, .VERSION etc.) are the result of the action of code-generation. Some of these files (eg: .OBJ. .MAP, .RSC etc.) are the result of the action of code-compilation.

"Generate" and "Make" (i.e. Compile) are two entirely separate IDE actions invoked when the "Generate and Make Current Application" menu is used.


After "Generate" and "Make" the resulting file count jumps to thirty-five (35), located in the four directories configured ealier in our CLARION100.RED.

• C:\TEST -- 10 Files created. (i.e. ${TargetDir} Parameter 1)
• C:\TEST\CLEAN -- 7 Files created. (i.e. Parameter 2)
• C:\TEST\CLEAN\CLW -- 9 Files created. (i.e. Parameter 3)
• C:\TEST\CLEAN\OBJ\RELEASE -- 10 Files created. (i.e. Parameter 4)

A quick review of our CLARION100.RED setup -- see Image 2, above -- will confirm that these file extensions are located where they were configured to be located.


Testing The IDE "Clean Solution" Menu

The major reason we're spending so much time testing and perfecting HNDCLEAN.EXE is because we've found that Clarion 10 does not provide a full enough cleaning service that will trigger both a full Re-Generate and a Full-Recompile.


The Clarion 10 "Clean Solution" or "Clean hndvideoplayer" menu do trigger removal of the .OBJ files resulting from the compilation of HNDVIDEOPLAYER.APP generated source files.

Unfortunately, neither of these menus, as our test image below proves, triggers removal of any generated code files. Consequently applications requiring a full-regenerate in order to trigger code from newly added templates or from changed template settings requires sometimes a maneuver as drastic as exiting and re-loading the application before full code regeneration is achieved.

Before discussing that further, take a look at the files-count resulting from a the IDE's "Clean Solution" menu. [Image 6 Below]


Of a total of 35 original files, only 10 files were deleted. Leaving 25 files as can be seen in Image 6.

All directories save the C:\TEST\CLEAN\OBJ\RELEASE still contain the same file count as before the "Clean" operation was performed.

As explained above, this is fine for triggering a "re-compile" of the application source code but it does not trigger the IDE to "re-generate" the application.

The "Clean" operation derives from functionality built into MSBUILD, an environment that does not incorporate the concept of code-generation, at least not to the extent that Clarion generates code.

MSBUILD considers code files to be static unless touched and edited by human hands or at least, modified by some action on the VS (Visual Studio) interface.

That may explain why Clarion "Clean Solution" or "Clean myapp" do not also erase generated-code files.

Unfortunately, again, it's less than satisfying to understand this when a developer knows they've made changes to their application template settings in various places and they want to trigger a full-regenerate to ensure that all template setting changes are being generated into the code files.



Image 1 above, explains how we set up HNDCLEAN.EXE on the Clarion Tools menu with input parameters that match the co-relative subdirectories configured in our CLARION100.RED file. If you need to recheck that before reading on, please do so now.

To execute an item on the Clarion IDE's "Tools" menu, where HNDCLEAN.EXE has been added, pull down "Tools" and click the "CHT Clarion Gen-Code Cleaner" menu item now located there. That's all there's to it.
[See Image 7]



Examining The Result Of Clicking The
CHT Clarion Gen-Code Cleaner Menu

Back in the "c:\test" directory, we show you now the remaining files list resulting from executing the CHT Clarion Gen-Code Cleaner menu.


Only 7 files remain from the original 35 files. HNDCLEAN.EXE removed the rest. Let's examine which files are left and why they are being left untouched.

The following files names remain in the C:\TEST directory. Note that there are no files remaining in any of the configured co-relative sub-directories. This may not always be the case depending on whether your application is pure-CHT or whether it contains other 3rd party templates, some of which, we know, also generate file extensions unique to them. Even CHT template settings can affect the total number of files generated, obviously.

The important point here is that HNDCLEAN.EXE is deleting the bulk of our application's generated files, ensuring that the code-content of these files is refreshed completely from the application templates.

C:\TEST\HNDVIDEOPLAYER.APP  (The original application)
C:\TEST\HNDVIDEOPLAYER.AP~  (The original application's temp file created when app is open)
C:\TEST\HNDVIDEOPLAYER.BPP  (The original application's backup file created by the IDE)
C:\TEST\HNDVIDEOPLAYER.CWPROJ  (The original application's project file)
C:\TEST\HNDVIDEOPLAYER.SLN  (The original application's solution file)
C:\TEST\HNDVIDEOPLAYER.CWPROJ.FILELIST.XML  (Required by the IDE "Clean myapp" menu)
C:\TEST\HNDVIDEOPLAYER.VER  (CHT-Genearated App version file used by other CHT templates)


While an extensive set of 35 generated or compile-created files emanated from only three original files, you can see that HNDCLEAN.EXE performed a far more extensive "Clean" operation than the IDE's native "Clean Solution" or "Clean myapp" menus.

The operation of HNDCLEAN.EXE WILL RESULT in the IDE's "Generate and Make" menu causing a full regenerate and a full recompile of your application.

This is going to be a real time-saver for us. We hope the same for you dedicated Clarion users.

Gus Creces
The Clarion Handy Tools Page

February 22, 2017


February 21, 2017

Build Update 21A.03.00 Posted

At 2:45 PM Tuesday February 21st, 2017 we completed posting Build Update 21A.03.00.

** This build contains a new version of HNDCLEAN.EXE that can work with significantly redirected outputs in the .RED file. We will explain in a separate posting how to configure this if you have redirections in the .RED file. As opposed to simply the standard redirections that come in the default .RED

** One of the things we learned in this study of the IDE's "Clean" behaviour is that errors or mis-directions in your CLARION100.RED file can actually break the IDE's native "Clean Solution" or "Clean YOURAPP.APP" behaviour. Take note, that our study involved only the [RELEASE] and [DEBUG] sections or the .RED file, as these are related to IDE file OUTPUT.

** We learned also that the IDE's native "Clean" behaviour when it does work -- and after fixing possible .RED file errors or ambiguities -- is only adequate to cause a "recompile" of the application. It apparently has ZERO impact on helping the developer to force the IDE to "force" regenerate the application. Consequently, if there are embedding errors in your .CLW/.INC output, or if you simply want the whole app to regenerate, you can't do it, at least not easily, with native IDE "Clean Solution".

** On the other hand, HNDCLEAN.EXE will FORCE a complete REGENERATE AND COMPILE when you run it against your application. We will explain further how/why it is able to do this in a separate posting entitled "How To Set Up and Use the Latest HNDCLEAN.EXE".

** Also in this update, we had to revisit recent changes in these templates:
This was not finding "default.version". It does now, all things .RED being in order.

These two templates have an on-off switch which writes a #PRAGMA into the application that then executes a batch file (when ON) to do some POST-BUILD operations having to do with code signing and executable compression. In the off condition, when the #PRAGMA is not to be executed, we were deleting the generated batch file, still referenced in the #PRAGMA. The IDE doesn't like this and could intermittently cause an "Exec" error resulting from its failure find the now missing batch file.

In the off condition, therefore, we're now still generating the batch file, but it simply contains a message about the template being set OFF. That seems to satisfy the conditions necessary to avoid the intermittent "Exec" errors.

Gus Creces
The Clarion Handy Tools Page

February 21, 2017


February 15, 2017


(Connecting to a Remote Client Server)

The first four procedures in this app assume local data tables. The last procedure highlighted in the dropdown menu [See image], however, is a Client/Server remote data procedure. At the moment, these procedures are hard-wired to be either local or remote. But in later versions of HNDPEOPLE_LBX.APP we'll make this a "Dual-Mode" app that can be toggled to use either local or remote Client/Server data on demand, from all procedures.

There's a server already set up to test the Client Server Remote Data example procedure in this app (HNDPEOPLE_LBX.APP)


When you invoke this menu a login-dialog will pop up the first time you run the procedure asking for login data. You can complete the dialog as shown. [See Next Image]


There are other passwords for this since these will clash if everyone tries to log on with the same password. We've added a list of them below. The email address can be anything, or left blank, since this app only requires a two-piece login. USERNAME and PASSCODE. The email address is ignored.

The data server we're using up there is not HNDMTSSV.EXE as indicated on the app's window. This data is coming from HNDCLIENTSVLEAN4VIEW.EXE which has a similar enough view structure to HNDMTSSV.EXE, except it doesn't deliver phone numbers as you can see on the next image.


Give this a run when you get a chance. Here are some extra (different) logins:


You should know by now that once you download an intitial set of records into the "Main Queue". You can click the "Shadow Queue" button and search for subsets in the main queue recordset with an entirely separate query. This secondary search (or sub-search) has no impact on the back-end since the search is in-memory, so it's very fast.

That data model, a browse with two QUEUE's is unique to LBX. This should be more clear when you look at the following image:


When you're done, click the RED Target Button to log out or the server will reserve a spot for you for one hour and not let anyone re-use that login until that spot is cleared when your app logs out. If you log out when you're done, the username, pwd are immediately freed for someone else's use.


Once you're logged in you can open this procedure as many times as you like without seeing the login dialog to hassle you. But once you're done and ready to leave the app, push the logout (RED) button. We need to add an auto-logout on the exit app event.

Gus Creces
The Clarion Handy Tools Page

February 15, 2017


Configuring HNDCMP.EXE

(CHT Clarion Project Builder)

Here in a series pictures is an explanation of how to initially configure HNDCMP.EXE for a test compile of the HNDAPPS.

Many of these settings will come in as automatic pre-sets, but some require user-intervention. Please check them for accuracy before performing a HNDAPPS compile test for this latest 21A.02.00 build.

Please also make sure the paths that you insert for copy destinations actually exist.







The HNDCMPC10.TPS file located in /accessory/hnd/ is a specialized HNDAPPS compile control file. You can create as many of these control files as you like for your own apps. But this one name, (HNDCMPC10.TPS) is reserved for the HNDAPPS.

When you load it, the path to the HNDAPPS changes to the correct one for your installation. Give it a second, on load, to detect the path settings. If it doesn't change immediately, just exit HNDCMP.EXE and restart it with HNDCMPC10.TPS loaded.



To begin compile, select, say the 6 first apps, and click the "compile" icon (lightning bolt).

If you try this, let us know how you make out.

CHT Gen-Code Cleaner Utility

We're remediating an annoying behaviour that's been around for a while having to do with the "CLEAN" operation.

It used to be that "CLEAN" would erase .CLW's and .OBJs related to the app, at least sufficient to cause the generator to force regenerate the app. Now that behaviour is changed and you have to jump through hoops to get a full, unconditional regenerate/recompile of the app, without practically exiting Clarion and re-loading the app.

Here's how to set up HNDCLEAN.EXE to work for you...

Pull down the IDE's Tools -> Options Menu and select "Tools". That brings you to the "External Tools" menu as shown below:

Complete the dialog exactly as shown after pushing the ADD button to add a new one. Select the "Arguements" and "WorkingDir" macros exactly as shown from the selection (>) buttons on the right. Then, check the "OutPut" window switch. This produces a message in the IDE's output box when HNDCLEAN.APP executes as follows. (see next image)


Save the "External Tools" dialog just added by clicking the OK button.

To test, load an app, generate it and then pull down the IDE TOOLS menu. You should see the "CHT Clarion Gen-Code Cleaner" item as in the next image:


To perform a clean on the currently loaded app, simply select the CHT Clarion Gen-Code Cleaner item.


The exe is sent the name of the app (minus the .APP extension) as a command line parameter. It deletes generated code files and OBJs created belonging to the app.

After you execute HNDCLEAN.EXE you'll find that a Build -> Generate and Make Current Application gives you a freshly generated set of .CLWs in case there were errors in them.

If your app has "hanging" .CLWs that are no longer part of the app as you might get by executing "Redistribute Procedures" your app will warn you that it can't find those .CLWs (because they've been erased) and because they're not generated any more due to your "Redistribute" Request. Just pull those .CLW's off the app .CLW tree. Any required .CLW's will re-generate as required. This kind of thing is what the IDE's Clean is supposed to do but it doesn't seem to work that way any more.

I discovered that some of our HNDAPPS were still including some "hanging" .CLWs that shouldn't be there due to my having executed "Redistribute Procedures" and the failure of the IDE "Clean" routine not stripping them off the app. And since the obsolete .CLW was still hanging around on my drive, the app compiled OK, at my end. But it would report the hanging file as missing at your end since it is no longer being generated by the IDE.

This one little utility is going to save us hours a week trying to get the IDE to force regenerate our apps.

Gus Creces
The Clarion Handy Tools Page

February 15, 2017


February 14, 2017

CHT Build Update 21A.02.00 Available Now

We've just posted the 21A build (now as sub-version .02) Tuesday Feb 14th, 2017 @11:45AM EST.

The biggest change in this update is a re-write of HNDCMP.APP (CHT Clarion Project Builder). And a new version of HNDCLEAN.EXE (used also by HNDCMP.EXE) now.

There have also been extensive internal checks on all HNDAPPS. We've recompiled all 200+ HNDAPPS from HNDCMP.EXE at least a dozen times in the last week to find potential "gotchas" in the .CWPROJ files for these apps.

We've added, to HNDCMP.EXE (.APP) a cross check that the .CWPROJ file is not littered with old .VERSION file references and/or contains .CLW files that no longer belong to the app. And we've also added an automatic default root icon (the one that you see if you use file explorer to view the .EXE).

If there is an icon for this on the app already, it's left alone, obviously. But if you've forgotten to set one up, HNDCMP.EXE inserts cht_tool.ico. You can always then go to the app's project settings and put your own ICON in here.

HNDCMP.EXE now has a .ZIP option that creates a .ZIP of the .EXE if you want one. This is something you'd use if you have apps that implement the AUTO-UPDATE template feature on EmbedWIndowFunctions.

HNDCMP.EXE now also has an EVT feature which turns off PRE and POST compile settings in the event you have set your app via template to perform some PRE or POST compile operation.

This build is dated Feb 11, 2017, the date that we originally intended to post this... [see next image].


When you've finished installing this, if you have time, we'd appreciate you're taking a few minutes to run /accessory/hnd/hndzindex.exe (CHT Installation Tuner).


This will report 100% up to date if the installation went without a hitch.

We'd also like anyone who has the time to try out HNDCMP.APP on at least a portion of the HNDAPPS. We'll post a separate item here on February What's New showing how to configure HNDCMP.EXE and how to perform an auto-compile test with HNDCMP.EXE.

Gus Creces
The Clarion Handy Tools Page

February 14, 2017


February 1, 2017

Interacting With CHT HNDAPPS

(Un-funking C10's .DCT Location Behaviour)

Somewhere along the line the internal workings of the IDE changed somewhat as regards the location of dictionaries and where the IDE looks for dictionaries.

The interpretation of how this works in the IDE presently, at least as we see it, is ambiguous and, can lead to misunderstandings and what exhibits as misbehaviour of the IDE due to the ambiguity.

We ship all of the HNDAPPS with NO PATH stated in the .DCT name field inside all HNDAPPS that use a .DCT (many of them do use a DCT, many of them do NOT use a DCT).

For example, HNDCMP.APP:


The reason we leave out the .DCT path is obvious. We want the APP to look in the same directory that the APP is located when it loads the .DCT. A path in there pointing to our \hndapps/ location would be silly, because your \hndapps/ are likely located somewhere else on your drive.

WebupdaterC10 gives you control over where you want the HNDAPPS to be located when it installs our tookit.

So when we install the \hndapps/ on your system, we put the .APPS, .CWPROJ, .SLN and .DCT files together. Then, regardless of where you put the \hndapps/, as soon as you load one of our .APP files, the IDE just automatically loads the .DCT from the same location.

Or so we thought. Since that's no longer how it is.

Even with NO path in the .DCT field, as shown above, the IDE WILL STILL go walkabout looking for the .DCT, depending on your IDE settings shown in the next image.


We have no control over how you set the first two fields on this dialog, nor do we want any. But here is our suggestion for a BEST PRACTICE setting...

"Use the last opened solution folder" (leave unchecked)
"Default project location" (leave blank)

When you do check the first field, it will fill in the second field automatically based on your last opened solution, when you next open an .APP or .SLN.

And if you have a value in the second field based on where on your drive you normally work, and then you try to open and load one of our \hndapps/ the IDE will ask you where the .DCT for that app is located even though it's right there in the same directory with the .APP.

That behaviour is funky, to say the least, and different than it once was, in earlier Clarions.

This odd behaviour sneaked up on us, as it probably sneaked up on you. Or maybe we just weren't looking, since we always leave the the Projects and Solutions tab set up as illustrated in the above image:

"Use the last opened solution folder" (leave unchecked)
"Default project location" (leave blank)

Should you be in a position of passing around apps to others on your team, and you have values in these two fields, or if he/she has values in these fields, the .DCT location will be wrong, or a question about where the .DCT is located will pop up, unless their directory structure is identical to yours.

So, since we have no control over how you set these first two "Projects and Solutions" fields, we must seek your indulgence, and ask you to configure them this way (even if only temporarily) when you interact with CHT HNDAPPS.

Gus Creces
The Clarion Handy Tools Page

February 1, 2017


The Latest Docs

(Regenerated Monthly)

The latest template documents (HTML) are here:

CHT Template Docs

The latest demo application docs are here:

CHT Application Docs (Complete)

The latest utility application docs are here:

CHT Utility Applications Docs

The latest BATCH-BOT application docs are here:

CHT Batch-Bot Application Docs

The latest SNAP-IN application docs are here:

CHT Snap-In Application Docs

The latest classes docs are here:

CHT Classes Docs