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

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

TaskWindow -txt &xxxxxxxx

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

Contents

  TaskWindow -txt &xxxxxxxx Dave Higton <davehigton@dsl.pipex.com> - 2011-09-27 21:41 +0100
    Re: TaskWindow -txt &xxxxxxxx Martin Wuerthner <spamtrap@mw-software.com> - 2011-09-27 23:08 +0200
      Re: TaskWindow -txt &xxxxxxxx Dave Higton <davehigton@dsl.pipex.com> - 2011-09-27 22:33 +0100
      Re: TaskWindow -txt &xxxxxxxx "Ste (news)" <steve@revi11.plus.com> - 2011-09-28 15:27 +0100
        Re: TaskWindow -txt &xxxxxxxx Martin Wuerthner <spamtrap@mw-software.com> - 2011-09-28 17:16 +0200
          Re: TaskWindow -txt &xxxxxxxx "Ste (news)" <steve@revi11.plus.com> - 2011-09-28 19:52 +0100
            Re: TaskWindow -txt &xxxxxxxx Erik G <erikg@noname.invalid> - 2011-09-30 06:02 +0200
          Re: TaskWindow -txt &xxxxxxxx druck <news@druck.org.uk> - 2011-10-02 16:13 +0100
            Re: TaskWindow -txt &xxxxxxxx Erik G <erikg@noname.invalid> - 2011-10-13 11:23 +0200
              Re: TaskWindow -txt &xxxxxxxx Alex Macfarlane Smith <nospam@archifishal.co.uk> - 2011-10-13 21:08 +0100
              Re: TaskWindow -txt &xxxxxxxx druck <news@druck.org.uk> - 2011-10-15 12:13 +0100
                Re: TaskWindow -txt &xxxxxxxx Erik G <erikg@noname.invalid> - 2011-10-18 16:25 +0200
                  Re: TaskWindow -txt &xxxxxxxx Martin Wuerthner <spamtrap@mw-software.com> - 2011-10-19 10:45 +0200
      Re: TaskWindow -txt &xxxxxxxx Erik G <erikg@noname.invalid> - 2011-09-30 05:47 +0200
        Re: TaskWindow -txt &xxxxxxxx Dave Higton <davehigton@dsl.pipex.com> - 2011-09-30 22:38 +0100
          Re: TaskWindow -txt &xxxxxxxx Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-01 05:49 +0200
            Re: TaskWindow -txt &xxxxxxxx Martin Wuerthner <spamtrap@mw-software.com> - 2011-10-01 13:19 +0200
          Re: TaskWindow -txt &xxxxxxxx Dave Higton <davehigton@dsl.pipex.com> - 2011-10-01 20:20 +0100
            Re: TaskWindow -txt &xxxxxxxx Steve Fryatt <news@stevefryatt.org.uk> - 2011-10-01 20:51 +0100
              Re: TaskWindow -txt &xxxxxxxx Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-01 22:46 +0200
                Re: TaskWindow -txt &xxxxxxxx Steve Fryatt <news@stevefryatt.org.uk> - 2011-10-01 22:07 +0100
                Re: TaskWindow -txt &xxxxxxxx Steve Fryatt <news@stevefryatt.org.uk> - 2011-10-01 22:04 +0100
                Re: TaskWindow -txt &xxxxxxxx Dave Higton <davehigton@dsl.pipex.com> - 2011-10-01 22:45 +0100
              Re: TaskWindow -txt &xxxxxxxx Dave Higton <davehigton@dsl.pipex.com> - 2011-10-01 22:44 +0100
            Re: TaskWindow -txt &xxxxxxxx Erik G <erikg@noname.invalid> - 2011-10-18 15:23 +0200
              Re: TaskWindow -txt &xxxxxxxx Erik G <erikg@noname.invalid> - 2011-10-18 15:55 +0200
              Re: TaskWindow -txt &xxxxxxxx druck <news@druck.org.uk> - 2011-10-19 20:27 +0100
    Re: TaskWindow -txt &xxxxxxxx Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-14 07:53 +0200
      Re: TaskWindow -txt &xxxxxxxx Gavin Wraith <gavin@wra1th.plus.com> - 2011-10-14 11:43 +0100
        Re: TaskWindow -txt &xxxxxxxx Martin Wuerthner <spamtrap@mw-software.com> - 2011-10-14 13:26 +0200
          Re: TaskWindow -txt &xxxxxxxx Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-15 20:37 +0200
      Re: TaskWindow -txt &xxxxxxxx druck <news@druck.freeuk.com> - 2011-10-16 18:26 +0100
        Re: TaskWindow -txt &xxxxxxxx Stewart Brodie <stewart.brodie@ntlworld.com> - 2011-10-16 23:28 +0100
          Re: TaskWindow -txt &xxxxxxxx druck <news@druck.org.uk> - 2011-10-19 20:30 +0100

Page 1 of 2  [1] 2  Next page →

#771 — TaskWindow -txt &xxxxxxxx

I'm puzzled by the paragraph on PRM 3-326 that says:

"-txt &xxxxxxxx an 8 digit hex number giving the handle for the Parent
to identify the Child by"

What sort of handle is this, and how can I find whether the child task
is still running?

It isn't the "task handle" as returned in block!0 returned from
TaskManager_EnumerateTasks.

Simply, I need to know when the child task has finished.

Dave

[toc] | [next] | [standalone]

#772

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

> I'm puzzled by the paragraph on PRM 3-326 that says:

> "-txt &xxxxxxxx an 8 digit hex number giving the handle for the Parent
> to identify the Child by"

> What sort of handle is this, and how can I find whether the child task
> is still running?

That is the "txt-handle", a unique handle assigned by your task to the 
child it launches. You will see this in the TaskWindow_Ego, which will 
tell you the child's proper task handle. The only purpose of the 
txt-handle is to be quoted back to you in the TaskWindow_Ego message.

Once you got the proper task handle, you can suspend, resume or kill 
your child task by sending it TaskWindow messages.

> It isn't the "task handle" as returned in block!0 returned from
> TaskManager_EnumerateTasks.

> Simply, I need to know when the child task has finished.

Watch out for the TaskWindow_Morio message from the task whose handle 
you got via TaskWindow_Ego.

The only reason why the complexity with the txt-handle is needed is 
because your task could launch several TaskWindows before returning 
control to the Wimp, and your task has to have a way to distinguish 
them.

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

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

#773

In message <068f781952.martin@bach.planiverse.com>
          Martin Wuerthner <spamtrap@mw-software.com> wrote:

> In message <3613761952.davehigton@dsl.pipex.com>
>           Dave Higton <davehigton@dsl.pipex.com> wrote:
> 
> > I'm puzzled by the paragraph on PRM 3-326 that says:
> 
> > "-txt &xxxxxxxx an 8 digit hex number giving the handle for the Parent
> > to identify the Child by"
> 
> > What sort of handle is this, and how can I find whether the child task
> > is still running?
> 
> That is the "txt-handle", a unique handle assigned by your task to the 
> child it launches. You will see this in the TaskWindow_Ego, which will 
> tell you the child's proper task handle. The only purpose of the 
> txt-handle is to be quoted back to you in the TaskWindow_Ego message.
> 
> Once you got the proper task handle, you can suspend, resume or kill 
> your child task by sending it TaskWindow messages.
> 
> > It isn't the "task handle" as returned in block!0 returned from
> > TaskManager_EnumerateTasks.
> 
> > Simply, I need to know when the child task has finished.
> 
> Watch out for the TaskWindow_Morio message from the task whose handle 
> you got via TaskWindow_Ego.
> 
> The only reason why the complexity with the txt-handle is needed is 
> because your task could launch several TaskWindows before returning 
> control to the Wimp, and your task has to have a way to distinguish 
> them.

Got it.  Thanks, Martin.

Dave

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

#792

In article <068f781952.martin@bach.planiverse.com>,
   Martin Wuerthner <spamtrap@mw-software.com> wrote:
> That is the "txt-handle", a unique handle assigned by your task to the 
> child it launches. You will see this in the TaskWindow_Ego, which will 
> tell you the child's proper task handle. The only purpose of the 
> txt-handle is to be quoted back to you in the TaskWindow_Ego message.

One example use for the txt-handle is to pass a pointer to some workspace
into the child.

Ta,

Steve

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

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

#793

In message <5219d7bca2steve@revi11.plus.com>
          "Ste (news)" <steve@revi11.plus.com> wrote:

> In article <068f781952.martin@bach.planiverse.com>,
>    Martin Wuerthner <spamtrap@mw-software.com> wrote:
>> That is the "txt-handle", a unique handle assigned by your task to the
>> child it launches. You will see this in the TaskWindow_Ego, which will
>> tell you the child's proper task handle. The only purpose of the
>> txt-handle is to be quoted back to you in the TaskWindow_Ego message.

> One example use for the txt-handle is to pass a pointer to some workspace
> into the child.

Really? How does the child get hold of the txt-handle value?

Of course, the most obvious thing for the parent to use as the 
txt-handle is a pointer to some data structure that is associated with 
the child, so when receiving TaskWindow_Ego, the parent has immediate 
access to its own data relating to the child, but I cannot see how you 
could pass anything into the child using the txt-handle.

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

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

#799

In article <a930dc1952.martin@bach.planiverse.com>,
   Martin Wuerthner <spamtrap@mw-software.com> wrote:
> Really? How does the child get hold of the txt-handle value?

I'm sure that's what I did in the past but now you come to mention it, I
can't remember what the program was that implemented this so perhaps it
didn't work that way after all. Let me do some digging and get back to you
on that. :)

> Of course, the most obvious thing for the parent to use as the 
> txt-handle is a pointer to some data structure that is associated with 
> the child, so when receiving TaskWindow_Ego, the parent has immediate 
> access to its own data relating to the child, but I cannot see how you 
> could pass anything into the child using the txt-handle.

This is pretty much what I thought I'd done in the past...

Several fruitless searches later...

You're right, of course. I had used a pointer to a structure as the
txt-handle but only because that was a convenient number. I actually passed
the pointer to the child task later.

Ta,

Steve

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

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

#811

On 28-9-2011 20:52, Ste (news) wrote:
> In article <a930dc1952.martin@bach.planiverse.com>,
>   Martin Wuerthner <spamtrap@mw-software.com> wrote:
>> Of course, the most obvious thing for the parent to use as the 
>> txt-handle is a pointer to some data structure that is associated with 
>> the child, so when receiving TaskWindow_Ego, the parent has immediate 
>> access to its own data relating to the child, but I cannot see how you 
>> could pass anything into the child using the txt-handle.
> 
> This is pretty much what I thought I'd done in the past...
> 
> Several fruitless searches later...
> 
> You're right, of course. I had used a pointer to a structure as the
> txt-handle but only because that was a convenient number. I actually passed
> the pointer to the child task later.

The most straightforward way of passing information like a pointer to a
child when starting it up would be as a parameter on the command line.

Something like:

TaskWindow "<MyProgs>.myprog -pointer f745dba" -txt 123

where the '-pointer f745dba' part passes the info to the 'myprog' child
program. Note the placing of the quotes around the command string.

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

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

#826

On 28/09/2011 16:16, Martin Wuerthner wrote:
> In message<5219d7bca2steve@revi11.plus.com>
>            "Ste (news)"<steve@revi11.plus.com>  wrote:
>> One example use for the txt-handle is to pass a pointer to some workspace
>> into the child.
>
> Really? How does the child get hold of the txt-handle value?
>
> Of course, the most obvious thing for the parent to use as the
> txt-handle is a pointer to some data structure that is associated with
> the child, so when receiving TaskWindow_Ego, the parent has immediate
> access to its own data relating to the child, but I cannot see how you
> could pass anything into the child using the txt-handle.

Via the -txt parameter to *TaskWindow.

!Edit the original taskwindow managing application uses it to pass the 
handle of a RISCOS_Lib txt_window structure, hence the name 'txt-handle'.

---druck

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

#868

On 2-10-2011 17:13, druck wrote:
> On 28/09/2011 16:16, Martin Wuerthner wrote:
>> In message<5219d7bca2steve@revi11.plus.com>
>>            "Ste (news)"<steve@revi11.plus.com>  wrote:
>>> One example use for the txt-handle is to pass a pointer to some
>>> workspace
>>> into the child.
>>
>> Really? How does the child get hold of the txt-handle value?
> 
> Via the -txt parameter to *TaskWindow.
> 
> !Edit the original taskwindow managing application uses it to pass the
> handle of a RISCOS_Lib txt_window structure, hence the name 'txt-handle'.

Question remains: How exactly does the child read the value of the -txt
parameter that was passed to the TaskWindow command?

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

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

#869

On 13/10/2011 10:23, Erik G wrote:
> On 2-10-2011 17:13, druck wrote:
>> On 28/09/2011 16:16, Martin Wuerthner wrote:
>>> In message<5219d7bca2steve@revi11.plus.com>
>>>             "Ste (news)"<steve@revi11.plus.com>   wrote:
>>>> One example use for the txt-handle is to pass a pointer to some
>>>> workspace
>>>> into the child.
>>>
>>> Really? How does the child get hold of the txt-handle value?
>>
>> Via the -txt parameter to *TaskWindow.
>>
>> !Edit the original taskwindow managing application uses it to pass the
>> handle of a RISCOS_Lib txt_window structure, hence the name 'txt-handle'.
>
> Question remains: How exactly does the child read the value of the -txt
> parameter that was passed to the TaskWindow command?
>

I don't think you can - the only way I can think of would be to also 
pass it to the child as a command parameter, ie.

Taskwindow "bobfish &12345678" -txt &12345678

or something.

Alex.

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

#877

On 13/10/2011 10:23, Erik G wrote:
> On 2-10-2011 17:13, druck wrote:
>> On 28/09/2011 16:16, Martin Wuerthner wrote:
>>> In message<5219d7bca2steve@revi11.plus.com>
>>>             "Ste (news)"<steve@revi11.plus.com>   wrote:
>>>> One example use for the txt-handle is to pass a pointer to some
>>>> workspace
>>>> into the child.
>>>
>>> Really? How does the child get hold of the txt-handle value?
>>
>> Via the -txt parameter to *TaskWindow.
>>
>> !Edit the original taskwindow managing application uses it to pass the
>> handle of a RISCOS_Lib txt_window structure, hence the name 'txt-handle'.
>
> Question remains: How exactly does the child read the value of the -txt
> parameter that was passed to the TaskWindow command?

Define child. There are up to 4 actors:-

1) The TaskWindow module
2) Initiator - who or what issues *TaskWindow
3) Handler   - a wimp task which provides the window for taskwindow 
output, can be the same as (2)
4) The taskwindow task spawned by (1) when it receives (2)

I assume by child you mean (4), in which can it doesn't get the txt 
parameter, as it's there for the use of the Initiator (2) which in this 
case will also be the Handler (4), as anyone else using the *TaskWindw 
command can't know the internal information.

The Handler (3) gets the txt parameter TaskWindow_Ego message sent by 
(1) along with the task handle of the new taskwindow task (4), so the 
handler can associate the two, and know how to deal with subsequent 
messages quoting just the task handle.

That's a more complicating explanation than I intended, but never mind!

---druck

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

#887

On 15-10-2011 13:13, druck wrote:
> On 13/10/2011 10:23, Erik G wrote:
>> Question remains: How exactly does the child read the value of the -txt
>> parameter that was passed to the TaskWindow command?
> 
> Define child. There are up to 4 actors:-
> 
> 1) The TaskWindow module
> 2) Initiator - who or what issues *TaskWindow
> 3) Handler   - a wimp task which provides the window for taskwindow
> output, can be the same as (2)
> 4) The taskwindow task spawned by (1) when it receives (2)

That would be "Child" as defined on the first page of the TaskWindow
chapter of the PRM (page 3-321). As you correctly surmised, this would
be (4).

Although... there does not seem to be a distinction made there between
the task that is started by the WimpStartTask(TaskWindow) call, which
has a task handle, runs from code in the TaskWindow module and sends
messages to and receives messages from the Parent (which is (3) in this
context) on the one hand, and the command-line program which is started
with the "command" parameter of the TaskWindow command, runs its own
code in its own memory space and whose I/O is intercepted by that task
and converted to messages.

BTW, is a task only called a "task" if it has a taskhandle (which, I
believe, requires calling Wimp_Initialise)?

If so, what are programs called that are not a task? I used
"command-line program" above, but maybe there is an official (or better)
term.

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

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

#891

In message <4e9d8c5b$0$32484$e4fe514c@dreader21.news.xs4all.nl>
          Erik G <erikg@noname.invalid> wrote:

> On 15-10-2011 13:13, druck wrote:
>> On 13/10/2011 10:23, Erik G wrote:
>>> Question remains: How exactly does the child read the value of the -txt
>>> parameter that was passed to the TaskWindow command?
>> 
>> Define child. There are up to 4 actors:-
>> 
>> 1) The TaskWindow module
>> 2) Initiator - who or what issues *TaskWindow
>> 3) Handler   - a wimp task which provides the window for taskwindow
>> output, can be the same as (2)
>> 4) The taskwindow task spawned by (1) when it receives (2)

> That would be "Child" as defined on the first page of the TaskWindow
> chapter of the PRM (page 3-321). As you correctly surmised, this would
> be (4).

> Although... there does not seem to be a distinction made there between
> the task that is started by the WimpStartTask(TaskWindow) call, which
> has a task handle, runs from code in the TaskWindow module and sends
> messages to and receives messages from the Parent (which is (3) in this
> context) on the one hand, and the command-line program which is started
> with the "command" parameter of the TaskWindow command, runs its own
> code in its own memory space and whose I/O is intercepted by that task
> and converted to messages.

There is no distinction because there is only one task. The TaskWindow 
command starts the command-line program *as* a task. The TaskWindow 
module calls Wimp_Poll on its behalf to allow it to multitask, 
intercepts its output and sends messages on its behalf.

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

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

#810

On 27-9-2011 23:08, Martin Wuerthner wrote:
> In message <3613761952.davehigton@dsl.pipex.com>
>           Dave Higton <davehigton@dsl.pipex.com> wrote:
> 
>> I'm puzzled by the paragraph on PRM 3-326 that says:
> 
>> "-txt &xxxxxxxx an 8 digit hex number giving the handle for the Parent
>> to identify the Child by"
> 
>> What sort of handle is this, and how can I find whether the child task
>> is still running?
> 
> That is the "txt-handle", a unique handle assigned by your task to the 
> child it launches. You will see this in the TaskWindow_Ego, which will 
> tell you the child's proper task handle. The only purpose of the 
> txt-handle is to be quoted back to you in the TaskWindow_Ego message.
> 
> Once you got the proper task handle, you can suspend, resume or kill 
> your child task by sending it TaskWindow messages.

Also, using the '-txt" parameter stops the TaskWindow module from
actually opening a window for the output of the child program.

This is useful when you have an application from which you want to run a
command-line program, and handle the output of that program inside the
application.

*Without* the -txt parameter the TaskWindow command will open a
taskwindow as soon as the child program produces any output (or
immediately if the -display parameter is given). All output of the child
goes to the taskwindow, and all input must be given by typing in the
taskwindow.

The parent task won't get a TaskWindow_Ego message so won't know the
taskhandle of the child. If fact, I believe that the parent won't get
*any* messages concerning the child. This means no TaskWindow_Morio
message, so the parent won't know if the child has finished.


*With* the -txt parameter no taskwindow will be opened. All output of
the child will be passed to the parent via TaskWindow_Output messages,
and the parent can send input to the child via TaskWindow_Input messages.

See PRM 3-266 to 267 for a description of these messages and those
mentioned my Martin.


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

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

#814

In message <4e853be3$0$831$e4fe514c@dreader28.news.xs4all.nl>
          Erik G <erikg@noname.invalid> wrote:

> On 27-9-2011 23:08, Martin Wuerthner wrote:
> > In message <3613761952.davehigton@dsl.pipex.com>
> >           Dave Higton <davehigton@dsl.pipex.com> wrote:
> > 
> >> I'm puzzled by the paragraph on PRM 3-326 that says:
> > 
> >> "-txt &xxxxxxxx an 8 digit hex number giving the handle for the Parent
> >> to identify the Child by"
> > 
> >> What sort of handle is this, and how can I find whether the child task
> >> is still running?
> > 
> > That is the "txt-handle", a unique handle assigned by your task to the 
> > child it launches. You will see this in the TaskWindow_Ego, which will 
> > tell you the child's proper task handle. The only purpose of the 
> > txt-handle is to be quoted back to you in the TaskWindow_Ego message.
> > 
> > Once you got the proper task handle, you can suspend, resume or kill 
> > your child task by sending it TaskWindow messages.
> 
> Also, using the '-txt" parameter stops the TaskWindow module from
> actually opening a window for the output of the child program.
> 
> This is useful when you have an application from which you want to run a
> command-line program, and handle the output of that program inside the
> application.
> 
> *Without* the -txt parameter the TaskWindow command will open a
> taskwindow as soon as the child program produces any output (or
> immediately if the -display parameter is given). All output of the child
> goes to the taskwindow, and all input must be given by typing in the
> taskwindow.
> 
> The parent task won't get a TaskWindow_Ego message so won't know the
> taskhandle of the child. If fact, I believe that the parent won't get
> *any* messages concerning the child. This means no TaskWindow_Morio
> message, so the parent won't know if the child has finished.
> 
> 
> *With* the -txt parameter no taskwindow will be opened. All output of
> the child will be passed to the parent via TaskWindow_Output messages,
> and the parent can send input to the child via TaskWindow_Input messages.
> 
> See PRM 3-266 to 267 for a description of these messages and those
> mentioned my Martin.

What I'm getting is that the taskwindow is only opened if /neither/
-task nor -txt argument is given.  This is disastrous, because the
whole point of using a taskwindow (in my case) is to present output
from a command line programme.  I don't want to have to do the
textifying and window drawing myself.

I also need to know when the child task has finished.  I need the
Morio message but not the Ego.

I'm sure I had it working earlier in the week, but it sure won't
behave the way I need it to now.  I can get either the Ego/Morio
messages or a taskwindow, but not both.

Dave

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

#815

On 30/09/2011 23:38, Dave Higton wrote:

> What I'm getting is that the taskwindow is only opened if /neither/
> -task nor -txt argument is given.

Because TaskWindow passes around a message in that case saying "can 
anybody deal with this?" and I think if somebody can, it is up to them 
to start up the task, and TaskWindow talks to them and them alone.


> This is disastrous, because the whole point of using a taskwindow
> (in my case) is to present output from a command line programme.
> I don't want to have to do the textifying and window drawing myself.

Off the top of my head, this is a really grotty hacky man-in-the-middle 
idea.


Right, if the TaskWindow module passes TaskWindow_NewTask (&808C5) to 
find a suitable handler, then what YOU should do is broadcast this 
message yourself, specifying a dummy command line. Something ought to 
bite (!Edit, !Zap, whatever).

Then you call TaskWindow to run your desired task, as if you dealt with 
the entire process. You'll get the Egos and Morios and so forth.

HOWEVER, when the TaskWindow creates output, you'll just pass it right 
on to whatever task is actually displaying the output. Likewise for 
input in the other direction. You just sit in the middle passing 
messages and taking note...

    .----------.                     .-------.
    |TaskWindow|       .-----.       |Display|
    |   task   | <---> | YOU | <---> |handler|
    '----------'       '-----'       '-------'

         ^                               ^
         '- - - - - - - - - - - - - - - -'
         TaskWindow task thinks you are a
         display/input handler. Display/input
         handler thinks you are a TaskWindow task.

Not terribly elegant (neither's the ASCII art ;-) ), but then messing 
with FilterManager (another approach, perhaps) could be equally grotty.


Best wishes,

Rick.

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

#816

In message <4e868de7$0$18793$ba4acef3@reader.news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> On 30/09/2011 23:38, Dave Higton wrote:

>> What I'm getting is that the taskwindow is only opened if /neither/
>> -task nor -txt argument is given.

> Because TaskWindow passes around a message in that case saying "can
> anybody deal with this?" and I think if somebody can, it is up to them
> to start up the task, and TaskWindow talks to them and them alone.

Yes, exactly.

>> This is disastrous, because the whole point of using a taskwindow
>> (in my case) is to present output from a command line programme.
>> I don't want to have to do the textifying and window drawing myself.

> Off the top of my head, this is a really grotty hacky man-in-the-middle
> idea.

> Right, if the TaskWindow module passes TaskWindow_NewTask (&808C5) to
> find a suitable handler, then what YOU should do is broadcast this
> message yourself, specifying a dummy command line. Something ought to
> bite (!Edit, !Zap, whatever).

> Then you call TaskWindow to run your desired task, as if you dealt with
> the entire process. You'll get the Egos and Morios and so forth.

Yes, that is a nice idea, but it needs a bit more effort to actually 
work because the other task (the actual server that displays the 
window) needs to see the Ego and Morio messages with its own 
txt-handle quoted back to it, so it thinks your task is the TaskWindow 
task. Otherwise, it will not be willing to receive any input from you.

So, the command you pass around in the NewTask message cannot be 
entirely dummy. It needs to be a command that allows your task to find 
out the txt-handle the other task specified (you need it for the Ego 
message you will send to the actual server), plus you need to find out 
which other task has actually claimed the request, so you can send 
messages to it.

One way to do that is to make the other task run a utility that sends 
a message containing its parameters (which include the task and 
txt-handles) to your task. A less complicated approach would be make 
the other task run an Obey file that stores its parameters in a system 
variable (which is safe as long as the variable name contains your 
tasks's internal unique handle for the TaskWindow job, i.e., something 
like <YourTask>$ExternalTaskWindow<handle>). Then, your task just 
needs to monitor that variable, and when it is set, extract the task 
and txt-handle values from it and remember them.

Once your task has the task and txt-handle values of the actual 
server, it can issue the TaskWindow command passing its own task and 
txt-handle values. Then, when your task receives the Ego message, it 
needs to pass it on to the actual server, substituting the txt-handle 
it got from the other task, and from that point on, the server knows 
your task, so it can make sense of all the other messages you pass on 
to it, most notably the Output messages and (finally) the Morio 
message.

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

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

#817

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

> What I'm getting is that the taskwindow is only opened if /neither/
> -task nor -txt argument is given.

Let me correct this.  Here's what I get for all four combinations:

-task -txt Ego+Morio Window
  no   no    no        yes
  no   yes   no        yes
  yes  no    yes       no
  yes  yes   yes       no

My apologies for last night's wrong posting.  The fact that I
get /either/ Ego+Morio /or/ an open window is correct; but it
depends solely on passing -task.

I was wondering about having to do the scheme Rick suggested.
Thanks, Martin, for pointing out the further pitfalls.

It's a shame that it works like it does.  I'd have thought that
what I want to do is the simplest and most obvious thing that
anybody would want to use a taskwindow for: to run a command
line app in a window /and/ to get notification when it finishes.

Dave

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

#818

On 1 Oct, Dave Higton wrote in message
    <c6107e1b52.davehigton@dsl.pipex.com>:

> It's a shame that it works like it does.  I'd have thought that what I
> want to do is the simplest and most obvious thing that anybody would want
> to use a taskwindow for: to run a command line app in a window /and/ to
> get notification when it finishes.

I've not read the whole thread, so I may have missed some nuance of what
you're trying to do, but surely you can do what PrintPDF does?  That simply
records the task handle of the GhostScript task that it spawns in a task
window and then watches Message_TaskCloseDown for the same task handle,
indicating that the process has ended.

The window is initially hidden, but any output from GhostScript (such as an
error stack) will cause it to open.

You're welcome to see the PrintPDF source, although it is written in C.

-- 
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

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

#819

On 01/10/2011 21:51, Steve Fryatt wrote:

> records the task handle of the GhostScript task that it spawns in a task
> window and then watches Message_TaskCloseDown for the same task handle,
> indicating that the process has ended.

I had thought that would be a fairly obvious answer prior to my 
convoluted suggestion; however I didn't encounter a *certain* way to be 
sure that the task that is started at that time is *really* the handle 
of the task.

This is why the -txt parameter is quoted back to you. From that message, 
you can pick up on the task handle of the child.

While it used to be a fair bet that "if a task is seen to start as I ask 
a task to start, it'll be mine", these days you can't be so sure - it 
could be a dialler application invoking a mail fetch, or something like 
that which periodically runs in the background that might just happen to 
start at the same time. While it might seem like a stretch, even one 
wrong assumption in a hundred could wind up as "a lot" (my mail is 
checked every five minutes; that's 12 times an hour for as long as 
Thunderbird is loaded (or once every 15 minutes by my phone otherwise)). 
In short, a one-in-a-hundred could be every other day...

I read all around the PDF PRM and I just can't find a definitive way to 
get TaskWindow to say "my task handle is..." to a task that didn't 
invoke it. Spent far too long actually, it would have been quicker to 
hack the source to stuff in a Broadcast Message, and Bob's yoruncle. ;-)


Best wishes,

Rick.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web