Hotlist menu (adjust on iconbaricon) often appears not
full width, but chopped. Although this happens
occasionally with all menus with sprites under RISC
OS, it happens about 50% of the time with nettle.
Possibly a malformed or vaguely stangly formed menu
block?
Logged In: YES
user_id=222505
I believe this to be a Wimp bug rather than Nettle.
The fact that it is nondeterministic, implies that it is
an uninitialised or corrupt variable being accessed. The
fact that the menu width is set to 0 in create_menu means
that it is entirely up to the Wimp to get it right (plus,
of course the fact that Nettle is 3.5+ only). The Wimp
doesn't and seems to be out by the width of the sprite.
This makes me think that it's failing to find the sprite
in its pools and giving up on that under some
circumstances. I'd be tempted to put forward the thought
that if the previous window (or some window last accessed
for sprites) had a sprite area specified, the menu might be
inheriting this sprite area pointer which would be invalid
for this task; this might then be caught by other pieces of
code and just faulted as invalid for other reasons,
resulting in no sprite being known. However, this is all
conjecture. It would be best if this were fixed at source
as - if it is a Wimp bug as I believe, there's no way
around it.
Logged In: YES
user_id=222505
Confirmed that this is not a Nettle bug. This fault is
caused within the Wimp.
Prior to Select 2i1 the window manager would attempt to
locate the sprite requested. Depending on whether sprites
have been cached or not the width of the menu might not be
updated properly. If the sprites had not yet been cached
(that is, the table of sprite names to addresses generated
by the Wimp in order to speed up name lookups) then the
calculation of the menu width would be aborted, leaving a
small size in the 'maximum width' register. Additionally,
extra information within the validation string may cause
the parsing code to become confused, particularly if the
sprite was not the first element of the string (and I'm not
certain that it would function correctly if the sprite was
not the last element of the string in any case).
This fault is present from (I believe) 3.[01]x. I don't
have any access to RISC OS 2 and I can't remember whether
RISC OS 2 had sprites in menus (I believe it did, but can't
be certain that they worked properly in other ways).
A possible solution might be to force a cache construction
by requesting details of a sprite known to be in the Wimp
ROM pool.