🚀 go-pugleaf

I am posting this article on behalf of John Tytgat (of Bass fame)
because his News forwarding system seems to be acting up these days.
Please reply to one of the adresses listed at the end of this message.
Let me take this opportunity to plug his excellent disassembler !Dissi
which is really worth while if you are interested in analysing code
produced by an optimising C-compiler, for instance. :)

Eric.
======================================================================

A WIMP problem this time :

On page 1257 in the PRM we can read about the Message_PaletteChange :

"This broadcast message is issued by the Palette utility.  It should
not be acknowledged.  The utility generates it when the user finishes
dragging one of the RGB bars for a given colour, or when a new palette
file is loaded.

If a task needs to adapt to a change in the physical colours on the
screen,it should respond to this message by changing any of its
internal tables (colour maps etc), and the call Wimp_ForceRedraw to
ensure that its window are redrawn with the new colours.  Note though
that the palette utility automatically forces a redraw of the whole
screen if any of the Wimp's standard colours change their logical
mapping, so applications don't have to take further action.

This message is not issued when the Wimp mode changes;
Message_ModeChange (&400C1) reports this, so tasks interested in colour
mapping changes should recognise this message too."



I am particulary interested in the sentence : "Note though that the
palette utility automatically forces a redraw of the whole screen if
any of the Wimp's standard colours change their logical mapping, so
applications don't have to take further action."

Does this mean that when a Wimp program changes a colour in a 16 colour
mode using "VDU 19, <colour number>, 16, <red>, <green>, <blue>", the
palette utility automatically issues a redraw of the screen ???

I guess it has to mean something different because such a VDU 19,...
sequence *does not* generate a redraw neither is there a broadcast
message Message_PaletteChange (using Risc OS 2.0) being send.

Is this a bug or do I misinterprete the PRMs ???



A quick way to verify what I am talking about : put yourself in a 16
colour mode, start-up !Paint, create a 16 colour sprite with the
'Palette' bit on and fill it with colour number 11 (that's red).

Now find a TaskWindow which accepts control characters (eg. the
!VMode application written by Brian Brunswick will do this).  Open a
new task and type 'BASIC'.  Now we are going to change the logical
mapping of colour number 11 by typing 'VDU 19, 11, 16, 255, 255, 255'.

Your red sprite will change into a white one.  As you can see there has
been *no* redraw.  To be sure of that last fact we will issue a
broadcast message ourselves by :

DIM Q% 256
!Q%=20
Q%!12=0
Q%!16=9       :REM Message_PaletteChange
SYS "Wimp_SendMessage", 17, Q%, 0

!Paint will pick up this message, read the current palette and change
its colour tables so that the red colour will now be represented by the
actually closest colour, which seems to be a grey one (if this last
thing didn't happen, you probably forgot to switch the 'Palette' bit
on).

Conclusion :

In Risc OS 2.0 the palette utility *does not* automatically force a
redraw if a Wimp standard colour changes its logical mapping, contrary
to what the PRM claims.  Can someone do the same test in Risc OS 3.x ?
Any comments Acorn ???


John
BASS
tytgat@esat.kuleuven.ac.be
tytgatj@imec.be
(my old e-mail account "devijt1@imec.be" is no longer valid...)