Scor­pio News

runtimes. Not a problem for an individual writing programs for himself, but when it comes to commercial use of either, Clipper is to be preferred as the end user doesn’t have to pay anything for the licensing of the compiler’s runtimes. Mind you, neither of these compilers is what you might call cheap, Clipper comes in at about £600, whilst Foxbase doesn’t give you much change out of £400, so you aren’t likely to buy either for fun.

My Stateside contact had recently confirmed Foxbase to the bin, as the disadvantages outweighed the advantages.

I know very little about Quicksilver. Paul is pressing me for copy (I said I wouldn’t get round to finishing this article before the copy deadline) and I shan’t lay hands on Quicksilver until next week. From what I read in the adverts, there are two things going for it. Firstly, not only are the database structures compatible with DBIII+, but the indexes are compatible as well {with Clipper and Foxbase, the databases are compatible, but the indexes aren’t); secondly, it has I/O commands, the equivalent of BASIC’s INP and OUT instructions. Not a major plus perhaps, except I have need of I/O commands in something I’m doing, and to be honest, I still find assembler patches in 8086 code a grade one pain (all this register lark). I haven’t found out the bad bits yet, like the size and speed of the code, or compatibility of licensing arrangements, etc.

So that leaves us with Clipper. As I said, I’ve become intimately involved with Clipper over the last year. What can I say, it does the job – it compiles DBIII+ source with very little incompatibility. Ok, so it’s not entirely compatible, I have to keep in mind that what I’m writing is going to end up compiled so that some of the quirks are accounted for.

Some of the incompatibility of version of Clipper appears to have come about by Nantucket being a little previous. It seems that my version was written around DBIII and then the designers thought, ‘Wouldn’t it be nice to include this, that, and the other.’. So they went ahead and added some nice bits, including windowing, box drawing and the ability to detect what particular key was used to exit from a GET statement. All worthwhile enhancements of DBIII.

Unfortunately, Ashton Tate also thought these would be s good idea and included them in DBIII+, but, you guessed it, they work slightly differently! The real killer of that bunch is the ability to return the key press on exit from a GET, in Clipper the function is called Lastkey() whilst in DBIII+ it’s called Readkey() and it returns a number. Worse, the same key returns a different number for either DBIII+ or Clipper, with more keys effective in DBIII+; this has resulted in me writing a translation table to sort it all out, messy and takes up space, but it does allow all sorts of things which would otherwise be impossible.

On the score of returning key presses, another incompatibility is the way INKEY() returns the function keys between DBIII+ and Clipper. Now any ordinary key is OK, the value returned by INKEY() is the character value of the key pressed, but function keys work differently, within DOS, a minimum two byte code is returned for function keys, the first byte being the key number, indicating it’s a function key, and the second and subsequent bytes being the function key string.

DBIII+ knows this and reads the second byte correctly returning the first character of what ever string bas been placed in the function key buffer, and only through function keys f1 through f10 – it ignores the other possible permutations of Alt-<function key>, Shift-<function key> and Ctrl-<function key>. Clipper gets it wrong, it returns the key number only, but for all possible permutations. Good news (more keys to play with) and bad news (you can’t preprogram them and have to sort them out later).

All this sounds like bad news from the programming point of view, but there are several ways round it, the neatest is that Nantucket anticipated this might happen so they have included the ‘Clipper’ variable. Now when a PUBLIC variable bas been declared, it takes the datatype logical until used, not only that, it is always declared false, both by DBIII+ and Clipper. So Clipper looks at the PUBLIC declarations when compiling, and if it comes across a PUBLIC call ‘Clipper’, it automatically declares it true, so that compiler differences can be written round. Take the box drawing functions. In this example we declare the publics first, then write some of the main program and then we want to draw a box. As we will be using the box drawing procedure for drawing all types of boxes throughout program, we must pass the x, y co-ordinates to the procedure, so I’ll use the DO .. WITH <parameters> command: