Wimp_LoadTemplate and fonts

I don’t understand the description in the PRM of the section of Wimp_LoadTemplate that deals with fonts.

I have a BASIC program (more than one infact) which has a template file in which one icon is defined as using a font and font size which are different to the desktop font.

I was under the impression that on loading the template the font reference would be stored for me, so that I can call Font_LoseFont on exit.

After multiple runs and exits of my program, StrongEd aborts with an error mentioning fonts.

I’ve been investigating the loading process.
I DIM a 256 byte area called fonts%
I initialise that area to 0’s
I call Wimp_LoadTemplate with fonts% in R4
On exit from Wimp_LoadTemplate the fonts% area still contains only zeros. I expected one byte to have changed.

Because of this, the exit routine which calls Font_LoseFont does nothing, which I believe is causing StrongEd problems.

I think you should call Wimp_LoadTemplate with fonts% in R5, and the name of the template in R6. So, just add an extra comma.

Here’s what the PRM has to say:

 Wimp_LoadTemplate (load syntax)
WindowManager
» SWI Calls
» Wimp_LoadTemplate
» Wimp_LoadTemplate (load syntax)
Wimp_LoadTemplate (load syntax)
(SWI &400DB)
Entry 	
R1 	Pointer to buffer for template
R2 	Pointer to workspace for indirected data
R3 	Pointer to end of indirect data workspace +1 byte
R4 	Pointer to 256 byte array for font reference, or –1 for no fonts
R5 	Pointer to (wildcard) name to match (must be 12 bytes word-aligned)
R6 	Position to search from, or 0 for the first call 

On exit from Wimp_LoadTemplate the fonts% area still contains only zeros. I expected one byte to have changed.

I would have expected that *fontlist would show that font/size to have been allocated a handle, or usage incremented if an existing font handle. The font% byte corresponding to the handle should be incremented by one. If fontlist shows no change, check the template and the load!

Because of this, the exit routine which calls Font_LoseFont does nothing, which I believe is causing StrongEd problems.

If LoseFont is not called, I cannot see why SE should be affected. It just means that the usage count for that font handle will never return to zero, so it cannot be released. A memory leak, if you like.

Is the default desktop font Homerton.Medium? I ask because that’s the font used in the icon, but at a different size. I tried changing the name of the font to Eric.Bold, and now one byte of the fonts array changes from 0 to 1.

So it seems as though I only need to use font_LoseFont if the font name is different from the desktop font, even though the size is changed.

Noting that R0 isn’t listed, so R4 is the 5th parameter.

Ah yes, my fault.

You should call LoseFont for every non-zero count byte in the array, repeated for the number of the count.
I have never seen any dependancies on the desktop font … but cannot check as away from home & RISC OS.
I agree it is R4 in LoadTemplate.

Remember, if you’re using the fonts in the window template, you must also…

• Use Font_LoseFont on every font returned in the table used by a window when that window is deleted.
• Use Font_ReadDefn, then Font_LoseFont, then Font_FindFont, and then Wimp_SetIconState to update the font handle in the window, whenever you get a mode change message.
• Use Font_LoseFont on every font returned in the table when your application exits.
• Be really sure that you’re doing what you mean, because if the user has configured something different to what you expect, your application will look incongruous.

IMO, basically it’s way too much hassle, and you’re better off doing things in user redraw or just not bothering, rather than putting font handles into icons – at least in the templates.

Use Font_LoseFont on every font returned in the table used by a window when that window is deleted.

That’s going to need some checking by me. The reason is that for some changes to a window, I’ve found it necessary to grab the window definition, delete the window, modify the definition, then recreate the window. The question is whether that would change the font handle.

It does seem that for Homerton.Medium, no font is returned in the table. I can’t remember how to find out what the desktop font is set to, but I suspect it is the same, which is the only reason I can think of for nothing being returned.

The other points you raise, re mode changes, aren’t mentioned in the PRM at all.

Fortunately all this is written for my own use, so I can be sure the desktop font isn’t going to change, and in most cases mode changes won’t occur either. (There’s one case where I’m going to have to remember to change screen size before starting the program.)

The main thing to come out of this, is that I don’t now have a theory about why StrongED was crashing. I’ll send Fred the dump file and see whether there are any indications in it.

aren’t mentioned in the PRM at all.

It’s right there on page 3-56. The blah at the beginning that talks about “Template files”.