🚀 go-pugleaf

For C programmers, a partial solution would be to have a template editor
which maintained a .h file containing constant definitions for the icon
numbers (e.g. #define I_LOAD_CANCEL 1 ).

I think this would also work for Norcroft Pascal (which has the C
preprocessor) and could be adapted for basic (use variables instead of
constants and include them as a library).

If you edit the template, the .h file is updated and running MAKE will
re-compile any modules affected.

You need some way of remembering the constant names assigned to each
icon.  I can see 4 ways of doing this:

1.  The template editor saves its templates in it's own format, which
    could include the icon names and any other extras. When you
    save your file, you actually save 3 things:

    * The new format template editor file
    * The original format template file (this is what your program loads)
    * The header file

2.  When the template editor loads the template file, it also loads and
    interprets the .h file.  You'd need some "smart comments" and such
    in the .h file to hold other info.  Problem here is if the template
    and .h files get out of step you're stuffed.

3.  Use the validation string to hold the icon name.  This means that 
    everything has to be an indirected text or indirected text+sprite
    icon, but that is only a problem if you need to use indirected sprite
    only icons (which !FormEd won't do anyway).  If you're using RO3's
    slabbed icons or Interface then you're in this position already.

4.  Tack some extra data on the end of the template file and hope...

The whole point of this idea is that, at the end of the day, your program
doesn't need any non-standard template files or new libraries, and users
can still use !FormEd to tweak the templates if they feel inclined.

The problem with using a new template file standard is (a) I don't think
you could ever get it to work with RISC-OS lib without horrendous kludges.
(Yes, RISC-OS Lib is c**p, but I wrote a few programs before I realised
that and I don't fancy re-writing them!) and (b) If those lads and lasses
at Acorn & Norcroft sort us out with a nice C++ compiler and class
library, you'd be back to square one.