Although most of you will not have learned of the above new release (v.3.55) until Archive 13.8 dropped through your letter box in about the middle of April 2000, a few definitely downloaded it very soon after its actual release on 2nd April. One of them, thankfully regular Dr Wimp correspondent Hanro Bosman in South Africa, promptly found a bug in the new 'iconiser' feature.

It is not fatal; the result is that you can't actually customise the iconiser response as you were supposed to be able to do, and panes are not handled correctly when iconising. You will get the Wimp's default iconiser icon instead and the panes do not disappear when they should.

Because of Hanro's prompt notification, by 9th April a corrected version of the DrWimp library was on my website - identified by the use of v.3.55a in line 50 of the library listing. So I think the vast majority of downloads will be of the corrected version.

However, if you were an early bird, only the DrWimp library needs replacing, so you can download that on its own and substitute v.3.55a for v.3.55 in just the following three places in the package:

!MyApp.DrWimp
!Fabricate.Resources.DrWimp
Examples.!DrWimpLib.DrWimp

And if you are one of a handful of people who got v.3.55 by post in very early April, please contact me for a postal replacement.

Sprites

If you are absolutely sure that you have done all the right things procedurally - which are not difficult but must be followed - then it is worth checking the length of the sprite names you are using. None must exceed 10 characters.

I speak from experience! I was trying out the new DrWimp iconiser routine (the corrected one!) with the Example program !PanePain and just couldn't get the correct sprite to show. The answer was that "ic_panepain" is 11 characters. Aarrghh!

PROCuser_overmenuarrow

As you will know, when a menu item has a submenu attached to it, this is indicated by a small arrowhead to the right of the item - and when you move the mouse pointer over this arrow-head, the submenu opens.

However, behind the scenes, the Wimp issues a unique 'message' whenever the mouse pointer is over one of these arrow-heads. Dr Wimp reacts to this message by calling the PROCuser_ overmenuarrow routine - passing you, the programmer, the live values of the parent menu item, the up-coming submenu handle and the pointer position.

It is then, for instance, very simple to change something in the up-coming submenu - to reflect or respond to the current application status, perhaps - before it is displayed; even to the extent of substituting a completely different submenu if you wish.

A practical example might be to enable/disable certain items in the up-coming submenu so as to reflect the up-to-the-moment status of some user determined flags/options.

!Fabricate

If you don't already know, !Fabricate allows you to construct - within literally a few seconds - a fully working 'baseline' application complete with an iconbar icon and a standard two-item iconbar menu with an 'info' window as a submenu. What's more, the handles and several other items can be customised - and it quits properly when you select Quit from the menu.

!Fabricate was produced - using Dr Wimp, of course - in recognition of the fact that whenever we start programming a new application, we invariably need to get to a common baseline starting position before we can commence looking at the features more likely to be unique to each application. And the real problem is that this baseline - albeit identical in structure each time - does need to be customised for each application, even if it's only the application name and changing the sprite names and info box contents correspondingly. This can be a little tedious each time.

So, load !Fabricate, bring up its main window, enter the new application name, enter new info window contents (if you wish) - and hit the OK button and drag the resulting Save box file icon to where you want it.

Hey Presto! Within a couple of seconds, your new baseline application appears. It has a !Run file, a Dr Wimp !RunImage, the DrWimp library, !Sprites and !Sprite22 files and a Templates file. In fact everything you need to 'hit the ground running' as they say.

Because I know it is liked, I am keen to improve !Fabricate - but there has to be a balance between keeping it useful to as many people as possible and extending the baseline product produced.

Do you have any ideas on how !Fabricate could be usefully improved? Please let me know.