Dr Wimp p18

Dr Wimp applications list

Dave Edwards suggests that I start a list of applications which people have authored using Dr Wimp - and internet links to them, where appropriate.

The purpose is to show what can be achieved with Dr Wimp and also to provide a source of practical code examples beyond those provided with the Dr Wimp package.

This sounds a good idea and I'll be happy to do it, but it needs you to send me the details of your own pride and joy, so please don't be shy.

When I have received a few, I'll add a page to my website, but for now let's kick things off here with one of Dave's applications:

!SiteMatch - a utility to keep track of changes made to your website (and more). Visit http://www.dave-edwards.com/riscos/software.html

Window definition space

Recently, I made a point about the errors that can suddenly start to occur if the WimpSlot of an application isn't large enough (whether using Dr Wimp or not). There is another, related, area that you need to watch and that is the size of the memory block you use to create windows, icons and menus.

In addition to ensuring that the WimpSlot is large enough to hold 'everything', it is essential that a Wimp application creates a memory block large enough to hold the largest window you are going to create, i.e. the window with the most icons, including any that may be added to a window by separate creation during program run. (No need to worry about the space needed to hold indirected data at the moment. That is covered later.)

In Dr Wimp, this memory block size is determined on initialisation by the second parameter (wimpmem%) of your call to FNwimp_initialise - which is invariably one of the first wimp-functions used. Just put your required value in there.

If the value isn't large enough, your application will fail at some point, possibly just hanging on start-up or perhaps giving an error typical of existing memory being overwritten, e.g. "Unknown or missing variable".

It is easy to do a rough estimate of the required size of the largest definition. An empty window definition needs 88 bytes and each icon needs 32 bytes.

If you are using a window template, the Statistics option from TemplEd's iconbar menu will give you more accurate data - but don't forget to add at least 32 bytes for each extra icon that is going to be created in the program run (if any).

By default (in the !MyApp skeleton application or if you are using !Fabricate) the value of wimpmem% is set to 7000 (bytes) which is enough for about 216 icons in a window. This will be more than adequate for most uses, but it's surprising how often you can exceed that when your imagination gets into gear!

In addition to the above, there is a need to set aside sufficient memory space for the accumulated total of the indirected data used by windows/icons, e.g. indirected text space. If you are using Dr Wimp, this is done automatically for you and you need worry no further - other than to note the final point in the next item.

WimpSlot revisit

Both the above factors - and others, of course - impinge on the WimpSlot size needed. My usual way of adjusting the WimpSlot size is to develop the application using a large value (600Kb?) and then include the line:

VDU4: PRINT (END-PAGE): VDU5

as the penultimate line (i.e. just before END) in the main !RunImage listing.

Then, when you quit the application in the normal way, this line will cause a small Task Window to open showing the amount of memory used, in bytes, by the program itself plus all the variables/arrays/memory blocks etc created during the program run.

You then need to set the WimpSlot value to just a little more than this - because you may not have exercised all the program options before quitting. Indeed, it is often interesting to compare the value shown after a 'start-up-and-immediate-quit' with a value shown after exercising the application.


Source: Archive 14.06
Publication: Archive Magazine
Contributor: Ray Favre