However, user 'Richie' pointed out that the documentation doesn't actually say how you go about loading other types of files into memory (as opposed to manipulating them with OPENIN/OPENUP/OPENOUT etc.).
In a version to be released in the near future, this omission will be corrected explicitly - but for now it may be useful to note that you can use the procedure described for loading drawfiles for any other type of file (except sprites, which have their own Dr Wimp procedure described).
If you do use the drawfile method for non-drawfile files, you can leave out the call to PROCwimp_initdfile, although it won't do any harm.
On the same theme, if you want to use dynamic areas, you simply use FNwimp_createdynamic instead of DIMming in the described procedure.
In fact, the pane had temporarily popped behind its parent window and couldn't be seen - and the simple reason was that he had forgotten to fill in DEF FNuser_pane to tell Dr Wimp which pane belongs to which parent.
What was odd about it was that the query caused me to look at multiple pans in the !Multipane application in Dr Wimp's Examples folder - and I found it exhibiting the same symptom, despite the fact that DEF FNuser_pane was apparently filled in correctly!
After a lot of work, I found there was nothing wrong with the Dr Wimp coding - but there was an error in the manual on how to set up panes - and it has been there a long time!
The manual said that, in DEF FNuser_pane, you must assign the bottom pane (of a stack of panes) to the parent window. This is wrong; you must assign the pane at the top of the stack to the parent window. Everything then works as it should.
I guess that the reason this documentation error has stayed unnoticed is because the fault only produces a very minor functional difference. Anyhow, the manual and example application were both corrected in the v.3.57 release.
I say 'suddenly' because everything had been working fine before a particular change: then you start to get such error messages. Sometimes you get one message and sometimes another. There's no consistency. It looks as if the world has turned upside-down - it has, but don't panic!
The problem is almost certainly very simple. You have just forgotten to increase your wimpslot size as you have been increasing your !RunImage coding. The consequence is that your application is now running into 'uncharted (memory) space' - and you know what happens to Captain Kirk in these circumstances!
Just open the !Run file and make the wimpslot value large - say, 640Kb. If the problems clear as suddenly as they started, you are home and dry and can continue to boldly go. You can now decrease the value by trial and error if you want, but if you are still developing it remember to leave a bit (well, some bytes actually!) in hand.
The nice thing is that these ideas are invariably accompanied with a message saying how much the user likes DrWimp, and I'm particularly pleased to have had some from first-time users who haven't dared to consider wimp-programming before.
It makes it doubly worthwhile.
| Source: | Archive 14.04 |
| Publication: | Archive Magazine |
| Contributor: | Ray Favre |