PreSet Wimp$IconTheme change

The recent change to "Preset Wimp$Icon Theme on initialisation to UserIF and restoration of lost error message for *Iconsprites is really playing havoc with my system.

https://www.riscosopen.org/viewer/revisions/logs?ident=1340439733-987760.html

On booting and before I enter the desktop I get an error message “Missing or squashed sprite file” but no way I finding what the file is or where it is located.

Equally even invoking the Configure window gives the same message and I get it when opening up at least 15% of directories with apps in.

I understand why the the change was made but as my Iyonix has lots of old/legacy apps running and the error message is rather unhelpful in identify what application is causing the issue or file that is missing then I have reverted to a previous softload.

Could the change be configurable or at least give some details of where the issue is located.

Support for Wimp$IconTheme has been in the Wimp since around 2002, so that’s probably a red herring, other than it now having a default value.

Is there one particular app that you can refer to that exhibits the error report? Preferably one that I can see/download from somewhere, if it genuinely is doing *ICONSPRITES !Sprites but doesn’t have a sprites file then that’s plain wrong, but it may point to some other latent fault. I checked the Filer and it makes sure the file exists before trying to iconsprites it.

Also – what EX/EY values do you use? Display manager will tell you in its mode box (menu click on display manager).

The error message text is just what the original author used, but that’s not to say it couldn’t be improved.

Hi

Ok thanks for the tip as I found one app !PCARes which issues a *Iconsprites in its !Boot file but has no Sprites and that was in my Resources area of the Boot structure as per the help file.

I have also found that Chris Wraight’s Theme manager 1.21 configuration plug in causes the same problem but only on my Iyonix and not when installed on the Beagleboard so is is down to one using SCSIFiler and the other ADFS.

Both the Beagle and Iyonix have EX1 EY1

By the way this took lots of time to find as I had to remove components and then reboot and then go into individually created directories with just that application in to check if it was the one causing an issue and I don’t fancy doing that for every single directory I have which may have up to 30+ applications in so any improvements to the error message to say in which application or !Boot file it was running would help.

re: !PCARes
Does copying the file !Sprites to !Sprites22 cure the error?
Similarly in !Themes does creating the corresponding !Sprites from !Sprites22 cure that error?

IIRC I think there is a requirement for Apps to have both.

However, as you say, the system error should be reporting the path to the missing file.

Ok something strange going on.

I have tracked down another application !Moonfish which gives the Sprites missing error and if I take that out of Resources.Configure directory on the Iyonix and then reboot then on invoking the Configure menu I do not get the Sprite missing error and TaskSetup plus Theme manager behave themselves and show their iconsprites. Tried it on both the Iyonix and Beagle with it in Resources.Configure and get the same issue Mooonfish that it errors when access Configure though shows it’s icon but TaskSetup and Themes don’t.

If I place Moonfish in a seperate directory, reboot and then access that directory manually then it does not error.

I have also tried adding a !Sprites22 by copying the Sprites files as sprites22 but it still errors when in the Resources.Configuration directory though again no error when manually accessing it in a seperate directory.

Moonfish can be found at:

http://www.cp15.org/networking/

Reporter would show exactly what commands are being executed (including obey files being run), and any errors found. Thus it should be relatively easy to see what is causing the error. See www.avisoft.f9.co.uk for details.

IIRC I think there is a requirement for Apps to have both [!Sprites and !Sprites22]

By chance, you should get away with it if you just have !Sprites22 because the search order tries the current EX/EY first then the next most square pixel mode, then rectangular pixel, then the base name. I generally take it to mean you must always supply !Sprites but may optionally supply better ones for “hires” modes too.

I have tracked down another application !Moonfish which gives the Sprites missing error and if I take that out of Resources.Configure

Ah ha – there’s an additional requirement that configure plugins must have a file called “CoSprite” (and CoSprite22 etc) and !Configure will hunt these down and iconsprites them. These sprite names must also be registered with the allocations scheme as they must be system unique.

It’s probably worth updating !Configure to behave like the Filer does and not get upset when the user hasn’t done the above step.

However, a more helpful error message shall be forthcoming…

In the intervening minutes I checked the Themes app and specifically its !Boot file.

If “<Theme$Current>”<>"" Then IconSprites <Theme$Path>.Apps.Themes.!Sprites
is the line that causes the error not the initial IconSprites <Obey$Dir>.!Sprites

The source of the error is that the Boot file has previously run the RunImage which on detecting no theme in the user choices, or similar, unsets the Theme$Path but leaves Theme$Current as “[No theme]” thus the line checking Theme$Current does not see a null value and tries to IconSprites a sprite file it could never find as the Theme$Path is unset.
The !RunImage file needs a little work to correct this or the Boot can be altered to check for “[No theme]” rather than ""

Set Themes$Dir <Obey$Dir>
Run <Themes$Dir>.!RunImage

| Select the correct !Sprites file for the current OS Theme
IconSprites <Obey$Dir>.!Sprites
If “<Theme$Current>”<>"[No theme]" Then IconSprites <Theme$Path>.Apps.Themes.!Sprites

Thanks to Martin’s great app I’ve managed to find two more applications a lot quicker that cause issues.

One is John Williams !CDDB which has a line in it’s boot file of:

Iconsprites <cddb$Dir>.CustomSpr

Though I can’t see any custom sprites?

Also Vince Hudd’s !Quicksand game that has no Sprites but issues an Iconsprite command.

Thanks Sprow for the feedback and I see a change in the CVS already and yes helpful error messages would be great.

Steve good feedback and hopefully someone more technical able on RISC OS internals than I will agree/disagree your findings.

All in all a great experience today and good to see that even non RISC OS programmers like myself can be of some use to help track down issues.

then go into individually created directories with just that application in to check if it was the one causing an issue

I know that Reporter’s now easing this process, but would bypassing the main boot sequence and then opening directories (containing multiple apps) using CTRL to avoid filer_booting be any help (then booting them individually by double-clicking)?

It would to some extent and thats what I initially started to do but you still have the issue about which one in 30+ is causing the issue and going through them one by one. At least with Reporter it gave the full directory view in one hit, apart from sub directories, and saved a lot of time.

OK – the “individually created directories” bit made me think you may not have been doing this. Never mind!

OK tried the 25th June Beagle ROM, Iyonix softload and Hard Disc components and I’m able to put !Moonfish back in Resources.Configure and not upset things.

Also a meaningful error now helps identify the applications with missing Sprite files.

Well done and thanks guys for the quick fix time and explanations.

good to see that even non RISC OS programmers like myself can be of some use to help track down issues

Absolutely – it’s equally important to be able to test, document, and diagnose code as it is to write it in the first place. Keep up the good work!

Steve Pampling wrote:

In the intervening minutes I checked the Themes app and specifically its !Boot file.
If “<Theme$Current>”<>"" Then IconSprites <Theme$Path>.Apps.Themes.!Sprites
is the line that causes the error not the initial IconSprites <Obey$Dir>.!Sprites

The source of the error is that the Boot file has previously run the RunImage which on detecting no theme in the user choices, or similar, unsets the Theme$Path but leaves Theme$Current as “[No theme]” thus the line checking Theme$Current does not see a null value and tries to IconSprites a sprite file it could never find as the Theme$Path is unset.

The !RunImage file needs a little work to correct this or the Boot can be altered to check for “[No theme]” rather than ""

Set Themes$Dir <Obey$Dir>

Run <Themes$Dir>.!RunImage



| Select the correct !Sprites file for the current OS Theme

IconSprites <Obey$Dir>.!Sprites

If “<Theme$Current>”<>"[No theme]" Then IconSprites <Theme$Path>.Apps.Themes.!Sprites

Sadly that’s not correct.

The source of the error is that the Boot file has previously run the RunImage which on detecting no theme in the user choices, or similar, unsets the Theme$Path but leaves Theme$Current as “[No theme]”

Theme$Current should definitely not be set to “[No theme]”, and being a user configuration option should not be changed without user interaction. Secondly:

If “<Theme$Current>”<>"" Then IconSprites <Theme$Path>.Apps.Themes.!Sprites

Theme$Path is a path, so MUST be used as Theme: not by expanding <Theme$Path> for the obvious reason that it may contain more than one directory.

If “<Theme$Current>”<>"[No theme]"...

This is definitely WRONG. Theme$Current MUST be compared with "" here. The fault is with whatever has set Theme$Current to [No theme] as that is nonsense. The Theme name is defined to be a valid directory name or empty, which that certainly isn’t. If no Theme is desired, then Theme$Current should be empty or undefined, simple as that.

Ok, having just checked Chris Wraight’s Theme Manager I can confirm that it is the culprit. It uses <Theme$Path> which is always wrong, and also overrides <Theme$Current> with [No theme] if it can’t find a directory which:

1. It has no right to do.
2. Is very wrong anyway.

I’ll email Chris but as his site was last updated in 2006 he may not be active.

Fortunately both the Manager and the Plugin are unsquashed BASIC so will be easy to fix. Right now though I’d not recommend its use. Replacing "[No theme]" with "" throughout and replacing <Theme$Path> with Theme: may be enough, but I haven’t looked in detail.

I’ll email Chris but as his site was last updated in 2006 he may not be active.

Chris is still knocking around. He keeps promising to release a theme manager configure plugin (see the ROOL ROM branding thread), but I don’t think that’s happened yet.

Chris is still knocking around. He keeps promising to release a theme manager configure plugin

Chris has offered his plugin sources for ROOL to use as a basis for the envisaged theme plugin (he’s very busy at present), however some extra facilities are planned which it doesn’t currently cover. At the moment therefore swapping to a non default theme requires manually inserting a “ThemeSetup” obey file in the boot sequence, the theme loader will then do its stuff.

This is one of the slight drawbacks of daily auto-builds, the brave testers get to see the part finished work too.

This is one of the slight drawbacks of daily auto-builds, the brave testers get to see the part finished work too.

I don’t see that as drawback but rather as a teaser that keeps things alive & fun.

@nemo

The !RunImage file needs a little work to correct this or the Boot can be altered to check for “[No theme]” rather than ""


Sadly that’s not correct.

Yeah, I know. I didn’t write the program I merely diagnosed where the problem people were seeing originated – i.e. in the theme definition marker variable.
Following a line suggested at work about being a touch more tactful I was pointing out that the RunImage content needs altering or the Run file content. The Run is halfway right so…

The source of the error is that the Boot file has previously run the RunImage which on detecting no theme in the user choices, or similar, unsets the Theme$Path but leaves Theme$Current as “[No theme]”

Theme$Current should definitely not be set to “[No theme]”, and being a user configuration option should not be changed without user interaction.

the RunImage is broke.

Secondly: If “<Theme$Current>”<>"" Then IconSprites <Theme$Path>.Apps.Themes.!Sprites

Theme$Path is a path, so MUST be used as Theme: not by expanding <Theme$Path> for the obvious reason that it may contain more than one directory.

If “<Theme$Current>”<>"[No theme]"…

This is definitely WRONG. Theme$Current MUST be compared with "" here. The fault is with whatever has set Theme$Current to [No theme] as that is nonsense.

The RunImage is broke…

The Theme name is defined to be a valid directory name or empty, which that certainly isn’t. If no Theme is desired, then Theme$Current should be empty or undefined, simple as that.

If the system has ever seen the theme manager then its defined, unfortunately.

So, since three times is a charm – the RunImage is broke.

I don’t suppose there is any possibility of information about those ‘extra facilities’? I am currently writing a theme creator which will output themes suitable for the theme manager as it currently stands on the website. I would like to be able for it to take advantage of any new features and output themes that are as complete as possible.