Creating user friendly programs (1) ----------------------------------- by Steven Flintham ------------------ The screen layout (1) --------------------- This is the first of a series of articles (and it might be the last!) about something I feel really strongly about - the user interface. There are hundreds of programs around in the public domain for the 8-bit Acorn micros which are completely ruined by pathetic user interfaces (in my opinion anyway!). I have a friend, who shall remain nameless, who writes programs that work perfectly but can be extremely hard/irritating to use because of an appalling user interface. A key element of a user friendly program is the screen layout. It doesn't take too much effort to give your program a professional finish, and it makes the program much more pleasant to use. This article is accompanied by a BASIC program called "Example" which illustrates one style of screen display. The style illustrated is possibly the most appealing form of 3D display which can be done on ANY BBC - although I'd love to be proved wrong! It involves rectangles which have an offset "box" behind them to give the impression of a simple "shadow". The program shows the principle clearly enough, but an explanation is never wasted! The main body of the program is just a call to the procedures explained below. PROCdisable and PROCenable are just there to enable and disable the cursor and ESCAPE keys - something I might whinge about later in this series of articles! PROCinit just sets up an error handler - there is no need to initialise variables etc in this program. The first really interesting routine is the function FNgxr_present. This can be used to detect whether an Acorn Graphics Extension ROM (GXR from now on!) is present and enabled. If you are using a Master or above, this will always return TRUE as the GXR is built into all Operating Systems above and including 3.20. The function should be called with a blank screen and as it corrupts the screen, a mode change or CLS should be done afterwards. It works by drawing a circle at the centre of the screen using a GXR command, which will have no effect if one is not present. It then returns TRUE if the pixel at the centre of the screen is non-blank - something which will only happen if the GXR is present. The result of this is assigned to the global variable gxr%. PROCbox3d needs this global variable to be present - if you want to "borrow" it for your own programs and you don't want to bother with the GXR detection routine, you can just set gxr% to FALSE or remove the code in this procedure which refers to GXR. I used a global variable because I thought that in a long program, you don't want to have to pass a flag to PROCbox3d every time you call it. It takes eight parameters. The first four are the coordinates of the bottom left and top right corners of the box surrounding the box AND its shadow - nothing is drawn outside them. The next two parameters are colour codes (as used with GCOL) which determine the colours to be used - experiment with them if you're not certain, but remember that the colours will vary from mode to mode. The final two parameters are used to place a text string centrally within the main box. The first is a text string, which can just be "" if no text is required, and the second is the width of a single character in the current mode. This can be found by (actual x resolution/characters per line)*8, but the values are listed in the procedure anyway. For the sake of completeness, here they are again: Mode 0 - 16 Modes 1 and 4 - 32 Modes 2 and 5 - 64 (although I really wouldn't recommend using this procedure in these modes - they're a bit "chunky") PROCrect_gxr and PROCrect_nogxr both draw solid rectangles in the current colour. The first uses the GXR for that slight turn of speed, while the second uses the time-honoured method of drawing two triangles. Incidentally, does anyone know how to produce a general-purpose non-GXR version of this routine which will work with GCOL 4? I've tried several times in the past but the triangles always overlap and an inverted line appears down the centre of the rectangle. This doesn't affect this program, but I have a couple of other ideas which need something like this. PROCoutline_rect simply draws an outline "box" - it doesn't have a GXR equivalent, as the GXR only supports solid rectangles. You might have noticed the reference to ANY BBC above - there is a nice style of 3D which is sometimes used on the Archimedes which relies on the availability of grey shades - if you've seen pictures of Impression in any magazines, you'll know what I mean. It looks a lot better than this method if it's done carefully, and it can be provided (I think!) on the 8-bit BBC by using a colour mode (such as mode 1) on a monochrome monitor. I haven't tried it yet, but if there are enough people with monochrome monitors, TV's (you can just turn down the colour on a colour set) or add-on boards (like the SPX or Chameleon boards) to allow analogue RGB who could use this technique (I'll judge it from the results of the questionnaire), I might consider trying it. The only problem is, of course, that users of colour monitors will get strangely-coloured displays - however, if you're writing a program just for yourself, it doesn't matter - and if you're feeling really professional you can always add a configuration option which will redefine the colours to give a flat but non-confusing display on colour screens. Accompanying this article are also two PD fonts - if you have a Master, you can just *EXEC them - everyone else will have to mess about with *FX20,6 and then fiddle about with PAGE before *EXECing them. They are definitely public domain, as I have got copies of them from several sources. I can't credit the designers because their names weren't given. Their filenames are: Bold0 (a bit over the top for a lot of text, but it might be useful for headings), and NewFont (strange name, but very readable - probably my favourite). Using them carefully could also help to make your programs more presentable. If you're feeling advanced, you could call them at various points within your program to allow headings in bold, main text in a different font etc. Example 2 demonstrates this, but remember that you'll still have to fiddle with *FX20,6 and PAGE before running it if you haven't got a Master. Try something like: *FX20,6 PAGE=PAGE+&600 CHAIN "Exampl2" Note that Exampl2 uses PROCexec(fname$), which performs the equivalent of *EXEC on fname$. This is done because *EXEC only feeds characters to the VDU drivers when the program pauses for input. I know I could use *TYPE or *PRINT, but there are subtle differences between these on various systems (compare OS 1.20 and OS 3.20 - on OS 1.20, *TYPE just sends the file straight to the screen but on OS 3.20, it displays all the control codes in the |V... format). In case you were wondering, the bold font is called Bold0 because it comes from a larger collection. I'm not sure if the rest of the collection is PD (I have copies of these two from several sources, so there's no doubt about them...), but if it is I will send the other fonts to 8BS. Anyway, that's it for now. The next article (if there is one!) will probably concentrate on creating a nice mode 7 display. Editor's note: Members who own BBC B or B+ machines who are interested in obtaining the Acorn Graphics Extension ROM may like to note that one was advertised for sale in Issue 20. Then again, a second-hand Master 128 was also advertised, and there are thousands (well, nearly) for sale second-hand quite cheap these days, which would make loading fonts in a lot easier as well.