Our Servers Have Moved
Our Servers Have Moved
The next build 27B.00.00 is scheduled for release May 24, 2023.
Suggest you read the forum messages we have posted, marked "FEEDBACK" as well as all new messages being posted on our new forum.
We're in the process of categorizing over 360 CHT Templates into TIERS or LAYERS. Each higher TIER represents an incremental level of sophistication, with the first two tiers encompassing pure desktop development: for example, building desktop browses, forms, reports and processes.
Two templates from TIERS 1 and 2, that all of you use, are: ExplorerBrowse (EXPB), and HandyMarkerBrowse (HMB). These templates are attached to ordinary ABC browses to extend their capabilities well beyond anything SV is doing with its ABC browse templates.
In TIER-3, we include ListBoxBrowseExtender (LBX) among other things. This browse looks and behaves like HandyMarkerBrowse but is NOT BUILT on top of an ABC browse, and therefore, does not inherit the ABC browse's built-in limitations. LBX can also create ordinary desktop browses with sorting and filtering features beyond ABC, but that's just the beginning. LBX browses do not neet to rely exclusively on Clarion file drivers. LBX can access data through ABC file drivers if you want it to, or it can access data from a nearby or remotely placed CHT server. LBX can be web-enabled.
TIER-3 and TIER-4 deal extensively with exercising the Web Enabling capabilities of Clarion Handy Tools. Check the following three links to see which CHT templates have been placed in which tiers, we think that TIER LAYERS will help you implement CHT Templates to their fullest extent.
CHT TIER definitions will help you analyse the apps that you have already built to see were they fit complexiy-wise. How many of our upper TIER templates are you actually using? We'll explain more as Build 27B.00.00 release nears.
So far, we've gone through seventeen CHT DEMO and UTILITY applications with an eye to removing the red icon that Clarion puts on procedures with HAND EMBEDS in them. The cause of HAND EMBEDS is the simple, unavoidable fact that a template cannot anticipate absolutely everything that developers might want to do with a control or extension template. "EMBEDDING" has been the long-accepted way to add code-based functionality to the app that isn't hard-wired into the template-generated code.
The following four templates are new as of this build. They are provided as convenient CODE-TAB platforms that allow the developer to insert code into procedures in a way that has never been possible without HAND-EMBEDDING.
The following, pre-existing templates have had "CODE-TABS" added as of this build. These templates operate exactly as always when any code tab edit field is left blank. Even then the standard generated code remains as it always was.
Only when a CODE-TAB edit field has had code inserted, is that code placed on the developers behalf into the PRIORITY procedure area indicated by that CODE-TAB.
A good example of the "unavoidable fact" that sometimes HAND-EMBEDS are necessary, is the ABC BUTTON CONTROL TEMPLATE. With this particular control template, you can do two things only:
1- Start a procedure
2- Provide an optional procedure parameter
There is no provision on the ABC button CONTROL template to insert any code before the procedure is started and no provision to insert any code after the procedure is completed.
To deal with any potential "BEFORE" and "AFTER" code requirement one has to open the procedure, enter the EMBEDITOR, and insert some hand-code manually, into those before and after positions. That hand-code is what we've always called, an "EMBED".
Embedded procedures display a red icon against the procedure name, indicating that there's at least one HAND-EMBED somewhere in the procedure.
If one now removes the ABC button control template under discussion, the button-related hand-embeds are still there in your code unless you chase them down using the ORPHANED EMBED facility provided by the IDE, at which point, you can then manually remove them.
What if that ABC BUTTON template provided two TEXT fields in the template interface to place code BEFORE and AFTER the procedure call?
The developer writes or pastes some code into these BEFORE and AFTER text fields and that code is inserted by the template into the correct location inside your procedure. This way of placing the same code, does not cause a red icon to appear on the procedure name, because there is, technically, no HAND-EMBED. All code issues from the template.
Your code is inserted by the template and is also removed when the template is removed. Hence, no orphaned embed hangs around when the button placed using the template is removed from the window.
Your specialized code can still be inserted as if by hand-embed, but that code now belongs to the template. It's placed by the template and removed by the template when the template is removed.
This is a simple example, but it easily makes the point. Many templates, in addition to writing the code that they traditionally do and have done, present specialized embed points into which developers can embed code by hand in case there is some functionality that needs to be added into what the template generates on its own.
We've gone, as mentioned above, through seventeen CHT applications, present in our suite of example and applications. These applications included many "unavoidable" instances of HAND-EMBEDS that furthered or enhanced the behaviour of template-generated code.
These HAND-EMBES were things that the template might not readily anticipate ahead of time, at least not without over-complicating the template interface or making template behaviour too specific and too inflexible.
To the new templates, we've added one or more of what we're calling "CODE-TAB"s. For easy recognition we've made the word CODE that appears on the template tab, a slightly larger font, and colored it RED. The template tab provides a place for developers to drop code into a documented text field. Each text field tells you briefly into which template-related embed location the added code is about to be inserted.
These CODE-TAB text fields can be ignored and left blank without impacting your application at all. Or developers can drop code into the them. In this way, existing apps, where extra code is not necessary, are not impacted. Nor do they need to be touched. But when developer-deployed code related to the template is required, that code may be inserted onto the template via CODE-TABS, to take the place of traditional, more loosely associated hand-placed-embeds.
Developers can also drop comments as we've done in some places in our demo applications, to illustrated that the code or comments are placed where they should be.
Plenty Of Examples
At release time of our 27A.03.00 update, we will provide you with a substantial list (shown above) of demo applications that we've made embed-free via this CODE-TAB technique using new and existing CHT templates outfitted with CODE TABS.
The distinguishing feature you will notice when you open these examples, is that the procedure names do not have red icons indicating hand embeds. The CHT templates on these procedures (some of them) will have red CODE tabs, some with code in them that you can find generated into the procedure itself.