Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1018 > unrolled thread

TaskWindow launch an app and get its output

Back to article view | Back to comp.sys.acorn.programmer

Contents

  TaskWindow launch an app and get its output Dave Higton <davehigton@dsl.pipex.com> - 2011-11-12 22:07 +0000
    Re: TaskWindow launch an app and get its output druck <news@druck.org.uk> - 2011-11-14 19:40 +0000
      Re: TaskWindow launch an app and get its output Dave Higton <davehigton@dsl.pipex.com> - 2011-11-19 22:45 +0000
        Re: TaskWindow launch an app and get its output druck <news@druck.freeuk.com> - 2011-11-19 23:49 +0000
        Re: TaskWindow launch an app and get its output Thomas Milius <Thomas-Milius@t-online.de> - 2011-11-20 11:48 +0100
    Re: TaskWindow launch an app and get its output Erik G <erikg@noname.invalid> - 2011-11-16 16:53 +0100
      Re: TaskWindow launch an app and get its output Martin Wuerthner <spamtrap@mw-software.com> - 2011-11-16 17:29 +0100
    Re: TaskWindow launch an app and get its output James Lampard <dontreplytothis@mailinator.com> - 2011-11-18 03:35 -0800
      Re: TaskWindow launch an app and get its output Dave Higton <davehigton@dsl.pipex.com> - 2011-11-19 22:14 +0000
        Re: TaskWindow launch an app and get its output druck <news@druck.freeuk.com> - 2011-11-19 23:44 +0000
        Re: TaskWindow launch an app and get its output James Lampard <dontreplytothis@mailinator.com> - 2011-11-20 02:39 -0800
          Re: TaskWindow launch an app and get its output Dave Higton <davehigton@dsl.pipex.com> - 2011-11-20 14:56 +0000
            Re: TaskWindow launch an app and get its output James Lampard <dontreplytothis@mailinator.com> - 2011-11-25 09:24 -0800
              Re: TaskWindow launch an app and get its output Dave Higton <davehigton@dsl.pipex.com> - 2011-11-25 21:00 +0000
                Re: TaskWindow launch an app and get its output Dave Higton <davehigton@dsl.pipex.com> - 2011-11-27 13:56 +0000
                  Re: TaskWindow launch an app and get its output "Ste (news)" <steve@revi11.plus.com> - 2011-12-20 13:48 +0000
    Re: TaskWindow launch an app and get its output Gerph <gerph@gerph.org> - 2011-11-20 05:09 -0800
      Re: TaskWindow launch an app and get its output Dave Higton <davehigton@dsl.pipex.com> - 2011-11-22 17:07 +0000

#1018 — TaskWindow launch an app and get its output

I'd like to get a task running in a TaskWindow to launch an Absolute
application, and transfer some data from or to it via a dynamic
area.

I've claimed the DA OK.  I've launched the Absolute file using
Wimp_StartTask.  It completes (very quickly).  However, all
subsequent output from the original TaskWindow app seems to be
on the top line (Zap on a BBxM) of the TaskWindow.

Any ideas/suggestions?

Dave

[toc] | [next] | [standalone]

#1020

On 12/11/2011 22:07, Dave Higton wrote:
> I'd like to get a task running in a TaskWindow to launch an Absolute
> application, and transfer some data from or to it via a dynamic
> area.
>
> I've claimed the DA OK.  I've launched the Absolute file using
> Wimp_StartTask.  It completes (very quickly).  However, all
> subsequent output from the original TaskWindow app seems to be
> on the top line (Zap on a BBxM) of the TaskWindow.
>
> Any ideas/suggestions?

You can't directly launch any program that calls Wimp_Initialise from a 
TaskWindow, as you are already inside the Taskwindow's wimp task. The 
best you can do is to request that another Wimp application starts it. 
The easiest way to do this is to *Filer_Run the program, this command is 
queued by the filer module and will be executed by the filer task when 
it gets polled.

---druck

[toc] | [prev] | [next] | [standalone]

#1049

In message <j9rqrm$gls$1@dont-email.me>
          druck <news@druck.org.uk> wrote:

> On 12/11/2011 22:07, Dave Higton wrote:
> > I'd like to get a task running in a TaskWindow to launch an Absolute
> > application, and transfer some data from or to it via a dynamic
> > area.
> >
> > I've claimed the DA OK.  I've launched the Absolute file using
> > Wimp_StartTask.  It completes (very quickly).  However, all
> > subsequent output from the original TaskWindow app seems to be
> > on the top line (Zap on a BBxM) of the TaskWindow.
> >
> > Any ideas/suggestions?
> 
> You can't directly launch any program that calls Wimp_Initialise from a 
> TaskWindow, as you are already inside the Taskwindow's wimp task. The 
> best you can do is to request that another Wimp application starts it. 
> The easiest way to do this is to *Filer_Run the program, this command is 
> queued by the filer module and will be executed by the filer task when 
> it gets polled.

This works to some extent; the output in the TaskWindow doesn't get
loused up.  However, I need to pass some non-constant arguments to
the Absolute app, which means Filer_Run won't work directly.  I
presume this means I'd have to construct an Obey file in a writable
directory, then Filer_Run that.  Is there any easier way?

Dave

[toc] | [prev] | [next] | [standalone]

#1051

On 19 Nov 2011 Dave Higton <davehigton@dsl.pipex.com> wrote:
> This works to some extent; the output in the TaskWindow doesn't get
> loused up.  However, I need to pass some non-constant arguments to
> the Absolute app, which means Filer_Run won't work directly.  I
> presume this means I'd have to construct an Obey file in a writable
> directory, then Filer_Run that.  Is there any easier way?

If you'll only ever be starting one instance at a time you can pass 
information in system variables.

However when you get in to the realm of using multiple tasks and 
passing information between them, it's time to look at using proper 
Wimp applications rather than taskwindow tasks, for at least one, if
not both ends.

The taskwindow system is very limited, and intended to only run 
programs in isolation in a pre-emptive(ish) shell. Trying to make it 
go further requires bodging, and beyond that proper wimp apps are 
actually easier and work better.

---druck

-- 
The ARM Club Free Software - http://www.armclub.org.uk/free/
32 bit Conversions Page    - http://www.armclub.org.uk/32bit/

[toc] | [prev] | [next] | [standalone]

#1053

In message <dacdcc3452.davehigton@dsl.pipex.com>
          Dave Higton <davehigton@dsl.pipex.com> wrote:
> This works to some extent; the output in the TaskWindow doesn't get
> loused up.  However, I need to pass some non-constant arguments to
> the Absolute app, which means Filer_Run won't work directly.  I
> presume this means I'd have to construct an Obey file in a writable
> directory, then Filer_Run that.  Is there any easier way?
> 
>

For a long time the FilerHRun module did a Filer_Run parameters. However
still and silent since a while at least under RISC OS the command

StartDesktopTask

is available.

Some other remarks. INKEY used in BASIC started as a Taskwindow immediately
opens the Window Output of the child task. Starting a child Taskwindow from
another regular Wimptask will require usage of the -task &00000000xxxxxxxxx
parameter inside Taskwindow command where xxxxxxxxx is Hex taskhandle of the
parent.

Best Regards

Thomas Milius

[toc] | [prev] | [next] | [standalone]

#1037

On 12-11-2011 23:07, Dave Higton wrote:
> I'd like to get a task running in a TaskWindow to launch an Absolute
> application, and transfer some data from or to it via a dynamic
> area.
> 
> I've claimed the DA OK.  I've launched the Absolute file using
> Wimp_StartTask.  It completes (very quickly).  However, all
> subsequent output from the original TaskWindow app seems to be
> on the top line (Zap on a BBxM) of the TaskWindow.

Could you give some more information about the situation? It would be
helpful to know:

- how many different programs are involved (looks like 2 from your
desctiption)

- How each program is started (Wimp_StartTask, OS_CLI, command typed in
a TaskWindow window, Filer_Run of an application (e.g. doulble-click an
app, etc.)

- For each program: is it a task (does it call Wimp_Initialise and
Wimp_Poll)? Is it an application (!App directory with contents)?

- In what language is each program written?

- Can you modify each program at will? (My guess is yes)

What I understand from your description is:

You have two programs. Let's call them progA and progB.

ProgA is a "task" running in a TaskWindow. Is this really a task? As
druck points out:

On 14-11-2011 20:40, druck wrote:
> You can't directly launch any program that calls Wimp_Initialise from a
> TaskWindow, as you are already inside the Taskwindow's wimp task.

So how was progA started? Does it call Wimp_Initialise?

ProgB is an "Absolute application". Is it an absolute file, i.e. a
runnable executable, or is it an application, i.e. a !App directory with
the full complement of !Run, !RunImage, etc?

ProgB is launched with Wimp_StartTask (presumably from progA).

Is progB a task (i.e. does it call Wimp_Initialise)?

If so, does it call Wimp_Poll? In that case that call would make
Wimp_StartTask (in progA) return immediately, while progB is still an
active task. If it does not call Wimp_Poll, the return of Wimp_StartTask
means progB is finished.

If progB is not a task, then there is no need to start it with
Wimp_StartTask.

Any answers to these questions would be helpful to solve your problems.

On a droning-on note (:-)), if progB is not a task, you could try to use
the TaskWindow command with the -task option to start progB and let
progA (a task) handle the messages to receive data from and send data to
progB. This might be easier than using a Dynamic Area.

-- 
Erik G.
From address is fake
See http://erikgrnh.home.xs4all.nl/

[toc] | [prev] | [next] | [standalone]

#1038

In message <4ec3dc69$0$3020$e4fe514c@dreader35.news.xs4all.nl>
          Erik G <erikg@noname.invalid> wrote:

> [...]
> What I understand from your description is:

> You have two programs. Let's call them progA and progB.

> ProgA is a "task" running in a TaskWindow. Is this really a task?

A program running in a TaskWindow is always a task.

> As druck points out:

> On 14-11-2011 20:40, druck wrote:
>> You can't directly launch any program that calls Wimp_Initialise from a
>> TaskWindow, as you are already inside the Taskwindow's wimp task.

> So how was progA started? Does it call Wimp_Initialise?

Since ProgA is running in a TaskWindow, that question does not make 
any sense.

> ProgB is an "Absolute application". Is it an absolute file, i.e. a
> runnable executable, or is it an application, i.e. a !App directory with
> the full complement of !Run, !RunImage, etc?

I cannot see why that should make any difference. Each executable is 
in some directory or other. Whether it starts with a pling or not is 
only relevant to the Filer, not to program environment.

> ProgB is launched with Wimp_StartTask (presumably from progA).

> Is progB a task (i.e. does it call Wimp_Initialise)?

> [...]

> If progB is not a task, then there is no need to start it with
> Wimp_StartTask.

Yes, there is. Starting progB directly from ProgA would replace ProgA 
by ProgB, i.e., ProgA would be terminated.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#1046

On Nov 12, 10:07 pm, Dave Higton <davehig...@dsl.pipex.com> wrote:
> I'd like to get a task running in a TaskWindow to launch an Absolute
> application, and transfer some data from or to it via a dynamic
> area.
>
> I've claimed the DA OK.  I've launched the Absolute file using
> Wimp_StartTask.  It completes (very quickly).  However, all
> subsequent output from the original TaskWindow app seems to be
> on the top line (Zap on a BBxM) of the TaskWindow.
>
> Any ideas/suggestions?

I suspect the problem may be that Wimp_StartTask calls
Wimp_CommandWindow.

There was a bug in old versions of the wimp that caused
Wimp_CommandWindow to output some control characters to the standard
output each time it was called even if the command window proper was
not being opened. These control characters would be picked up by Zap's
taskwindow implementation causing odd effects.

The odd thing is that I thought this bug had been fixed post RISC OS
4. It should not occur on a BBxM.

I suggest opening the initial task with '%TaskWindow' to get around
Zap's aliasing of the TaskWindow command (namely it adds the -ctrl
parameter). After this control codes should be ignored.

--
James.
To reply use james underline lampard at talk 21 dot com

[toc] | [prev] | [next] | [standalone]

#1048

In message <314050ac-9837-4f22-9ba8-dcc0a2f338a2@e2g2000vbb.googlegroups.com>
          James Lampard <dontreplytothis@mailinator.com> wrote:

> On Nov 12, 10:07 pm, Dave Higton <davehig...@dsl.pipex.com> wrote:
> > I'd like to get a task running in a TaskWindow to launch an Absolute
> > application, and transfer some data from or to it via a dynamic
> > area.
> >
> > I've claimed the DA OK.  I've launched the Absolute file using
> > Wimp_StartTask.  It completes (very quickly).  However, all
> > subsequent output from the original TaskWindow app seems to be
> > on the top line (Zap on a BBxM) of the TaskWindow.
> >
> > Any ideas/suggestions?
> 
> I suspect the problem may be that Wimp_StartTask calls
> Wimp_CommandWindow.
> 
> There was a bug in old versions of the wimp that caused
> Wimp_CommandWindow to output some control characters to the standard
> output each time it was called even if the command window proper was
> not being opened. These control characters would be picked up by Zap's
> taskwindow implementation causing odd effects.
> 
> The odd thing is that I thought this bug had been fixed post RISC OS
> 4. It should not occur on a BBxM.
> 
> I suggest opening the initial task with '%TaskWindow' to get around
> Zap's aliasing of the TaskWindow command (namely it adds the -ctrl
> parameter). After this control codes should be ignored.

My apologies for the delay; I've been out of the country for a week.

I think you're onto something re. the cause, but unfortunately not
the cure.  I originally started the app by double-clicking an app
directory whose !Run file is of type TaskObey, containing the line:

Basic -quit <Obey$Dir>.RunImage

I've changed it so !Run is now of type Obey, containing the line:

Taskwindow -ctrl "Basic -quit <Obey$Dir>.RunImage"

Alternatively:

%Taskwindow "Basic -quit <Obey$Dir>.RunImage"

The first behaves no differently from my original.  The second does
print out all the lines, but without carriage returns!

I then tried redirecting the output of my Absolute app to a log
file, to see if I could catch the control characters.  It logs:

1C 28 5B 77 24 04 17 01 00 00 00 00 00 00 00 00
17 10 01 FE 00 00 00 00 00 00

Even with the output from the Absolute file supposedly redirected,
the output from the first app is still affected.

Does this put us any further forward in diagnosing what's happening?

Dave

[toc] | [prev] | [next] | [standalone]

#1050

On 19 Nov 2011 Dave Higton <davehigton@dsl.pipex.com> wrote:
> I then tried redirecting the output of my Absolute app to a log
> file, to see if I could catch the control characters.

Ouput redirection of the command used to start the task window doesn't 
behave as expected due to the TaskWindows interception of output.

---druck

-- 
The ARM Club Free Software - http://www.armclub.org.uk/free/
32 bit Conversions Page    - http://www.armclub.org.uk/32bit/

[toc] | [prev] | [next] | [standalone]

#1052

On Nov 19, 10:14 pm, Dave Higton <davehig...@dsl.pipex.com> wrote:
> In message <314050ac-9837-4f22-9ba8-dcc0a2f33...@e2g2000vbb.googlegroups.com>
>           James Lampard <dontreplytot...@mailinator.com> wrote:

[snip]

>
> I then tried redirecting the output of my Absolute app to a log
> file, to see if I could catch the control characters.  It logs:
>
> 1C 28 5B 77 24 04 17 01 00 00 00 00 00 00 00 00
> 17 10 01 FE 00 00 00 00 00 00
>
> Even with the output from the Absolute file supposedly redirected,
> the output from the first app is still affected.
>
> Does this put us any further forward in diagnosing what's happening?

Yes, that's what Wimp_CommandWindow likes to output.
Digging out an old text file from 2006 shows that RO4 typically
outputs:

1C 0A 4D 4E 32                    (define text window)
04                                (split cursors)
17 01 00 00 00 00 00 00 00 00     (disable cursor)
17 10 01 FE 00 00 00 00  00 00    (disable scroll protection)

However I got this but I got from intercepting the output of the
parent task window, not the child task.

I've got a new idea to get around this problem. On my machine
VDU21:SYS "Wimp_StartTask","Command":VDU 6
appears to work without the unwanted text window being used by Zap.
Now I just need to re-write my Basic library to remove the hideous
bodge I was using before.

--
James.
To reply use james underline lampard at talk 21 dot com

[toc] | [prev] | [next] | [standalone]

#1055

In message <bdedbce6-15b9-4afd-9ef7-8dc5a46c63e0@m7g2000vbc.googlegroups.com>
          James Lampard <dontreplytothis@mailinator.com> wrote:

> On Nov 19, 10:14 pm, Dave Higton <davehig...@dsl.pipex.com> wrote:
> > In message
> > <314050ac-9837-4f22-9ba8-dcc0a2f33...@e2g2000vbb.googlegroups.com>      
> >     James Lampard <dontreplytot...@mailinator.com> wrote:
> 
> [snip]
> 
> >
> > I then tried redirecting the output of my Absolute app to a log
> > file, to see if I could catch the control characters.  It logs:
> >
> > 1C 28 5B 77 24 04 17 01 00 00 00 00 00 00 00 00
> > 17 10 01 FE 00 00 00 00 00 00
> >
> > Even with the output from the Absolute file supposedly redirected,
> > the output from the first app is still affected.
> >
> > Does this put us any further forward in diagnosing what's happening?
> 
> Yes, that's what Wimp_CommandWindow likes to output.
> Digging out an old text file from 2006 shows that RO4 typically
> outputs:
> 
> 1C 0A 4D 4E 32                    (define text window)
> 04                                (split cursors)
> 17 01 00 00 00 00 00 00 00 00     (disable cursor)
> 17 10 01 FE 00 00 00 00  00 00    (disable scroll protection)
> 
> However I got this but I got from intercepting the output of the
> parent task window, not the child task.
> 
> I've got a new idea to get around this problem. On my machine
> VDU21:SYS "Wimp_StartTask","Command":VDU 6
> appears to work without the unwanted text window being used by Zap.
> Now I just need to re-write my Basic library to remove the hideous
> bodge I was using before.

Brilliant, James, thanks!  It works perfectly using Zap.  With
Edit, there are five spurious printed characters - but I think
that will be OK, with a warning in the Help file.

StrongED seems to go wrong with "Internal error: abort on data
transfer at &00041BC8" immediately, i.e. before it gets as far
as launching the Absolute app.  I have no idea why.  This is a
new installation of SE 4.68; I don't normally use SE, being a
Zap user for many years, but I thought I should check
compatibility.  Failed, sadly.

Dave

[toc] | [prev] | [next] | [standalone]

#1062

On Nov 20, 2:56 pm, Dave Higton <davehig...@dsl.pipex.com> wrote:

[snip]

> Brilliant, James, thanks!  It works perfectly using Zap.  With
> Edit, there are five spurious printed characters - but I think
> that will be OK, with a warning in the Help file.

As I mentioned before, Zap aliases the Taskwindow command to let
through control characters. What I didn't mention was that this alias
persists even after you quit Zap. If you run Edit on a system without
Zap present you won't get the spurious characters (hopefully).

> StrongED seems to go wrong with "Internal error: abort on data
> transfer at &00041BC8" immediately, i.e. before it gets as far
> as launching the Absolute app.  I have no idea why.  This is a
> new installation of SE 4.68; I don't normally use SE, being a
> Zap user for many years, but I thought I should check
> compatibility.  Failed, sadly.

I don't think v4.68 is fully ARM v7 compatible. Try v4.69a4 from
http://www.stronged.iconbar.com/archives/releases/se469a4.zip

--
James.
To reply use james underline lampard at talk 21 dot com

[toc] | [prev] | [next] | [standalone]

#1063

In message <c5c19c33-edd5-416f-a452-d091b1da141a@l24g2000yqm.googlegroups.com>
          James Lampard <dontreplytothis@mailinator.com> wrote:

> On Nov 20, 2:56 pm, Dave Higton <davehig...@dsl.pipex.com> wrote:
> 
> > StrongED seems to go wrong with "Internal error: abort on data
> > transfer at &00041BC8" immediately, i.e. before it gets as far
> > as launching the Absolute app.  I have no idea why.  This is a
> > new installation of SE 4.68; I don't normally use SE, being a
> > Zap user for many years, but I thought I should check
> > compatibility.  Failed, sadly.
> 
> I don't think v4.68 is fully ARM v7 compatible. Try v4.69a4 from
> http://www.stronged.iconbar.com/archives/releases/se469a4.zip

Many thanks!  Pity only 4.68 is linked to from the front page.
Also I see there's a version 4.69a5 adjacent to your link.  I
downloaded both 4.69a4 and 4.69a5, installed 4.69a5, and it seems
to work.

Dave

[toc] | [prev] | [next] | [standalone]

#1074

In message <b42bda3752.davehigton@dsl.pipex.com>
          Dave Higton <davehigton@dsl.pipex.com> wrote:

> In message <c5c19c33-edd5-416f-a452-d091b1da141a@l24g2000yqm.googlegroups.com>
>           James Lampard <dontreplytothis@mailinator.com> wrote:
> 
> > On Nov 20, 2:56 pm, Dave Higton <davehig...@dsl.pipex.com> wrote:
> > 
> > > StrongED seems to go wrong with "Internal error: abort on data
> > > transfer at &00041BC8" immediately, i.e. before it gets as far
> > > as launching the Absolute app.  I have no idea why.  This is a
> > > new installation of SE 4.68; I don't normally use SE, being a
> > > Zap user for many years, but I thought I should check
> > > compatibility.  Failed, sadly.
> > 
> > I don't think v4.68 is fully ARM v7 compatible. Try v4.69a4 from
> > http://www.stronged.iconbar.com/archives/releases/se469a4.zip
> 
> Many thanks!  Pity only 4.68 is linked to from the front page.
> Also I see there's a version 4.69a5 adjacent to your link.  I
> downloaded both 4.69a4 and 4.69a5, installed 4.69a5, and it seems
> to work.

Having said it seems to work, I've been getting an "Unknown operand"
error box on every start-up for the last couple of days.  I was
about to start diagnosing a boot-up problem, but then I realised I
hadn't made any changes to the boot system recently; the only thing
I had done was to install StrongED.  I deleted SE and its config app
and restarted; no more error box.

Dave

[toc] | [prev] | [next] | [standalone]

#1205

In article <a10dbb3852.davehigton@dsl.pipex.com>,
   Dave Higton <davehigton@dsl.pipex.com> wrote:
> Having said it seems to work, I've been getting an "Unknown operand"
> error box on every start-up for the last couple of days.  I was
> about to start diagnosing a boot-up problem, but then I realised I
> hadn't made any changes to the boot system recently; the only thing
> I had done was to install StrongED.  I deleted SE and its config app
> and restarted; no more error box.

We (at ROOL) debugged this issue with Fred Graute so hopefully he will
publish his fixed version at some point.

Ta,

Steve

-- 
Steve Revill @ Home
Note: All opinions expressed herein are my own.

[toc] | [prev] | [next] | [standalone]

#1054

On Nov 12, 10:07 pm, Dave Higton <davehig...@dsl.pipex.com> wrote:
> I'd like to get a task running in a TaskWindow to launch an Absolute
> application, and transfer some data from or to it via a dynamic
> area.
>
> I've claimed the DA OK.  I've launched the Absolute file using
> Wimp_StartTask.  It completes (very quickly).  However, all
> subsequent output from the original TaskWindow app seems to be
> on the top line (Zap on a BBxM) of the TaskWindow.
>
> Any ideas/suggestions?

This sounds like you're being hit by a problem in earlier versions of
the TaskWindow module which were caused by the Wimp's setup of a
Command Window in order to ensure that the subsequently run command
will be able to read the window size correctly. As you're inside a
TaskWindow it captures this output stream and sends it to the
controlling application. !Zap, understanding the control sequences,
applies a window (albeit not the one that was expected) and you end up
with a strange result.

Using Wimp_StartTask from within a TaskWindow is unsafe prior to
TaskWindow version 0.72 on the Select versions (when used with
WindowManager 5.09), due to pre-emption problems beyond the issues you
describe above. http://select.riscos.com/prm/desktop/taskwindow.html
has a paragraph (which says not much more than the above). The fixes
for the pre-emption problem also address the above Command Window
issues, as they ensure that the new-born task is no longer within the
TaskWindow's control by the time the context is initialised by the
Wimp_CommandWindow call.

If you wish to invoke a task from within a TaskWindow on a modern
version of the OS, use TaskManager_StartTask which doesn't allow you
access to the Task handle, but then you couldn't reliably use it
within your original TaskWindow in any case. This said, however, you
will need to be careful to remove the dynamic area should your second
task not start successfully, and - of course - any invocation of a
task may result in an error box which requires user intervention to
clear.

--
Gerph

[toc] | [prev] | [next] | [standalone]

#1058

In message
<e104c9d7-5a33-4dc2-9392-a3fd2a4736da@q16g2000yqn.googlegroups.com>
          Gerph <gerph@gerph.org> wrote:

> On Nov 12, 10:07 pm, Dave Higton <davehig...@dsl.pipex.com> wrote:
> > I'd like to get a task running in a TaskWindow to launch an Absolute
> > application, and transfer some data from or to it via a dynamic
> > area.
> >
> > I've claimed the DA OK.  I've launched the Absolute file using
> > Wimp_StartTask.  It completes (very quickly).  However, all
> > subsequent output from the original TaskWindow app seems to be
> > on the top line (Zap on a BBxM) of the TaskWindow.
> >
> > Any ideas/suggestions?
> 
> This sounds like you're being hit by a problem in earlier versions of
> the TaskWindow module which were caused by the Wimp's setup of a
> Command Window in order to ensure that the subsequently run command
> will be able to read the window size correctly. As you're inside a
> TaskWindow it captures this output stream and sends it to the
> controlling application. !Zap, understanding the control sequences,
> applies a window (albeit not the one that was expected) and you end up
> with a strange result.
> 
> Using Wimp_StartTask from within a TaskWindow is unsafe prior to
> TaskWindow version 0.72 on the Select versions (when used with
> WindowManager 5.09), due to pre-emption problems beyond the issues you
> describe above. http://select.riscos.com/prm/desktop/taskwindow.html
> has a paragraph (which says not much more than the above). The fixes
> for the pre-emption problem also address the above Command Window
> issues, as they ensure that the new-born task is no longer within the
> TaskWindow's control by the time the context is initialised by the
> Wimp_CommandWindow call.
> 
> If you wish to invoke a task from within a TaskWindow on a modern
> version of the OS, use TaskManager_StartTask which doesn't allow you
> access to the Task handle, but then you couldn't reliably use it
> within your original TaskWindow in any case. This said, however, you
> will need to be careful to remove the dynamic area should your second
> task not start successfully, and - of course - any invocation of a
> task may result in an error box which requires user intervention to
> clear.

Very interesting, Justin, and thanks for your reply: informative as
always.

*Help Taskwindow tells me it's version 0.73 (04 Aug 2011), and it's
running under RO 5.17 built from sources from a few weeks ago.  I
guess the RO5 and Select versions differ in their behaviour - Select
fixed a bug that's still in the ROOL version?

Dave

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web