What CodeTemps does is make the use of FNwimp_createwindow and FNwimp_createicon painless. These two wimp-functions allow you to create windows/icons from within your program coding without including a window templates file for them. Sometimes there are very good reasons why this is desirable or even necessary. For example, when you don't know at the start how many icons are going to be needed in a certain window, you can include a window template in the usual way and add icons to it as necessary. Alternatively, you could create both the window and the necessary icons as necessary.
They therefore fulfil very useful purposes, but these two wimp-functions are (necessarily) not quite like any others in Dr Wimp, and to use them 'raw' needs some concentration and a better understanding of Wimp programming than is the aim of the package. So CodeTemps was produced to overcome this unfriendliness.
The utility allows you to design your window and/or icons in a window template editor as normal and then, with simple drag-and-drop, turn this template file automatically into a Basic listing having the precise coding of all the calls to FNwimp_create-window and/or FNwimp_createicon which are necessary to recreate the windows/icons in the template. You then just lift out those that you need and put them where you wish in your !RunImage. The source templates file is then no longer needed (but it would be sensible to keep it somewhere safe to help with any later changes).
A few upgrades back, Harriet Bazley kindly offered me a super utility which takes the Fnc'n'Prc source information and presents it in StrongHelp format. Since then I have been including the output from this in the package also. It doesn't offer all the facilities of Fnc'n'Prc, but it certainly gives all the same descriptive material in the popular StrongHelp format - which I know many users like to use.
In the latest version of the package, this StrongHelp file has been upgraded (again by Harriet) to provide full cross-reference linking when one function description makes reference to another.
I had done the common thing of using the same variable name in more than one DEF PROC/FN, for similar purposes. Unfortunately, the value of the variable in one DEF PROC was surreptitiously being carried over into another DEF PROC. I wasted about an hour trying to find what was causing the application to go wrong. It was solved simply by making the variables local - as I should have done earlier rather than later!
So, do get into the habit of making sure all the variables you use within a DEF PROC/FN are made local unless they are intended to be global. You don't have to worry about variables used as DEF PROC/FN parameters because they are automatically made local, but you should carefully check that all the other non-global variables are included in the LOCAL list at the start of each DEF.
This applies just as much to those Dr Wimp's user-function DEF PROC/FN's which you begin to fill as you develop your application.
| Source: | Archive 14.01 |
| Publication: | Archive Magazine |
| Contributor: | Ray Favre |