Dr Wimp makes printing a doddle - whether 'wysiwyg' or independent of what is on the screen.

The biggest practical problem is getting your head around the work/screen/paper coordinates, but this is the same with or without Dr Wimp. It is best to slow yourself down deliberately and tackle the conversions methodically. Even so, it is quite common to start by printing something partially or wholly off the paper! (Often, a result partially off the paper works wonders for better understanding, because you can more easily see what is needed to position it correctly.)

The other problem is forgetting to check that you have set the graphics and/or text colour correctly. It is quite easy to print a nice white line on white paper! Use PROCwimp_setcolour to set the GCOL value for graphics items. For text, the various wimp-functions include colour choice in their parameters. In both cases, Dr Wimp lets you specify colour in a familiar way and uses the proper wimp SWIs behind the scenes to convert these into something the desktop understands.

One point does often help: if your application doesn't show a printed item at all (maybe not even feeding the paper through) but you are not getting an error message, you can be pretty sure that Dr Wimp is actually printing something 'correctly' - either off the paper or white-on-white, i.e. you haven't really got a coding error; you just haven't got the variable values right.

Oddly enough, this can be more reassuring than getting an error message - because tracking down your real coding faults within the printing protocol can be a bit of a tussle (again, not due to Dr Wimp - it's just the nature of things).

My best tip for chasing a true error is progressively to isolate/bypass sections of code within the printing procedure - temporarily using GOTO to skip some lines, is a very good way - until the error message doesn't occur. Then go over the isolated area with a fine-toothed comb, preferably getting someone else to do it! Difficult-to-spot favourite errors are variable names with a % missing, or quote marks missing in string constructions, or calling a variable which hasn't been seen before.

Declaring global variables

In non-wimp programming the program flow is, by and large, linear and it is relatively easy to ensure that variables aren't called before they have been declared.

In wimp programming, the flow is different: usually a multiple of loops centred on the wimp-poll. Therefore, it can be quite easy to declare a global variable for the first time in one loop and use it later (in elapsed programming time, that is) in another loop which can actually be called before the declaration (in program operating sequence).

The solution is to get into the habit of declaring all global variables at the start of a program; in PROCuser_initialise is the best place.

This habit will also stand you in good stead in other programming languages, some of which require this practice anyway.

Custom error boxes

But did you know that later versions (from v. 3.50, Jan 1998) introduced facilities to help you make, amongst other things, error/warning boxes of your own design?

The main new feature was a wimp-function, PROCwimp_bindpointer, to hold the mouse pointer within the confines of a specified window.

So, design your own error/warning box as a normal window, with all the bells and whistles you wish, and then call PROCwimp_bindpointer when you open it. The user will then not be able to leave that window until he/she takes one of the action options you offer - after which you will have called PROCwimp_releasepointer to put things back to normal. Simple!