Experiences with the Use of Causeway
Vector 12:3, page 47
Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 47
Introduction and Orientation¶
A causeway (according to the dictionary) is a paved way (derived from the Latin ‘calciata’ meaning as much as ‘chalked’ or ‘paved with lime stone’). In modern times, I assume, it is a highway or turnpike with fly-overs and rest areas. I am a naïve user because I am not a professional computer scientist but just somebody who needs software for his (or somebody else’s) applications. I showed very naïve indeed when I first started with Causeway in a rather large and complex application: a pension fund administration – not as a free choice, it just fell on my route like manna.
I didn’t know Causeway (who did outside Swansea, UK?), except from reading Adrian’s article in Vector and later Duncan’s. I just trusted the promises and accepted the assignment.
I know most ins and outs of pension funds, have a few years’ experience with Dyalog APL/W, but knew little of the internals of Microsoft Windows (I’m just a ‘clicker’). I bought myself the recommended book ‘The Windows Interface, An Application Design Guide’ and started.....
Why did I trust the promises? Adrian Smith is one of my first APL teachers (although perhaps he doesn’t know so). His book ‘APL, A Commercial Design Handbook’ is on my shelf (it wasn’t for a long time, since it was on my desk), together with ‘APL, the Language and its Usage’ (Polivka, Pakin) and ‘APL, An Interactive Approach’ (Rose, Gilman).
First, I needed to adjust my home-made character-based database management system (because there is so much functionality specific to the kind of applications and so little overhead that I prefer this above a manufactured one).
Here already the approach of the Causeway-design paid off (that’s what I mean by the presence of rest areas: it pays off to carefully look around and to look inside). I re-designed my dbms in a structure similar to the design of Causeway: fully table-driven, using the TextMatrix Grid object, and stored all the functionality in a filetab (similar to classtab, styletab, domain, etc.), containing file and fields characteristics, constraints, display and storage formats, and so on, and even code as much as I want ‘outside’ the workspace; it has 12 columns now.
Browsing through the Causeway system I came across another word for which I needed the dictionary (remember I’m Dutch): ‘holler’. What does ‘holler’ mean? The description in the dictionary and the functionality which I found out made me think of a long forgotten public service which I remembered from the (in those days) remote and isolated little village in the SW of Holland where I was born: the bell-man. Loudly and clearly make everybody know the important changes in life!
Appearance¶
If one is going to use Causeway seriously I would recommend to install the Causeway font. (Guidelines come with the product.)
Warning: if you are also a user of Rex Swain’s WSFIND this function fails under the Causeway font (how can this happen?) and you’ll need to modify this function. The Causeway font is a piece of beauty (of the already beautiful design of the APL character set itself) and certainly makes APL more approachable, due to the locations of the characters on the keyboard (e.g. <commute> with Shift+Ctrl+t).
Customizing¶
Naïve I showed when I thought I needed a multi-line TextMatrix Grid: I had to adjust the NavGrid function (there is very instructive code in there!), and thus, I had to dive in the deep right away. I learned a lot about Causeway, how it was built and how to customize it to my own needs. I came across the DT-domain, which had been copied from Microsoft Excel, on its turn copied from Multi Plan, and discovered that the year 1900 is a leap-year! (Is this why Dyalog’s dates stop backwards at March 1,1600?. Keep away from leap-years!). Result: all your dates display one day short, if you did a correct conversion (e.g. from old data), that is. Pension funds have a long range of dates and periods: from say 1890 until far in the next century, and many ways of treatment of dates. Thus, you better write and add your own (dates) domains as needed. It was stated in the guidelines that Domain had not been generalized.
Designer¶
The Dbx-designer is a miracle. It works! and it works efficiently, at least and certainly for a rough design. Refinements can be made afterwards easily by changing values in the ‘dbx_xxxx’ variable by use of enclose and pick, e.g.
in order to change the size of the main Form, or
in order to change the call-back function of the first event of the fourth object, or
and so on. (I do not understand why the order of the columns shown in the designer is different from those in the dbx-variable.)
Use in Practice¶
The ease of making and positioning all objects and decorations: designing the main menu, designing menus for the right mouse button, messages in the StatusBar, ProgressBars, etc. is amazing. There is a rich choice of objects, styles and prefab-ed events.
Cloning, aligning, the Snap of 1, 4, 8 are all tools which make life comfortable.
Then, as soon as you’ve designed some of these dbx’s, you may choose lines from existing and copy them into new ones, or use several lines as a ‘template’, i.e. often the first few lines. For the application I built there is a certain pattern: most dbx’s have an identification (of the participant) section, a combo selector (for selecting by name), a data section, an annotation, a control section (action buttons) and a status bar (sometimes also a progress bar). This ‘geography’ shows that some of the sections are shared by most dbx’s.
Further, you might write a function to ‘sort’ the dbx: take care that the FM (Form) is on top, next is the Combo Selector and the remaining ones are sorted by group and/or position. The result is such, that the user always has the first focus at the Combo Selector and that sequential focusing by Alt+Tab is always in the order of the relevant objects. I also wrote a function to discard redundant classes from the classtab: this often saves a lot of space in your workspace.
Performance¶
The sting is in the tail. Once you have designed the dbx’s they let you wait! Performance, that is, emerging of the windows on your screen, needs more than ‘a touch more’ compared to directly designed dbx’s. (They behave well on a Pentium 75Mhz and up.)
A few hints:
- be moderate in the number of objects in each dbx (max. 15 to 20).
- use ‘Hide’ and ‘Show’ commands in a particular session. Once the dbx has been created it’s much faster to make it visible and unvisible.
- try to be efficient in ‘hollering’ variables and ‘refreshing’ objects, avoid redundant execution of (call-back) functions.
Support¶
The Help is omni-present.
The support (which you definitely will need: after three months working with Causeway I still find little spots and stains) is informal but professional, fast and to the point, completely in line with the style of support you are used to getting from Dyadic. They (Adrian and Duncan) manage to give support with a personal ‘touch’ and in relation to the ‘contribution’ (what else is $50 for such a sophisticated product?) of high quality and – as they put it in their ad – provide a ‘shoulder to lean on when times get hard’.
Conclusion¶
My conclusion is that Causeway is a high-sophisticated product which only has its equals in APL (or J) itself or in Dyadic’s APL interpreter, and which could lead to a renaissance of APL in many regions. At least the customers are surprised and like the results!