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
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.
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 |