We're in the process of writing several detailed articles about the use of ListBoxBrowseExtender (LBX) to build local and remote data browses.
We're focussing particularly on the use of Data Base Views as implemented in SQL, since the same data delivery model and mechanism underlies our CHT Client/Server Data Servers.
This first article (linked below) deals entirely with local data at this point using HNDSCHOOL.APP, which you have, and a single procedure in that application that implements ListBoxBrowseExtender on an SQLITE data table containing SQL DATA VIEWS.
The article is can be found here:
The article is also linked on our "Support" page under the section title: "RECENT INSTRUCTIONAL PAPERS (BY: GUS CRECES)"
Feel free to post questions and or discussion about the article, on our developer forum..
We've added to our "CHT Weeklies" list of separately installable CHT componentry, a new "Weeklies" container called CHTWEEKLIES_1.HZO with its own installer CHTWEEKLIES_1.EXE.
The componentry in here is a standard part of the CHT Toolkit and comes up-to-date whenever we post a new CHT Webupdater build or build update.
We introduced these "weeklies" about a year and a half ago, first of all to show off our installer client apps and installation servers. Apps which you yourself can build with a copy of Clarion 10 and the CHT toolkit if you're in the business of selling software over the web as we are.
But the primary purpose of these "weeklies" as regards the CHT Toolkit, is to help keep your installations up to date with the lastest things we're doing that may be moving ahead of the componentry that our "official" installation files and updates are able to include, given that these "official" updates are at a minimum monthly, often bi-monthly or quarterly.
We're moving rapidly now on the development and deployment of our "CHT Document Builder" componentry. Too rapidly to constantly be updating our full toolkit installation on a weekly or even monthly basis.
So we've added this new "Weeklies" component updater to our main installer site (see next image).
As we release videos, documentation, images, and discussion, about "CHT Document Builder" we will refer you inevitably, to this specific Weeklies updater. The one with the red box around it in the image above.
The componentry in here will always be up to date with any of our postings having to do with "CHT Document Builder" should you be interested in trying out some of the concepts discussed.
You can see a list of the current contents of this installation container at the link below.
Note that the paths shown here apply to the install location of our Clarion 10. Your own Clarion 10 installation location will be detected and applied when you run this CHTWEEKLIES_1 installer at your end.
Any questions, feel free to ask.
Here is a flow chart of the CHTSNAPEDIT.EXE portion of the CHT Document Builder toolset.
Of course this set of 5 steps, as the image indicates, describes five steps for Manual Document Creation.
We can, of course, perform Programmatic Document Creation by replacing Step 1, above with app-generated content of any kind. Our CHT Document Builder system is able to equally easily create viable, responsive HTML documents, based on the design and layout from the chosen XML template file, embedded into programmatically, rather than manually.
CHT is in the process of creating a variety of XML template files that may be used as-is to generate HTML documents.
Most likely, the developer will want to make a personal copy of our XML templates, under new names, and tweak the CSS in them into designs closer to their own personal or company requirements.
At time of writing we have XML templates for:
Near future features:
In this month's build update (21C.01.00) about which you'll hear more in the coming days we're further developing our "Next Generation" features particularly in regard to a group of capabilites we've grouped around "CHT Document Builder" and "CHT Snap Edit".
Using the latest version of this capability we've set up a number of pages on our website that conform to the standards of "Responsive Web Design" discussed here on our August What's New page.
The idea is to create web pages and forms that only need to be designed once, regardless of the device size and type.
These pages are clearly distinguishable at
www.cwhandy.ca by the distinct header image which we've placed there for the purpose of easy identification.
We've tried these "responsive design" pages here on several devices, mostly phones and smallish tablets to see if they conform. Pass or fail is judged entirely on whether the contents of the page are FULLY available, readable, useable on all devices regardless of device size without EVER having to use horizontal scrolling. All text, images, fields, links, and so on, fit the window even on small phones.
Primarily in our case legibility is a important issue since at our age, the old eyesight isn't what it used to be. We don't want the page (looking from the phone) to appear as if we are viewing it form across the room. The web page should not zoom out to accommodate fitting the smaller screen. The page should wrap and adapt it's shape to fit the screen while the font sizes are not diminished or reduced.
And finally, there should only be one version of the page. Not a separate version for each device.
Below are some screen snaps from our Nokia phone to prove the point. We're holding the phone in vertical mode as the snaps are taken. These pages, are clearly all completely readable, large enough for navigation with fat fingers and a pleasure to interact with.
More later with more details on our August What's New page.
To test this try our website on your phone at the url: http://www.cwhandy.ca
As of 5pm EDT August 11th, 2017 -- we've just finished posting and download testing the 3rd quarter 2017, CHT build update, numbered 21C.01.00.
Our installer creates a "The Clarion Handy Tools C10" folder on your Win 10 machine which you can find in the "T" section of the Windows Menu. (see next three images)
CHT WebupdaterC10 is near the bottom of this list as per the last image above.
That's all for now. we'll be sending around a summary email to all subscribers in the next week, as well as posting information on our Subscriber Forum and here, on our August What's New Page.
Any questions, feel free to ask.
Responsive web design makes your web page legible and useable on all devices.
Responsive web design uses only HTML and CSS.
Web pages can be viewed using many different devices: desktops, tablets, and phones. Your web page should look good, and be easy to use, regardless of the device. Web pages should not leave out information to fit smaller devices, but rather adapt its content to fit any device:
It is called responsive web design when you use CSS and HTML (only) to resize, hide, shrink, enlarge, or move the content to make it look good on any screen.
The viewport is the user's visible area of a web page.
The viewport varies with the device, and will be smaller on a mobile phone than on a computer screen. Before tablets and mobile phones, web pages were designed only for computer screens, and it was common for web pages to have a static design and a fixed size.
Then, when we started surfing the internet using tablets and mobile phones, fixed size web pages were too large to fit the viewport. To fix this, browsers on those devices scaled down the entire web page to fit the screen. This was not perfect!! But a quick fix.
Web pages handled this way often feel like one is reading an
8 1/2 x 11 sheet of paper from across the room - zoomed out too far. The whole page is there, but it's too far away to be comfortably read.
HTML5 introduced a method to let web designers take control over the viewport, through the
To incorporate HTML 5 "ViewPort" support, you should include the following
<meta> viewport element in all your web pages:
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta> viewport element gives the browser instructions on how to control the page's dimensions and scaling.
width=device-width part sets the width of the page to follow the screen-width of the device (which will vary depending on the device).
initial-scale=1.0 part sets the initial zoom level when the page is first loaded by the browser.
Here are two screen snaps, of the same a web page viewed on the same smart phone, one without the "viewport" meta tag, and the other, with the "viewport" meta tag.
Users are used to scrolling websites vertically on both desktop and mobile devices - but not horizontally!
So, if the user is forced to scroll horizontally, or zoom out, to see the whole web page, the result is a poor user experience.
Some additional rules to follow:
Do NOT use large fixed width elements.
** For example, if an image is displayed at a width wider than the viewport it can cause the viewport to scroll horizontally. Remember to adjust this content to fit within the width of the viewport.
Do NOT let the content rely on a particular viewport width to render well.
** Since screen dimensions and width in CSS pixels vary widely between devices, content should not rely on a particular viewport width to render well.
Use CSS media queries to apply different styling for small and large screens.
** Setting large absolute CSS widths for page elements, will cause the element to be too wide for the viewport on a smaller device. Instead, consider using relative width values, for example, width: 100%. Also, be careful of using large absolute positioning values. It may cause the element to fall outside the viewport on small devices.
There's more to say about responsive web design. We'll do that in some near-future posts in these "What's New" pages.
Here is some sage advice from Microsoft for designing flexible windows that don't need to be re-coded for every device.
Of course, this pertains primarily to browser-based windows and forms but since app development shouldn't only be targeted at the Windows Desktop (even though that's really all Clarion is designed for), there's more than one way to skin a cat.
A couple of examples of "skinning the cat" in this regard are two CHT Tile Menu demos that we gave you with the last build update on July 11th, 2017.
These two applications are: HNDPEOPLE_LBX.APP and HNDTILEAPPLAUNCHER.APP.
The MAIN screens in both these applications were designed using HNDDOCUMENTBUILDER.APP (and CHTSNAPEDIT.EXE) using the principles of a "flex-screen" design as proposed in this Microsoft article, that works across a range of device sizes without fore-knowlege of the screen on which it is going to be displayed.
The following two images are screen snaps from this Microsoft "Screen Size" document to give you a taste.
For the next build, we have new demo applications that will illustrate a couple of screens -- we call them documents -- that run inside a Clarion window and collect display information -- user-specific data mixed with fixed text -- by calling a stored procedure on a CHT server.
We'll tell you more about those in upcoming posts.
We've completed the work (for the upcoming 21C.01.00 update) to have the ApplicationSnapIns template highlight with an alternate color, any Snap-Ins, Batch-Bots and CHT Utility Executables that you may have included with your application.
The above color highlights result from setting the "Enable" switch on the two Snap-Ins that are highlighed.
As soon as you include one of these ApplicationSnapIns, by setting the "Enable" switch and the color highlight appears, your generated Clarion .SHP file automatically shows them to be part of your application -- after a complete app regenerate of course.
So far so good...
Now the second switch provided on every SnapIn has to do not only with reminding you that this binary is required by your application.
The "Copy to outPut directory" (a separate switch shown above) directs the IDE to copy that .DLL or .EXE into your application's compile target directory. (the directory where the IDE is told by redirection to copy your compiled application). This "copy" switch cause two things to happen.
It causes the CHT binary to appear in your "Libraries and Objects" list as in the next image.
It causes the CHT binary to be copied into the app's output directory as in the next image.
Our template depends on Clarion's .RED (redirection system) to properly find the ship location of our binaries in /accessory/bin/ and copy the binaries from there to the configured executable output directory of your Clarion 10 configuration.
The .RED file's default settings are not normally adequate to find these CHT binaries without a little assistance from you.
Here is the .RED files default [copy] setting:
Note that it does not include /accessory/bin/ as a place to look for binary copying and note too that it does not incorporate the copying of .EXE files, only .DLL files.
To get [copy] to work correctly for you here is a modified .RED setting that will make your IDE conform so that our templates can fully do their job for you where our CHT Snap-In binaries are concerned.
The IDE's redirection system is a marvellous piece of magic that allows Clarion templates to do stuff for you, but .RED is under your control and the defaults are not necessarily always adequate. We make a point of NOT programmatically messing with your .RED file, preferring to leave control of the magic in your hands.
BTW, the 21C.01.00 update is still scheduled for Aug 11, 2017 at this point.
We are working on some advancements to HNDDOCUMENTBUILDER.APP and spotted a new feature in our "ApplicationSnapins" template that we haven't mentioned and should point out. (see next image)
In build 21C.00.00, (the latest build as of July 11th, 2017), when a CHT Snap-In has been incorporated into the app, the template interface presents the name of that Snap-In, in a second color. That way, it's easy to tell at a glance which ones are part of your application.
Presently this is implemented only on the "Snap-Ins" tab that you see above, and not yet on the "CHT Batch-Bots" and "CHT Utility Executables" tabs. By the next update 21C.01.00 scheduled for, approximately, August 11th, 2017 we'll have these other tabs doing the same kind of easy-to-spot presentation.
Indirecly related to this, we're working on a Batch-Bot (Batch Bots are Clarion based, Snap-Ins are C# based) at the moment, that can be run from inside any app, or from the DOS prompt or from CHT Snap Edit, which takes over all of the XML to HTML conversion duties presently included in separate procedures inside HNDDOCUMENTBUILDER.APP and HNDBULKNETMAILPROMO.APP.
That won't change the functionality of these apps, it merely abstracts the XML to HTML conversion into a separate Binary Executable that can be run from any application. (Hint, hint, say from a server app packaging data into HTML using a CHT XML template.)
If you're not sure what the heck we're talking about, watch the 4 videos we posted recently using your HNDVIDEOPLAYER.EXE located in /accessory/hnd/.
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: