                 Test printing to another job's window
                 =====================================


Prerequisites
=============

Requires toolkit PRTSTR_BIN pre-loaded into job#0

As it stands, SMSQ/E only, although it should be simple enough to make it
work under Qdos by making suitable alterations and then compiling the
slave_bas program.

(I did this for you! See in io_prt_demo_qdos_)

Unzip to ram1_, for example

For SMSQ/E
----------

 Preferably mode 16 or above, then

 EX ram1_master_bas!

For Qdos/Minerva:
-----------------

 Needs TK2 2.32+ (for FEX_M)

 Needs Q2S_bin, my SMSQ/E compatibility toolkit (SUSJB, SCR_XLIM) or
        equivalent. Instead of SCR_XLIM you can use x% = 512, or whatever
        your screen resolution

 Needs CHID_bin (for CHID. Minerva can use PEEK_L(\48 \40 * ch) instead)

 LOAD master_bas and set the location of the slave_obj program and
        set your desired mode. (Try the default mode 0 first), then
        RUN

All required toolkit commands can be found at Knoware.no.


What this program does
======================

Nothing much, really. It simply demonstrates that it is possible to print
to another job's window. In this case, six different slave jobs, owned by
master_bas, print to a window set up by master. Each slave has its own colour,
position and priority, and terminates after counting up to 999.

SUSJB is needed to give the scheduler time to breate in between, otherwise
the output will be a mess.

The point of PRTSTR% is that it happens to be a command that prints
information to a window. It has options to set the colour and position of
the output string(s) to print. And I made it possible to take a channel ID
instead of just an S*BASIC channel number. It was originally designed to
overcome the problem of locked windows, ie that a program providing
continuous progress updates would not stop running just because its windows
were partially burried, as was the case with early PE non-destructive
windows on the QL.

A weakness of PRTSTR% acting on an external channel is that the different
functions it contains, ie set colour, stripe, position, are not "atomic".
The scheduler can interrupt the command between any one of them. So
another job, including the owner of the channel, may move the cursor
position set by a slave job, and when that job outputs the string it will
be in the wrong place. Whether this is fixable or not I dont know; I havent
tried. The reason I made this command was to output the time on an
asynchronous timer in some main program's subwindow, and it can do that well
enough.

Although not useful, I hope you will find it interesting and fun!


Program Status
==============

Some more information on the background of this program may be found in
this thread on QL Forum: https://theqlforum.com/viewtopic.php?t=3616)

V0.00, pjw, 2025 Oct 04, based on earlier work


Conditions of use and DISCLAIMER as per Knoware.no
