![]() |
|
Published 1998-04-01 Printer-friendly version
Welcome back!
As the Clarion community slowly works its way through the new directions TopSpeed is plotting for us, here's a little food for thought....
I have seen the above question more than once recently on the TopSpeed CIS forum when a request for help resulted in answer which was brimming with what I call ABC speak - mentions of this method and that property, overriding this and inheriting that, and so on and so forth. Meanwhile, our hapless requestees are more confused than they started out (and it doesn't help that they are usually using CW 2 or the Clarion templates and forgot to mention that). Is this just the standard growing pains of a new version... or does it indicate a more significant trend?
Let's take a simple example that was posted in a recent CIS message by the ever-helpful Stamos D. Fafalios. He was making a different point (that it takes about the same number of lines to accomplish the same thing in both CW 2.x and the ABC libraries), but it will serve just as well for my purposes here.
Each of the following code snippets performs the same exact task: To retrieve the first (and only) record from a single record control file. If the record isn't found, one is added.
Here is your basic pre-ABC code:
SET(config)
NEXT(config)
IF ERRORCODE()
CLEAR(con:record)
!...set any field values...
ADD(config)
IF ERRORCODE()
STOP(ERROR())
END
END
Now let's take a look at the equivalent code using the ABC libraries:
SET(CONFIG)
IF Access:Config.TryNext()
Access:Config.PrimeRecord()
!...set any field values...
IF Access:Config.TryInsert()
Access:Config.Throw(Msg:InsertFailed)
RETURN
END
END
Other than the most basic SET, IF, RETURN and END statements, I think I could easily convince someone unfamiliar with Clarion that they were looking at two completely different languages -- and that is what has been nagging at me: Is the Clarion language being split into two mutually exclusive variants ('standard' and 'ABC')?
Yes, yes - I know that behind the ABC methods are the same old Clarion file access statements that were used in the first snippet. The point is that you are being explicitly warned by TopSpeed NOT to use them in conjunction with the ABC templates and libraries since, in a very real sense, you have yielded control to the ABC library classes which are now managing every aspect of your files.
Is it good that the basic language statements are being absorbed into and replaced by ABC methods? After all, what I call the ABC Language Reference Manual (the ABC Library section of the 'Application Handbook') is already 600 pages in its first release, and it contains many methods which are basically direct replacements for the 'standard' language statements found in the actual C4 Language Reference.
So, do you think it is a worthwhile tradeoff - that it is better to work at a more abstract level through the ABC classes than it is to code in the language itself? Are we ultimately facing a shift similar to going from Assembler to C? C to Clarion? Or, to cut to the chase, Clarion to ABC?
What DO you think? Drop me a line and let me know! I'll publish the best comments pro and con in a future column.
In case you haven't heard by now, TopSpeed released a new CW 2.x to ABC primer near the beginning of last month. Written by esteemed Richard Taylor (TopSpeed Director of Technical Communications), it is one of the most practical guides to switching your mindset from the CW 2.x way of thinking to the ABC collective that I have seen so far. The focus is on "Making the transition to C4's ABC Templates" and it is in a question and answer format.
If you have used the stock CW templates, I highly recommend that you download it and check it out. It is in Adobe Acrobat PDF format, and can be found on the CompuServe TopSpeed Forum as well as at http://www.topspeed.com (look for it on the 'Latest News' page about half way down). The file is named CW2ABC.PDF.
Here are some tidbits and announcements gleaned from the TopSpeed forum and elsewhere over the last couple of weeks. If you see any products here which you would like to see scheduled for a full review in Clarion Online, let us know!
One of the really nice things about using Clarion is the overall generosity of the user community. (Go ahead, all of you give yourselves a pat on the back!) Often, this manifests itself in truly useful templates that the authors have made available to the rest of us for that most favorite of prices: FREE! Each month, this column features a handy free template (or collection of templates) which you might want to add to your bag of Clarion tricks.
Note: If you decide to download and try out any free templates mentioned here, please remember that you get what you pay for - don't expect support from the author like you would from a commercial product. While most of them are generous to a fault (as witnessed by their giving away the template), they are NOT obligated in any way, shape or form to you because you want to use the template. Be nice to them!
This month's jewel is:
This is one of those templates that you never want to need, but when you do need it, you need it bad! What does it do? Glad you asked...
DPL Helper is designed to help you get around the dreaded Dynamic Pool Limits (DPL) which can plague 16-bit CW 2.x and (though not quite as often) C4 Clarion template procedures. What is a dynamic pool limit? Well, look at it this way (an extremely simplified way): As the compiler does its thing on a procedure, it sets aside a number of 'buckets' in memory where it will store various types of information about what it has done so far while compiling the procedure. The problem occurs when a procedure is so big or complex that a bucket 'overflows' before the compiler has finished with the procedure - causing the compiler to give up with a message similar to 'dynamic pool limits exceeded: isl.plists'.
The most common culprit is a Form with a ton of controls on it, since each control generates a CASE EVENT() structure which goes inside the CASE FIELD() structure which in turn goes into the ACCEPT() Loop structure along with the main CASE EVENT() structure (gee, this sounds like a song!). The net result is that there are all of these structures nested together within your procedure and they simply overload the compiler.
The most common remedy is to try and move as much of your embed code to routines, since routines are treated by the compiler as a sort of local procedure (each with its own buckets to fill). Turning off debugging for a problem procedure also sometimes works. In both cases, the goal is to reduce the amount of code/complexity within the main procedure.
DPL Helper works by moving the entire ACCEPT() Loop into a routine. If that isn't enough, it also has a 'Get Tough' option which will further split the CASE EVENT() and CASE FIELD() loops into other new routines. In most cases, by this time you will be able to compile the problem procedure and proceed on your merry way.
New in version 3.0 of DPL Helper is a 'CaseSplitter' template, which they say can help with the 'isl.labs' type of error. It can be used to further split the CASE FIELD() structure into multiple routines. Also included are a version of DPL Helper for complex reports, and a utility template that will add or remove DPL Helper templates from an entire application at one time.
Note that Dynamic pool limits only affect 16-bit applications that use the Clarion Templates (CW 2.x and/or C4 Clarion). 16-bit ABC based procedures rely on the efficiency of the class libraries, etc., to avoid pool limits. After all, a standard ABC procedure now only has one line in the CODE section of the procedure itself:
GlobalResponse = ThisWindow.Run()
Kinda hard to exceed a pool limit with that...
In any case, download the file DPLHELP3.ZIP and check it out if you are a 16-bit CW2.x or C4 Clarion user. Note: You will need a ZIP compatible program to extract the template and its instructions. Also, like any template, don't forget to register it.
Next month: Who knows? You'll just have to come back and find out!
Each month, this column will provide you with the latest in Clarion news, tips, rumors, freebies and basically anything else that seems interesting about the going's on in the Clarion world.
So, who determines what's most interesting? YOU DO!!
Are you a vendor? Let me know about new releases, updates, betas, product plans or anything else you think Clarion Online readers might want to know about.
Are you a user (and who isn't)? Drop me a line about any cool nuggets of information you come across, free templates or examples worth sharing, or anything else that other readers might find useful.
What do you get for contributing? Well, you'll see your name up in lights (phosphor, to be accurate) here in the Bit-vine credits. For especially useful bits, you may even win an autographed GIF of an official Clarion Online shirt or other similarly valuable prize. Come on, how can you resist?
Let me hear from you! The magic address isTomH@ClarionOnline.com
Everything in this column is the sole opinion of me, the author, and does not necessarily reflect the views of this magazine, its publisher, or even of myself (hey, I can change my mind, too!). Don't bet the farm on anything you read here: consider it a starting point for your own inquiries and research. The point here is that this column is intended to both enlighten and entertain, and that in the fast-moving world of software development this month's truth (or product release date) is often next month's "oops, did I say that...?".
'Nuff said!
Copyright © 1999-2008 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.
Clarion Magazine ISSN 1718-9942
One year: $189
(includes all back issues since '99)
Renewals from $139
Two years: $289
Renewals from $239