Now That's Magic!

Introduction

This article explores the capabilities of dB2k to generate its own code, under the control of its simple native database language in ways that allow the developer to readily configure such generator utilities to implement his own style and scope. Several examples are given of this technique including a method to auto-convert DOS to windows based code, a rapid report generator for generic use, a self build form and table generator demo for an financial application, and a grid generator.

Why the title?

The title above was used by the editor of the VSj magazine for an article outlining some of the techniques covered in more detail below. It seemed a perfect desciption of the dB2k facilities we aim to describe so why not use it again we thought?

The background

 Back in the days of DOS, many programmers used Application Generators to write some at least of the many thousands of lines of code in a typical application. Windows programming software offered "RAD" with its visual tools, custom forms and similar. So the vogue for code generators faded. But as we become accustomed to such tools we again find that many programming tasks are still proving tedious and largely repetitive. So should we be looking for new ways to speed and ease the construction of our applications? In fact there is more scope than many might realise. Better still, it is in part available free and in part capable of fine tuning by each user to meet their own styles and preferences.

DOS xBASE code

 Despite the almost universal switch to Windows, there are still many DOS application in use. Whether they are written for dBASE, Clipper or Fox, the code will consist mostly of the basic and shared dBASE language. Some will have been written by programmers who have long since vanished, some have evolved as one or more employees learnt enough dBASE to put together a system while they still spent most of their time on other, non-computing, tasks. Like it or not, organisations with such systems know that they will have to move to a Windows replacement. They would ideally like to be able to re-use (or auto convert) code wherever possible. They will rightly be concerned at the potential high cost of a complete re-write. So here again tools that can be used to ease the conversion and so lower costs could prove invaluable

More wretched Wizards?

Windows software often includes Wizards to help new users to get started or to help with specific tasks. If well done they can be useful but are frequently soon discarded as their scope is limited and may not fit a user's needs. Most will probably place the dB2k wizards in this category and soon stop using them. In fact the very name Wizard is a big turn off for many programmers.

However a Wizard in dB2k is a code generator. Nothing wrong with the idea, the problem is the limited scope. So would you still spurn it if the scope was extended and you could optionally change it to work just the way that suits your needs? Or if we dropped the name Wizard and called it something else such as a Report Generator or Grid Maker?

dB2k for D-I-Y?

All flavours of dBASE, right from the early (pre-DOS!) days of dBASE II have included facilities to write text to files. Such facilities are enhanced in dB2k and now include functions to read from ASCII files, optionally amend or insert and to write back to the same or a fresh file.

Now unlike most other Windows languages, all dB2k forms, programs, reports etc. comprise 100% ASCII code or text. So if dBL, the dB2k language, can write the sort of code it uses, why don't we make more use of such a powerful facility? Consider the advantages:

  • If our need is specific, we can write it for ourselves
  • For more generic tasks, we can create, share and gradually improve suitable tools
  • As a generic tool is written in dBL, we can modify and extend it to suit ourselves

General Introduction

This has been covered in an article for the VSj magazine (Visual Solutions Journal). The scope of the article had to fit criteria set by the magazine so it does not explore possibilities to the depth we will here. But it does illustrate some of the ways we can build and use generic tools. At present, we cannot include a copy of the article here so use the link below to read it.

Article "Now That's Magic" in VSj magazine

Sections below will tackle examples of the different ways that we are already using code generation to extend and enhance our use of dB2k in the UK.

A specific DOS task

Terry Ede, who hosts meetings of the southern section of the UK dBASE User Group, was offered what at first sight seemed a totally daunting task. This was to migrate to dB2k a huge system (too many prg files to count exactly!). However, though it would have to work within dB2k the client insisted that it must still look like DOS and that it could continue to handle new programs written in DOS dBASE code. Impossible some might think. Not so, nearly all requirements were handled by conversion tools, written of course in dBL. This could be the extreme example of just what is possible in dB2k.

The application itself was unusual and possibly unique in many respects. So it is unlikely that Terry's conversion tools could be re-used elsewhere exactly as they were written. But the general approach and methods should be relevant with many other applications. Which means that his detailed description of how he achieved the near impossible is very worth while reading.

DOS dBase to dB2k Automatic Conversion

A Self Build demo

This is an interesting example of just how far dB2k will generate not only code but most of a complete application. It started as one of those Quid pro quo things for a friend who was owed a favour. Except that it quickly began to look like a favour far bigger than had been anticipated. Until it was realised that extensive code generation could be applied.

Self Build Demo

A Form Generator

Among the limitations with the included dB2k Form Wizard is that it does not use custom forms or custom controls. The layout does not suit everyone either. Yet most data entry forms are really very similar, especially if you do use custom forms to maintain a common style. Typically, such forms require up to a dozen or so entryfields to be dragged on, labelled etc. Not difficult but tedious. Then you may want a pick list grid on page 2. You may want to set the When property to False and True for each entryfield to control editing. Oh dear, it soon becomes a lot of near repetitive code.

The example Form Generator enables the programmer to:

  • Select a custom form
  • Select his/her file of custom controls
  • Select a table
  • Select the fields to be included and in which order
  • Optionally enter label text for each field
  • Flag fields to be in the grid and whether they are indexed.

Now such a generator is not likely to suit every programmer as it stands. What if you use a datamodule? Well it will only take a moment to replace the Query() code and to do a Search and Replace on all the rowset lines. What if you like your labels in a different position? Well, you have all the source code of the generator, change it to suit your preferences. The program supplied is a tool in its own right but possibly it would be better to treat it as an example or template that can be readily adapted.

(Download will be inserted here when it has been written! )

A Grid Generator

Why a grid generator, dBL has a grid control? True but I want my grids to include several extra features. I want to use my text, not the field names, as column headings. I want to place buttons over those headings so that the user can select the preferred index order. I want a Search facility to work on the indexed column and for that column to be highlighted in a different colour. I want to be able to fit it all easily in a pre-determined size. None of this is difficult but all the drilling down in the Inspector gets oh so tedious. A grid generator can complete the whole task in just a couple of minutes.

Not everyone uses grids as pick lists to the same extent, nor would everyone be happy with my style. So the GridMaker is not included here as a download but is available to be sent by email on individual request. Note, it has no included instructions but works much like a simplified URG. It also still has a few bugs as I have learnt how to avoid them!

Apply for a copy to: BobRimmington@ukf.net

A Report Generator

Many reports, those that list data from tables in columns, are ideal for auto generation. At its simplest, what more should be required than to select a table and select the required fields in it? If only the dB2k Report Designer were that easy! In practise headings (overall and columns) are required, index order needs to be set, totals arranged and so on. Plus, all too often, font sizes juggled to fit it all on the paper.

A User Report Generator (URG) to do this has been around for a while (it is on your dB2k CD as part of dBulletin issue 9). However the name may be misleading as now, in its Mark II version, it is intended more for use by developers. A rename to Quick Report Generator (QRG) has been suggested and may well be used for future versions.

The QRG/URG should handle most listing type reports but as always some programmers may want to do some things differently. Again, it is supplied as source code so why not change it to suit? Now some may look at all the code (over 7000 lines) and be loth to risk changing anything. Obviously any changes should be done carefully but much can be modified or added without any need to understand every part of the program. For example, to change the position, font size, colour of the report heading needs only very small changes to the relevant ? .... lines in the ReportStream function (and HTMStream for web pages).

In essence the QRG/URG collects various user choices, options, entered text etc.and holds it as form properties. This allows easy access to that data from any function without the need to ensure that every relevant variable is passed as a parameter. So, for example, if you wanted to add a colour option for column headings, then insert a combobox listing colours and save the one selected to a new form property. There is spare space on the Advanced page or just remove a block of instruction text from another page and insert it there. In ReportStream, in the loop where column headings are written, insert another line with the selected colour property. It is not rocket science stuff, only ordinary dBL coding!

QRG/URG Program with dBulletin article download (580k)

QRG/URG Program only (82k)

Smaller Tools?

There must be other tasks that could be eased with the aid of auto code generators. A very good one in fact is on the dB2k CD in the dUFLP Code Library. Called Crreind.prg it will extract information from every table in a directory and then write a file called IdxBuild.prg. When the latter program is run, it deletes each mdx file, removes all the index details from the dbf file header and then rebuilds it all back again. A perfect way to re-index, I use it in all my applications.

Surely there must be other good tools that somone has written for their own personal use? If so, you are invited to submit the program and details for inclusion here. Or supply a link to your own web site if preferred.

Future Scope

The dBASE company is itself using dBL to write programs that generate programs. Such as Web Wizards. So is there any limit to what is possible? Do you have any partially repetitive coding tasks that could be eased with a suitable wizard or generator? My list already includes:

  • Typical invoice report layout
  • Building a multi page Notebook

Tackling those DOS Applications

Existing DOS applications appear to have one common characteristic, their diversity! So it is very unlikely that a single tool or even a set of tools would readily handle even a few such systems. Yet a great deal of automation should still be possible. With large systems with lots of code, study Terry Ede's article carefully. It ought to be possible to apply the same general principles in many other situations.

Clients usually want to be able to switch to a Windows system wihout losing all their existing records and history. Providing the DOS system is reasonably well structured and not too many changes are required, then it should be possible to use the same tables, perhaps with some additional fields. If so, a Form Generator should be able to build at least the greater part of user entry forms. My own experience so far is that dB2k allows simpler systems than DOS. Instead of popup panels to handle the many groups of fields that cannot be fitted on the 25 x 80 DOS screen, we can use a single form with multi pages, a notebook or both. Most reports too are now a doddle with the QRG/URG.
 

Home Page 

Articles       Demos      Library       Meetings      Members       Tip & Tricks