Merging Template Files (WinEd)

Apologies if I’m missing something obvious here again as I’m a bit tired this evening.

I thought WinEd might let you drag one or more window defintions from one Templates file window into another as a way to merge some changes into another file.

When I try that today, it always says “A file already exists in the location chosen. Do you wish to overwrite it?” (This even happens if it’s a brand new Template file that hasn’t been saved to disk). If I say yes, the window I dragged in still doesn’t show up in the destination template file.

Is there an easy way to copy a window from one Template file to another or am I better off recreating it by hand?

I thought WinEd might let you drag one or more window defintions from one Templates file window into another as a way to merge some changes into another file.

It does: I’ve just tried it here, and it works exactly as expected.

When I try that today, it always says “A file already exists in the location chosen. Do you wish to overwrite it?” (This even happens if it’s a brand new Template file that hasn’t been saved to disk). If I say yes, the window I dragged in still doesn’t show up in the destination template file.

I’m certainly not seeing that, but if you tell us what version you’re using, I can investigate further. Some files that exhibit the problem might be interesting, too.

Thanks Steve. I thought I’d seen that working in the past. This could very well mean I’ve screwed something up with my RPCEmu setup or the RISC OS installation. I’ll have a poke around with it when I’ve got more time.

Ah, I’m apparently still on WinEd 3.20 (September 2008)!

I tested the r155 test build from here, although I’d hope that 3.26 (from the same page) should also work OK.

That can’t be helping matters, can it?

3.20 definitely has some issues on modern hardware and OSs, although I don’t remember copying templates being one of them. I’d suggest trying an up-to-date version first, and if that doesn’t help I can do some more digging.

Random notes:

• It’s legal to have multiple items with the same name in a Template file – one can enumerate them.
• Wimp_LoadTemplate is one of those buffer-with-no-length calls that has to be taken on trust. Always read the actual length required with R0=0… and then max(R0,68) – see later.
• If LoadTemplate R5 points to a wildcarded name it must be in a buffer of at least 12 bytes as it will be written to.
• The ability to have arbitrary data in a Template file (windows are type 1) was somewhat broken in RO3.5 where some nutter decided to write 1 to buffer+64 regardless of whether the data was actually a window. Grrr.

I may be totally “off piste” with this thought, but this sounds a lot like the kind of weird/undefined behaviour that can occur if something is trying to use wimp$scrapfile (wimp$scrap? sorry, my brain is fried this weekend) and it is either a) a folder (can’t overwrite a folder with a file) or b) protected.

To check this, open a task window and do a show wimp to list all the wimp system variables, and find the scrapfile (I think) one. It is normally set to something like <wimp$scrapdir>.scrapfile

Find that location on disc – usually !Boot then Resources, then !Scrap, then ScrapDirs, then whatever wimp$scrapdir is set to (IDxxxxxx or ScrapDir) then look for “ScrapFile” (or whatever the variable showed). Delete it.

This kind of thing can cause a range of unexpected behaviours where apps/protcols expect to be able to use scrapfile as a… file!

Anything that creates a directory named <Wimp$Scrap> will be sacrificed to Shiva as befitting an agent of chaos and destruction.

With its author.

3.20 definitely has some issues on modern hardware and OSs, although I don’t remember copying templates being one of them. I’d suggest trying an up-to-date version first, and if that doesn’t help I can do some more digging.

Thanks Steve. I ran 3.26 and that one works as expected.

Find that location on disc – usually !Boot then Resources, then !Scrap, then ScrapDirs, then whatever wimp$scrapdir is set to (IDxxxxxx or ScrapDir) then look for “ScrapFile” (or whatever the variable showed). Delete it.

Thanks Andrew. There wasn’t any ScrapFile there in the ScrapDir at the moment.