Dr Wimp applications

The list is now on my website and the latest addition is:

!Fingering by John Schroder. An application to store and display bassoon fingerings. Visit http://www.j-schroder.demon.co.uk/Fingering/Finger.html.

Spring clean

One of the areas this affected was the wimp-functions which are used to 'switch' a feature on or off - or to change it from one of these states to the other.

For example, for some time there had been a pair of wimp-functions called PROCwimp_iconenable and PROCwimp_icondisable which did exactly what they each say - yet there was only a single wimp-function called PROCwimp_iconselect which, by the use of an extra parameter, provided a means for both icon selection and de-selection.

This seemed inconsistent to me and so v.3.59 introduced a single pattern for these and a few other similar cases.

The new pattern is best described with an example:

PROCwimp_iconenable(window%,icon%,state%)

where the third parameter can be set to 0, 1 or 2: 0 means the described effect is 'off', i.e. here, the icon is disabled; 1 means the effect is 'on', i.e. here, the icon is enabled; and 2 means the current state is reversed, i.e. here, a selected icon would be de-selected and a de-selected icon would be selected.

This same pattern is now used for:

PROCwimp_iconenable
PROCwimp_iconselect
PROCwimp_menuenable
PROCwimp_menutick

and I hope you will find this more logical and easier to remember. It also has the advantage that it has reduced the number of wimp-functions needed.

Another issue concerned those wimp-functions which 'get' the current status of a feature, e.g.

FNwimp_geticonenable()

which tells you whether an icon is currently enabled or disabled, or

FNwimp_testsysvariable()

which tells you if a certain system variable already exists.

There are quite a few of this type of wimp-function but their patterns of return differ. Some return 0 or 1 (to signify 'off' or 'on' respectively) but others return FALSE/TRUE.

Ideally, I wanted the returns to follow just one pattern but, after a lot of thought, I decided that keeping the current two patterns would be better - as long as each was applied carefully.

For example, it makes much more sense to make the return from FNwimp_geticonenable()

match the pattern in PROCwimp_ iconenable(), i.e. 0 for disabled, 1 for enabled - not least because it's quite common for these complementary wimp-functions to be used together.

However, where there's no direct complementary wimp-function, a return of TRUE/FALSE seems more natural - and this is what is used in FNwimp_testsysvariable(), for example.

Demonstration/Talk