Toolbox: "The naming of Parts"

This is a bit of a ramble, but might generate some new ideas.

The use of the Toolbox arose in in the IDE topic and it prompts me to start a topic on the naming of Gadgets and Events in the Toolbox, particularly with regard to BASIC and in comparison to WinEd. I have not used such a template editor in earnest for a long time, though.

Object and Gadgets

An Object has a name that can be edited in ResEd and is used in the Res file as the Template name. This can be returned by the Toolbox and used to create a variable at runtime for the Object and used for function calls related to events.

A Gadget only has a number. This is first allocated by ResEd and is local to the Window object it is in. The Gadget number can be edited to any value, which provides flexibility, but doing this is not made easy by ResEd when there are many Gadgets. WinEd makes the renumbering of Icons quite simple, but these numbers have to be within the total number of Icons, so not so flexible.

For ease of programming, Gadget numbers can be defined as constants. In C etc this is in a header file, but involves some co-ordination between using ResEd and writing the constants header. If you were to use Basalt to program the Toolbox you could do something similar. Using BASIC alone, the numbers would have to be held in variables, which is inefficient. There have been several programs over the years to substitute constants for such variables and my Crunchie is one, but this is an additional step.

WinEd can give a name to an Icon by including an ‘N’ item in the validation string. It can then export the names and Icon numbers for C or BASIC variables, not constants. ResEd cannot do this and in general a Gadget does not have an editable validation string.

However, each Gadget can have a Help message and part of this can be a name. With a bit of juggling, this name can be removed from the message and used to create a variable at runtime for the Gadget and used for function calls related to events.

This is not very satisfactory, and an alternative is to export the Res Messages and use this to provide the name generation like WinEd, or even do this with the Res file itself. Neither of these is at all convenient and not for beginners.

If ResEd had a ‘Name’ field for Gadgets and could export in a similar way to WinEd this would be a big step forward. Even better would be the inclusion of the name in the Res file itself.

Events

WinEd does not provide support for events, as far as I know.

In ResEd you can include Events for Objects and Gadgets. There is a standard set of Event constants defined by name in a header file for C and they are implicit in Basalt. There are also user-defined Events for many Gadgets, but these are only numbers.

The user-defined Events can be given names as constants in the same way as Gadget names. In BASIC alone this can be very inefficient when names are variables and it is likely the values will only be used once. This can be alleviated by the use of a constant-generating step, as with Gadget names.

Event numbers are attached to functions. In BASIC only this is probably done using a CASE structure, but can be done more efficiently in a more complex way. The naming of these functions is arbitrary, but it makes sense to use something related to the Object, possible Gadget, and Event name, say MyWindow_ThisGadget_ClickSelect.

There are C libraries that have functions for the standard Events and similarly BASIC libraries such as AppBasic, but there is no standard for naming.

There is no facility in ResEd for creating skeletons for such functions, but recent discussion of an IDE has had this as one of its objectives. For this to work I think that there either has to be standard naming convention, as above, or else ResEd has to have a field for the function name. If the latter then user-defined event numbers might be generated automatically by RedEd.

There are more ideas and things that I have done buzzing around in my head, but I will wait to see what reaction there is. ;-)

Edited after posting for clarity.

When you say for BASIC storing constants in variables is inefficient, what sort of performance penalty are we talking about? I would not have though it would be significant on anything running RISC OS 5, even if all constants began with the same latter.

In the mists of time Acorn decided that windows would have handles and that icons in a window would have index numbers, starting at 0. Panes (subwindows) came later. Denotations involving strings, for human consumption, are the responsibility of whatever higher level programming language you are using. All the wimp sees are the handles and the indices.

I would not have thought [performance penalty] would be significant on anything running RISC OS 5

I have to agree, but a big part of me is still looking for anything to reduce memory and increase speed. I actually use variables, though. ;-)

There is another small consideration. If variables for Gadget names are assigned automatically at runtime from a Res file, then it is possible that the programmer might assign the same variable without being aware of the conflict. This cannot happen if Gadget names convert to constants.

windows would have handles and that icons in a window would have index numbers, starting at 0.

But Toolbox Objects have names, at least their templates do, and Gadget numbers can be any integer, not constrained by sequence, so the situation is a little different.

I can conceive of all Gadgets having a different number, but that is not how ResEd acts at the moment.

WinEd can give a name to an Icon by including an ‘N’ item in the validation string. It can then export the names and Icon numbers for C or BASIC variables, not constants.

I’m not sure I follow this?

For C, WinEd generates either a bunch of #define lines for the names, or something involving typedef or enum. It doesn’t use variables.

With BASIC, as far as I’m aware there’s no other option but to declare a set of variables. If there is, then the new icon name export code (as of WinEd 3.26) is fairly easily extendable, so it should be possible to add.

Yes. Sorry. I am not sufficiently familiar with C, so I am talking gibberish. I am also using an earlier WinEd, so what I say does not reflect the changes you have made recently. ;-(

My point about variables and not constants when applied to BASIC would be that the export is not in a form suitable for one of the constant substituting methods. For instance, Crunchie requires the assignments to include the LET keyword to be recognized as constants. Another I vaguely remember used REMs.

It does not currently matter, but the MessageTrans export would be suitable for Basalt. ;-)

For instance, Crunchie requires the assignments to include the LET keyword to be recognized as constants.

That’s fairly easy… Without waiting for me to add a GUI option, find the line

ExportBasicIcon:@pf[@wn_]@in@vs[ = @ih]

in !WinEd.Resources.<country>.Messages and add the token value for LET at the start:

ExportBasicIcon:\xe9 @pf[@wn_]@in@vs[ = @ih]

It should be possible to do similar with REM by using \xf4 and whatever other magic incantations the cruncher of choice demanded.

Perhaps the time spent on getting the export formatter to do all of that fun stuff was worthwhile after all! :)

(Again, WinEd 3.26 or later only. 3.25 and earlier did icon export in a very different way…)

That’s fairly easy…

Thanks for that. I have downloaded 3.26. If I used WinEd it would be very useful. Perhaps you could look at ResEd and do the same? ;-)

Edit: Actually, I am going to use WinEd, because I will attempt a mock-up of the ResEd CSE applications – which are not themselves Toolbox apps – to see how they might look with names.