Changes to TaskWindow
=====================

Changes since RISC OS 4 :

Buffered output has been improved which allowed buffered output up to the
full length of the Wimp buffer. Previous versions would send output in
messages that could have been longer.

Response to UpCall SleepNoMore has been fixed.  Taskwindow now claims this
upcall passing back an error if an attempt is made to stop sleeping on a
pollword which is currently being waited upon.

UpCall 6 and pollidle for INKEY (OS_Byte 129) handling has improved:

UpCall 6 is documented as accepting a pollword which can be scanned for
being non-zero to return control to the process requesting to sleep.  This
was not being used within the TaskWindow module. TaskWindow will now yield
for the default slice time if the pollword pointer specified was either 0,
or the pollword value was non-zero. If the pollword value was zero, the
TaskWindow module will return after the default timeslice has elapsed, or
the pollword becomes non-zero. Use of OS_UpCall with pollwords, or 0 pointer
can be used to allow other tasks processor time when no processing is
required of the TaskWindow-based application.

When INKEY() (OS_Byte 129) is issued, TaskWindow will now wait for the
specified time. Previous versions of TaskWindow would wait for an amount
of time based on the current screen frequency (using VSync) by idling
on Wimp_Poll.

A significant fault in the exit sequence of a TaskWindow application could
cause the machine to lock in an unescapable loop, requiring a reset to
clear. More usually, however, this fault caused aborts to be observed in the
MessageTrans module. Previous versions of TaskManager would fail to mark a
critical operation and interaction with the preemptive feature of the
TaskWindow would (occasionally) cause a dead-lock situation.

Issuing a SWI Wimp_StartTask (or *WimpTask command) from within a TaskWindow
could provoke unreliable responses and aborts on earlier versions of the
TaskWindow module. This issue has been addressed within the TaskWindow and
WindowManager. It may be observed that a new filter is placed on every
TaskWindow running as part of the support for this fix.

Attempting to switch output to sprites from within a TaskWindow could
provoke unreliable output and aborts on earlier versions of the TaskWindow
module. Support for sprite output is only reliable when the TaskWindow-based
application provides a save area for redirection. When a save area is not
used, the TaskWindow module will suspend preemption until either a
preemption request is received (OS_UpCall 6), or input is required from the
parent application.

The purpose of a save area is to preserve the graphics context when output
is switched away from the sprite. Without a save area, the two events given
above will cause the sprite redirection to be restored when returning, but
the graphics context will have been reset to its default settings. It is
strongly recommended that all users of sprite redirection use a save area to
avoid this and future problems.

Where a save area is specified, output to the taskwindow will continue
oblivious of the preemption by the TaskWindow module.

For command line based taskwindows, whilst input is being waited for at
by the TaskWindow, it is now possible to resize the slot used by the
TaskWindow. Whilst a task is running, TaskWindow will refuse to resize the
slot. Tasks which are controlled by other processes (ie which use the
'-quit' flag when launching the TaskWindow) are not resizable by the user.
