HNDVIDEOEDUCATION.APP and HNDVIDEOPLAYER.APP have been redirected to http://server101.cwhandy.ca:5000. The SERVER and URL they were directed to were put to other purposes some time around mid-March 2019 so these apps have been unable to connect for a few weeks. In this build the newly applied url puts them back into service.
New Demo Application Just Introduced: HNDTYPE4SERVERPEOPLE.APP
This is a Type 4 example page server that publishes the "PEOPLE" table from HNDO.TPS. It publishes just two different pages, a browse listing records from the PEOPLE table, and a READ ONLY form that displays one record (when selected on the browse) from the PEOPLE table. This follows exactly the Clarion browse/form paradigm.
This is a TYPE 4 server, so it is a read-only public-access server. Data displayed is not editable or changeable from the browser.
Page design is such that it will display quite legibly in browsers based on phones, tablets and desktops. Imagine it providing public shopping pages or public lists of all sorts.
This CHT server app is a perfect learning opportunity for Clarion developers wanting to break into HTML web browses and forms that will run on any browser-based device, a phone, a tablet or standard desk-top.
100% of page design is controllable, and previewable from CHTSNAPEDIT.EXE, (+HNDXML2HTMLGEN.EXE +HNDPREVIEWER.EXE) based in the two .XML files mentioned below.
The server's two page designs are based on two XML template files: 000PEOPLEBROWSE.XML and 000PEOPLEFORM.XML located in our installation \accessory\hnd\xml\ directory.
Procedure XML2HTMLPeopleBrowse() generates a browse table into XML embed point
Procedure XML2HTMLPeopleROForm() generates a read-only data form into embed point
• (The server application)
• (The server dictionary)
• (The server data file)
• (copied to server root on server start)
• (copied to server on server start root)
• (copied to server root on server start)
This build was released late last week, a few days early. The "official" release date of this build is, however, April 2, 2019, as it falls within the first week of the second quarter of 2019.
As always, the letter incorporated into our build number represents the current year quarter:
23A = First Quarter (Jan, Feb, Mar)
23B = Second Quarter (Apr, May, Jun)
23C = Third Quarter (Jul, Aug, Sep)
23D = Fourth Quarter (Oct, Nov, Dec)
See the second section below, for details from our updater notebook to get a more expansive look this build. Of course you will receive those same notes on your desktop, as soon as you complete an update with the latest CHTSETUPC11.EXE or CHTSETUPC10.EXE.
HNDSLFSV.APP has been revised to be a pure type-4, file server. It acts, as before, as a flexible web page, public web-site server. Page servers are, after all, file servers, first and foremost.
A server-level login dialog has been added. This dialog creates a 2-part server-level user name, password intended to limit server interactions from CHT clients wishing to send files into or fetch files from, the server root or any directory below the server root. With this design the server can act simultaneously as a public web-site server as well as an installation server that requires the installation client application to have server-level permission to acquire the installation file(s).
HNDSLFCL.APP has been revised to be a pure-type 4, file client application. It illustrates two HNDCLIENT upload methods and two HNDCLIENT download methods. Access to the server for either upload or download permission is password controlled by a two-part user name, password, combination determined on the server.
This is a simple, single-file-at-a-time client. It can place files into or draw files from any the server root or any directory below the server root. A login dialog has been added. The 2-part user name, password combination entered here must match the same 2-part user name, password established on the server, before access is granted and file transactions may take place.
HNDSLFCMD.APP has been revised to be a pure-TYPE 4, file client application. This application is also classed as a command-line "BATCH-BOT". It may be used as part of a DOS batch file, manually from the DOS command line with command-line parameters, or hooked into another Clarion application using CHT global template "ApplicationSnapins". This application displays the required command-line inputs when the application is run with no command-line parameter. A splash screen pops up followed by a text file containing these instructions.
To test these three applications locally, set up HNDSLFSV.EXE (the server) and point it's root directory at say, c:\web\. Pick an IP from the server's IP dropdown and a port. Configure server security by clicking the lock button on the toolbar. The username and the password are up to you - (write them down). Now start the HNDSLFCL.EXE application and configure it's login dialog with a user name and password maching those established on your server.
Enter also the IP address of your server, prefixed with http:// and a port also configured as configured on your server. When you close that dialog with the "Save" button the client app will connect to your server if the login information it was given matchs that established on your server.
We've re-worked CHTSNAPEDIT.EXE so that it now can work independently from your Clarion Installation in a root exe directory of your choice.
This application works in co-ordination with four other CHT applications when designing web pages, it requires a directory structure below the CHT Snap Edit executable directory.
For example, suppose a server root directory called c:\chtsnap\ (your choice)
c:\chtsnap\ - (root directory)
We've created a separate installer (chtsnapedit.msi) that installs all of the necessary components including some example .XML style sheets.
You have enough components in this CHT 23B.00.00 update to set this up yourself and run these components from, say, c:\c11\ or c:\clarion11\ or c:\c10\ or c:\clarion10\.
However, to obtain a separate installer containing only the components described above, you can obtain the .MSI installer at this URL:
The default stylesheet shipped with this .MSI installation is called 000example.xml. It contains comments and explanations for some of the key XML embed points. Other style sheets provided let you quickly build a navigable website with five items in the main menu.
When developers populate a standard Clarion control to their application window, certain basic window controls carry along with them some built-in control-template behaviours. Let's consider for example, vanilla button and entry controls.
There's nothing wrong with these built-in control template behaviours, of course, they help developers to more easily make use of the basic screen control, without having to write code for some rudimentary functionality hooked to that control.
There's one problem related to this situation, that detrimentally affects 3rd party developers of control templates and the developers that use them.
Third party control templates, regardless who they're from, often use basic controls with new, non-standard behaviours hooked into them. We have tons of these (153, to be exact). When we create one of these control templates, we really don't want the default ABC control template dialog to interfere with ours. In all cases of our control templates, the default ABC control-template interface is irrelevant and can be ignored.
If the default ABC control-template interface COULD simply be ignored that would be fine by us!
The problem as we see it is two-fold. First, the Clarion 10-11 IDE configuration that makes these ABC control-template interfaces (supposedly) go away and leave us alone, is broken. We doubt that it ever worked. The ABWINDOW.TPW template seems to make no reference to any setting that makes ABC built-in control template code defer (give way to) third party control templates. The image below illustrates the IDE switch that is supposed to remove the ABC control-template interface from vanilla controls that third parties have put their own template interfaces to.
The ABWINDOW.TPW makes no reference to any IDE setting that would (should) make default ABC control templates defer to third party control templates hooked into a window control (as the above setting implies it should).
We said above, that the problem is two-fold, and it is. Since we can't make ABC control templates go away when window controls have been decorated with new behaviours from CHT control templates, the least the ABC default control template interface could do is co-operate with our control templates and those from other third parties, and not monopolize the template interface workspace.
In the two images that follow, you can see what happens when we create control templates with a standard button control and a standard entry control. Badly thought out and badly designed ABC "junk" puts itself under our sheet-and-tab control-template work surface, in a get-in-your-face way that trashes the neighbourhood.
Remember, non of the ABC control template "junk" that hangs itself below our template tabs is required in this situation. Particularly in the entry control pictured in the image directly above. Our template code handles all the necessary details and the default ABC stuff is superfluous to our application of the entry control. The default ABC entry control template interface ought, really, to be hidden, tucked away, or taught some manners.
Ideally, the ABC-default control template interface ought to be laid onto a #TAB control that makes it appear as just another tab in a multi-tab template interface. This works with raw window controls, undecorated by specialized window control enhancements as it will display the interface on a neat, single tab. It works equally well with multi-tab control templates from third parties like ourselves by tacking an "ABC" tab onto the end of our tab set. The image below illustrates how this works.
We're providing a minor change to ABWINDOW.TPW that does not change ANY of the native generate behaviours, attached to vanilla window controls.
ABWINDOW.TPW control templates continue to work exactly as always whether in the context of CHT templates, or in the context of other, 3rd party template, or with no 3rd party templates at all!
We just taught them some much-needed manners!
Unless you use exclusively development tools only from the Windows store, you probably have your Windows 10 set to "Developer Mode".
Developer Mode lets you "Install any signed and trusted app and use advanced development features". So says the "For Developers" dialog in Windows 10 settings under "Update & Security".
Clarion developers and consequently users of 3rd party Clarion tools, need to set their systems up in "Developer Mode".
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: