Iconbar icon number

Two other wimp functions are provided to allow you to change the iconbar sprite or text beneath the sprite - so most iconbar icon manipulation needs are specifically catered for.

However, if you actually need the iconbar icon number, it is in fact held in the global variable wihan%. This is used 'behind the scenes' by Dr Wimp.

Returns from user functions

When 'filling' any of the user function DEF FNs, there is invariably also a need to change the return value, to ensure that the DrWimp library knows what's going on. The return value to use is clearly identified in Section 3 of the manual (or via !Fnc'n'Prc, or its StrongHelp equivalent).

For instance, in its 'empty' state, DEF FNuser_savedata returns 0. If you fill it with a routine to save some data, you need to ensure that the return value is changed to 1 when (and only when) your save routine is used. If you don't, Dr Wimp won't get the right messages and won't function properly.

A good way to structure the user functions is:

DEF FNuser_something
Return%=0: REM** Default/'empty' return value. **
IF condition% THEN
  PROCTakeAction
  Return%=1: REM** 'Action taken' return value **
ENDIF
=Return%

This ensures the correct return value is always sent. (You can amend this for other 'empty' return cases.)

Tying down specific conditions

As an example, here's a very common user function:

DEF PROCuser_mouseclick(window%,icon%,button%,workx%,worky%)
CASE window% OF
  WHEN Main%
  CASE icon% OF
    WHEN 0:PROCTakeAction
  ENDCASE
ENDCASE
ENDPROC

If you only have one window and one icon, the above structure to filter it out might look a bit heavy. (I've used only the window% and icon% parameters here but the other parameters could be used similarly, of course.)

There are two good reasons why you should get into the habit of following this sort of structure. Firstly, most programs have more than one window and more than one icon (or other parameters). It becomes a doddle to add more specific selections very safely once you have a CASE structure in place. By "safely", I mean with little risk that an addition/amendment will mess up what is already there.

Secondly, it helps ensure that you do actually tie down the action to specific circumstances. Some of the Dr Wimp user functions, such as FNuser_savefiletype, will cause problems with your application if you return a 'non-empty' value without tying down the specific circumstances when it applies. For example, if you were (wrongly) to use:

DEF FNuser_savefiletype(window%)
="FFF"

then Dr Wimp would think (reasonably) that all your windows are 'save' windows and start taking the appropriate action and thereby cause you some head-scratching.

The correct form is:

DEF FNuser_savefiletype(window%)
Return$=""
CASE window% OF
  WHEN Save%: Return$="FFF"
ENDCASE
=Return$

which ensures that "FFF" is only returned when the action involves the save window.

Feedback and new functions

Often, the query arises because the user has run into a problem and so far (fingers crossed!) I've been able to sort it out fairly quickly and the problems haven't been due to faults in Dr Wimp.

Much less frequently, the query relates to something for which Dr Wimp currently doesn't supply a specific wimp or user function. Normally, I can offer a way to do it - and it also goes on my list of "Things to look at" in case it points to a need to add a new facility to Dr Wimp in a future release.

On this latter point, as I see it, a wimp function normally needs to fulfil one main criterion: it needs to involve a SWI call (or some similar operating system access). This criterion is important, I think, because the whole point of Dr Wimp is that it hides all the SWI and other tricky wimp programming actions behind the scenes. If this criterion isn't preserved, I think the DrWimp library will risk being regarded as 'just another library of useful Basic wimp routines'.

Do you have any views on this?

Having said this, there are a (very) few exceptions in the current version (Version 3.53a) of Dr Wimp!

After much thought, I decided to include four new wimp functions which format numbers - offered by Guy Bartle . They don't involve accessing the OS, but they are (surprisingly, perhaps) quite tricky Basic routines if you try to sort them out yourself, and virtually every program involves displaying numbers. So I thought that the exception to the rule was justified here.

!BSquasher

Fortunately, there are other Basic compactors and, at the next release, I hope to include a different one. In the meantime, !BasCrunch and !BasCompress are available from various PD sources.

Demonstration/Talk

I am also willing to do this, provided I don't have to travel too far. If your group would like this and meets at a location within, say, an hour or so's drive from Heathrow - then please contact me.