Every user should have one - Steve Mumford begins writing a parachute jump database.
Before I go on, I'd better point out an unexpected feature belonging to AULib that I noticed the other day - when allocating memory during the process of loading a set of templates, the program calculates the length of the window title and sets aside the appropriate number of bytes. However, I'm afraid to say that, until now, it didn't account for the zero byte at the end of the string. This caused the operation that freed the memory to fail erratically if more than one window was loaded.
It's interesting to see the effects that this style of error can generate; while trying to trap this error, I managed to truncate each window's workspace by one byte - the icons lost their three dimensional appearance, but other than this the program didn't appear to be significantly affected.
There's one other point I should make clear. When building your menus it's possible to create submenus of three types: specifying a value of -1 if no submenu is required, the address of another menu datablock in the case of a standard submenu or a window handle to pop up a window. Unfortunately, I suggested last time that you might pass the pointer to a window data block here. I've no idea where I picked that one up from, but let me be the first to say that it doesn't work particularly well. There's an example of how it should be done on the cover disc - in the form of a standard Info box.
Now that's out of the way, I can introduce you to the latest stage of the project - in an attempt to prevent the proceedings from becoming too abstract, I've started work on a simple database-type program. You may or may not find it useful; it's a utility to record the details of any parachute jumps you've made recently.
Putting its subject matter aside for a moment (and once you've written the scaffold of the code, it's easy enough to change the field names), a program such as this covers a wide range of aspects. To be fair, it steers clear of the more complicated techniques required for customised output - for instance, the graphics window of Draw or the text window of Edit. I hope to cover those in the near future, but meanwhile this program will allow us to investigate a wide range of topics from linked list data structures to the message-passing that goes on during a save or load operation.
The first thing to think about when constructing an application of this type is the number and specification of the data field you will require - from there, you can go on to determine the method of data storage best suited to the task. In this case, most of the fields are strings, such as the name of the drop zone and the aircraft type, and a few are integers - the altitude of the jump and the number of seconds spent in freefall.
To aim for memory efficiency and flexibility, I've decided to create a form of linked list to hold the information, but I'll be using structures that hold a 'last element' pointer as well as one that holds the address of the next element. The reason for this is that the user will want to be able to flick back and forth through the database. A one-way linked list would make this prohibitively hard, so including a 'backwards' link is a simple way of making this easier to deal with. It's possible to create even wilder data topographies, but this should suit us for now.
The next step is to begin defining the shape of the user interface, as this will be critical in the code to come. Using any template editor that comes to hand, it's just a matter of arranging the icons clearly, making sure they're long enough to contain the most extreme of entries.
Once you know the icon numbers of the writable icons in the window, as well as any display icons or buttons there might be, you're ready to write them into the program. I've taken the functions provided by AULib and used them to begin building the shell of the database - there's not much to see yet, but I'll present you with the second instalment next month.172 September 1996
|Source:||Acorn User - 172 - September 1996|