Steve Fryatt <ne...@stevefryatt.org.uk
> On 2020-06-08, Harriet Bazley <har...@bazleyfamily.co.uk
> > Wimp_StartTask will launch a program from within BASIC, and will return
> > the task handle in R0 if successful.
> > SYS"Wimp_StartTask",cmd$ TO handle%
> Yes, this is pretty much how it works.
> > In Infozip, in order to avoid freezing the desktop I launched the
> > 'child' task in a taskwindow, recorded the task handle as child%, then
> > listened in on Wimp_Poll for the Wimp message &400C3 (TaskCloseDown)
> > being broadcast in order to detect when the child had finished. This is
> > a fairly crude approach which only allows for one child task to be
> > running at a time.
> This isn't a great idea, however, as it fails with at least one of the
> popular TaskWindow providers (and ISTR that InfoZip has this problem,
> although I'm not 100% certain). There's no guarantee when calling
> Wimp_StartTask with *TaskWindow that the returned handle will be for the
> task that you're interested in.
> The better way is to check the handle returned from Wimp_StartTask to make
> sure that it isn't zero, which tells you that something has happened. Then
> listen out for Message_TaskInitialise, and check the names of new tasks to
> see if they match the one that you're expecting to start up. When you find
> it, you know the task handle from the sender field of the message block.
That might be better, but there is still more guesswork involved and less
control than using the TaskWindow protocol, which was specifically designed
to allow tasks to control their TaskWindow children. Using this protocol
also makes you independent of any registered TaskWindow provider since your
application itself becomes the TaskWindow provider.
The key point is to launch the child by passing
TaskWindow <command> -wimpslot <slot> -name <name> -quit
-task <my_task_handle> -txt <arbitrary_id>
(obviously, all in one line) to Wimp_StartTask.
Then, you listen for the messages that TaskWindows sends to the given handle
(i.e., to your application since you passed your own task handle), most
notably TaskWindow_Ego, which tells your application the handle of your
child. If you run several children, you can distinguish them because the Ego
message quotes the arbitrary id you passed. TaskWindow_Morio tells you that
your child has died. While the child runs, you can suspend it, resume it and
kill it by sending messages TaskWindow_Suspend/Resume/Morite to your child
handle. By listening to TaskWindow_Output you can receive the output of your
child, e.g., any error messages from Ghostscript.
That is how GView (http://www.mw-software.com/software/gview/gview.html
Martin Wuerthner MW Software http://www.mw-software.com/
------- RISC OS Software for Design, Printing and Publishing --------