Wolfgang Lenerz writes:
> > My solution (perhaps not unique, I don't claim it, but I haven't seen it
used
> > elsewhere) exploits the fact that a job waiting for Input/Output with an
> > infinite timeout (D3=-1) will only ever get 'not complete' (D0=-1)
returned if
> > MT.RELJB/SMS.USJB (release job from suspension) has been used on it.
> (snip)
>
> FiFi has implemented a two job scheme like that for quite some
> time, except that the main job (not the one reading the pointer)
> passes an event to the job reading the pointer whenever it needs to
> update the window. Thjis ALSO causes a return from the read
> pointer loop. The job reading the pointer then suspends itself - the
> main job does whatever it has to do in the window and then
> releases the suspended pointer read job.
Can you do something about FiFi stopping up when its window, or button, gets
burried? (Put the io timeout to 0, or something) You may have done that
since V4.19, of course..
Per
