CHT Build 26D.01.00
When CHT users post a problem to the subscriber forum or via email, we test the reported issue here in various ways, in order to provide some answers, some guidance or perhaps to make a CHT modification. Below are a described two modifications available in the upcoming 26D.01.00 update.
We removed an obsolete template variable in Explorerbrowse that under certain conditions, having to do with which template dialogs were completed, caused a non-critial template error to be thrown at generate time. The developer testing this has reported success with the changes made for 26D.01.00.
We've modified the images search routine which sniffs out images with paths in your applications and reports them to you in a set of files.
CHT's Global template AACHTControlPanel provides two separate dialogs reporting to two separately generated files, the names of images it finds in your application.
This is very useful intelligence about your application available to you as needed, since the procedure name or the CHT template incorporating the image into your app is reported at the same time. This feature is a real development-time-saver especially if source apps are shared as well as co-developed, so that source images have to be transported with the app source.
These dialogs may be found as follows:
Open "AACHTControlPanel" -> Select the "Information Tab" click "Application Images".
This is a template-generated HTML page listing the images, and, if any, the image paths, that our template-based image sniffer routine has found in your application. The HTML page displayed, provides an explanation, that devs should take to heart when it comes to the practice of embedding images in your app which contain path names.
"Above, is a list of images found in your application. Assuming default, .RED settings, one of the things that makes an application less portable than it might be, is referencing images that are not in your / accessory / images/ directory, since Clarion stores such images in your app with a path name, and anyone trying to compile your application on a different machine may not have those images on that particular path."
"To make your application more portable, configure CHT's ApplicationImagesEx template to copy all the images in your app to a standard location or to the /accessory / images/ directory so they're all in one place instead of scattered all over your drive."
"Clarion templates, however, are not given write access to your screens in order for us to remove embedded paths automatically from the image names. So it is in your interest to maintain application portability by checking for images with embedded paths and removing the path which will no longer be necessary once the image has been copied by the template to / accessory / images /."
"Images listed above, showing a path, are candidates for your attention. As long as a path is part of an image's description, inside your application, it will cause a hassle for you should you want to move the source application to another system or to a client's computer."
"To remedy, go to the procedure or template named and remove the path from that image."
Open "ApplicationImagesEx" -> Select the "Image + Style Settings StyleSheet" click "IMAGES" tab to see a list of images embedded in your application.
The same rules apply to this list as described above. Images in your app with paths in their names are listed here as above along with all other images found in the app.
CHT template prompts having to do with the selection of image files, automatically strip any incorporated paths from those images and also automatically copy the image to / accessory / images / where the IDE is able to find it without the necessity of a path.
Automatic path stripping and cross-copying is obviously not the case with images populated into your app from, non-CHT templates or from standard IDE image controls. Our templates can see and read these image location values, but CHT templates are not given access, internally, to modify these protected values when paths are found. Hence our template reports paths + image names to two user-accessible report files visible from our templates - "AACHTControlPanel" and "ApplicationImagesEx".
Our image path sniffer routine has been modified to be more robust when writing to the output report files. Previously, applications riddled with path-containing images names, caused the routine to be called in a manner that was more frequent than the IDE template engine could handle, leaving behind an open file handle resulting in a template-generation error.
We've modified this routine with more robust code that now tolerates multiple, successive, calls and will not throw an error as we had it doing. To test the new design we built an app called "hndfullofimages.app" which is included with 26D.01.00. The app contains Clarion image controls with paths in the image names.
By way of verification, the app successfully reports the erroneously pathed images to both of the CHT TEMPLATE DIALOGS described above. None of you will be able to compile this application because the paths at which these images are located, we're sure, do not exist on your hardware. This example kind of proves our point that images with embedded path names, just will not compile on other machines until the paths are stripped.
We've been testing and modifying CHT templates ExportProcedure and ImportProcedure as a handy means of transferring procedures from one app to another, say from one of our HNDAPPS examples into your own app. You may be aware that Clarion's internal import from another app is not up to the job. I alluded to this procedure import capability in my last CHTTODO.CLW writeup, that our demo apps were loaded with potential JumpStart procedures, available to be exported from our apps and imported into yours.
The built-in IDE template export procedure will export our procedures OK, but due to a Clarion template system bug, the Clarion template system's native template export does not automatically strip templates with the "REQ" tag. This results in any template with a "REQ" tag being double- populated on the procedure when imported. The IDE doesn't check at import time whether the "REQ" tagged template is already in the procedure and inserts it again.
This is a known Clarion bug in all versions of Clarion up to and including Clarion 11.1.
Our specialized ExportProcedure template scans your procedure and strips CHT "REQ" templates from the exported TXA since "REQ" templates will be auto-populated back into the procedure at import time by the Clarion template generator.
Use CHT "ExportProcedure" to export a desired procedure from one of our apps -- for example, from hndcpydm.app -- and then use CHT "ImportProcedure" to import that same procedure into one of your applications. The CHT "ImportProcedure" template knows the name of the template just exported so there is no export file name to remember once you're back in your app.
With standard IDE import routine you will be fumbling and looking for a file name and location.
Most importable CHT procedures -- from hndcpydm.app, for example -- expect certain global CHT templates to be present in your target application. To determine what these are, go first to the Global Extensions tab of the source app and incorporate into your application the same set of CHT Globals found in the source application. In this 26D.01.00 build, we've provided a candidate import application called hndstubwindow.app with which to practice. You can experiment with using the import technique described here. This app contains the necessary CHT Global templates.
Some of these importable procedures in hndcpydm.app expect a dictionary called hndcpydm.dct to be attached to the application as well. You can tell by touching the procedures in hndcpydm.app which of them incorporates table usage.
These same rules outlined about apply when you want to transfer procedures between apps of your own making. Use Exportprocedure to export from the source app and ImportProcedure to import to the target app. The IDE will nag you to make sure that the correct dictionaries are in place. It'll all work as expected if you follow the guidelines.