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 2 of 2 — ← Prev page 1 [2]

#820

Grr.  Sticky Ctrl keys are a menace.  What I'd meant to post, before it
fired prematurely, was...

On 1 Oct, Rick Murray wrote in message
    <4e877c2c$0$18793$ba4acef3@reader.news.orange.fr>:

> 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.

Um.  I might be missing something, but PrintPDF does

  snprintf(command, sizeof(command),
    "TaskWindow \"gs @%s\" %dk -name \"%s\" -quit",
    config_str_read("ParamFile"), config_int_read("TaskMemory"), taskname);
  error = xwimp_start_task(command, &conversion_task);

and then hangs the following off Message_TaskCloseDown:

  if (message != NULL && message->sender == conversion_task &&
      !convert_progress(NULL)) {
    conversion_task = 0;
    conversion_in_progress = CONVERSION_STOPPED;
    convert_remove_current_conversion();
  }

-- 
Steve Fryatt - Leeds, England

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

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

#821

On 1 Oct, Rick Murray wrote in message
    <4e877c2c$0$18793$ba4acef3@reader.news.orange.fr>:

> 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.

Um.  I might be missing something, but PrintPDF does

  /* Write all the taskwindow command line details to the command string. */

  snprintf(command, sizeof(command),
    "TaskWindow \"gs @%s\" %dk -name \"%s\" -quit",
    config_str_read("ParamFile"), config_int_read("TaskMemory"), taskname);

  /* Launch the conversion task. */

  error = xwimp_start_task(command, &conversion_task);





> 
> 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.
> 
> 
> 


-- 
Steve Fryatt - Leeds, England

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

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

#822

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

> 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.

Wimp_StartTask returns the handle of the child task in R0.

Dave

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

#823

In message <mpro.lsekib00pcmxs01jl.news@stevefryatt.org.uk>
          Steve Fryatt <news@stevefryatt.org.uk> wrote:

> 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.

Brilliant, Steve.  Thanks for pointing out what should have been
bleeding obvious to me.

It works now.

Dave

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

#885

On 1-10-2011 21:20, Dave Higton wrote:
> 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

This surprised me a bit. What PRM 3-326 says about the *TaskWindow
command is:

"If -txt and -task are not used, then [a server, eg Edit, is started to
show the output in a window]".

I read this as: if either -txt or -task is used, no window is opened.

The table above shows that -task is the controlling parameter, which
determines if a server is used to show a window. The -txt parameter is
optional. Using -txt without -task has no effect (since no Ego message
is sent, which is the only place the value of the -txt parameter is used).

So when can a calling program leave out the -txt parameter? My theory is
that it is possible to do so if the calling task is absolutely certain
that the Taskwindow_Ego message it gets is about that one specific child
it has just issued the *TaskWindow command for. Basically it should not
issue another *TaskWindow command before it has received an Ego message
for the previous one.

I will investigate what the value of R1+20 in the TaskWindow_Ego message
is if no -txt parameter is given. It could be 0, it could be random.
(Though I can't test now, as my VirtualRPC is on the blink again :-( ).

Personally I would advise to always use the -txt parameter. If only to
save the bother of putting it in afterwards when it turns out the
program needs to handle more than one child at the same time after all.

New question: what should an application do if the value in a
TaskWindow_Ego message it receives does not match any value it knows about?

I think the calling application should send a TaskWindow_Morite message
to the child (who's handle in R1+4 of Ego message) in an attempt to kill
off the rogue child. And maybe show an error message to the user.

If the Ego message came from a genuine TaskWindow task, then the problem
is due to an internal error in the calling application, and the Morite
message will ensure no child lingers around.

If the Ego message came from some damned fool program sending or
broadcasting silly messages, then the Morite message will do no harm.

Any other suggestions?

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

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

#886

On 18-10-2011 15:23, Erik G wrote:
> [snip: loads o'stuff]

BTW: I think I'll start an article on the use of TaskWindow to run
programs that do not call Wimp_Poll (i.e. command-line programs) on
<http://www.riscos.info/>.

Subjects covered:

- How to call TaskWindow so the I/O of the child is done in a window
handled by a server (typically a text editor). This will also mention
the way to detect that the child has finished, which was the original
question of this thread.

- How to call TaskWindow so your program itself handles the I/O of the
child. Handy if you want to process the output of the child directly.
This involves the use of the -task and -txt parameters.

- (Possibly) How to make your text editor program work as a TaskWindow
Server.

There will be room for a more detailed description of the parameters of
the TaskWindow command and how messages should be handled.

What would be a good page title for this article? I'm looking for
something that mentions TaskWindow and is more descriptive than just
"TaskWindow". Like:

- Using TaskWindow (not descriptive enough to my taste).
- Using TaskWindow to start non-task programs (a bit long).
- Using TaskWindow to start programs (too vague?).
- Handling command-line programs (does not mention TaskWindow).

etc, etc.

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

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

#895

On 18/10/2011 14:23, Erik G wrote:
> This surprised me a bit. What PRM 3-326 says about the *TaskWindow
> command is:
>
> "If -txt and -task are not used, then [a server, eg Edit, is started to
> show the output in a window]".
>
> I read this as: if either -txt or -task is used, no window is opened.

That's correct, with neither of the parameters it means use the default 
taskwindow handler application (starting it if necessary), and as such 
can be issued by either a program or the user at the command line.

If the parameters are supplied it means that a program wants to to start 
a taskwindow task and handle the output itself. Hence no window is 
automatically opened, and the Ego is sent round to allow the program to 
identify the started task.

> The table above shows that -task is the controlling parameter, which
> determines if a server is used to show a window. The -txt parameter is
> optional. Using -txt without -task has no effect (since no Ego message
> is sent, which is the only place the value of the -txt parameter is used).

I can't see the point of that right now, although there might be one.

> So when can a calling program leave out the -txt parameter? My theory is
> that it is possible to do so if the calling task is absolutely certain
> that the Taskwindow_Ego message it gets is about that one specific child
> it has just issued the *TaskWindow command for. Basically it should not
> issue another *TaskWindow command before it has received an Ego message
> for the previous one.

I concur. I've always used both looks like bad practice not to.

> Personally I would advise to always use the -txt parameter. If only to
> save the bother of putting it in afterwards when it turns out the
> program needs to handle more than one child at the same time after all.

Agreed.

> New question: what should an application do if the value in a
> TaskWindow_Ego message it receives does not match any value it knows about?

In general you should ignore any broadcast message which contains 
handles you don't recognise. If it's sent specifically to your task you 
may decide to take further action.

> I think the calling application should send a TaskWindow_Morite message
> to the child (who's handle in R1+4 of Ego message) in an attempt to kill
> off the rogue child. And maybe show an error message to the user.

You could do that, I'm not sure it's an error case worth handling, as it 
most likely you've supplied the wrong handle to yourself and will notice 
that bug very quickly, and somewhat less likely that the TaskWindow 
module has gone berserk.

> If the Ego message came from a genuine TaskWindow task, then the problem
> is due to an internal error in the calling application, and the Morite
> message will ensure no child lingers around.

It's sometimes worth leaving the orphan task window task in the task 
manager list, as then the bug is more obviously that you aren't picking 
up the Ego, rather than killing it and not being sure that the task was 
ever started.

> If the Ego message came from some damned fool program sending or
> broadcasting silly messages, then the Morite message will do no harm.

Maybe!

---druck

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

#870

Following this discussion of TaskWindow messages, I wanted to comment on 
the, um, interesting names of the TaskWindow messages.

For starters, TaskWindow_Ego. This is easy to misinterpret, for these 
days we think of "ego" in terms alongside Id and Super-ego; though its 
origin is that of self (hence "egotistical"). And what does TaskWindow 
do here? Announces it's own handle.

Then there's TaskWindow_Morio. I could not find a direct translation for 
this stuff, it would appear to me to be a sort of mixture of Latin and 
Italian. And Morio would appear to mean "died", which is exactly what 
TaskWindow says when the child task exits.

Finally, we have TaskWindow_Morite, and this would appear to mean "die" 
as in "DIE!". Meaning to TaskWindow? Kill the child task.

By comparison, Input/Output and Suspend/Resume are quite boring.


Maybe we ought to have:

   808C0 TW_Cibare    808C4 TW_Morite
   808C1 TW_Exuro     808C5 TW_Aduivare
   808C2 TW_Ego       808C6 TW_Claudus
   808C3 TW_Morio     808C7 TW_Sese

;-)


Best wishes,

Rick.

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

#871

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

> I could not find a direct translation for 
> this stuff, it would appear to me to be a sort of mixture of Latin and 
> Italian. 

Years ago I emailed my peeve, on what forum I cannot now recall, that
Acorn, then situated in a city well endowed with classical scholars,
should have been so crass and pretentious as to try their hand at Latinity
and fall flat on their face. You would have thought somebody might have
checked it out.

"I die" is "morior" - there is no Latin word "morio" as far as I know.
"die!" is "morere" if addressed to one person, and "morimini" if to
several - there is no Latin word "morite" as far as I know.
 
-- 
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

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

#872

In message <3796002252.wra1th@wra1th.plus.com>
          Gavin Wraith <gavin@wra1th.plus.com> wrote:

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

>> I could not find a direct translation for
>> this stuff, it would appear to me to be a sort of mixture of Latin and
>> Italian.

> Years ago I emailed my peeve, on what forum I cannot now recall, that
> Acorn, then situated in a city well endowed with classical scholars,
> should have been so crass and pretentious as to try their hand at Latinity
> and fall flat on their face. You would have thought somebody might have
> checked it out.

> "I die" is "morior" - there is no Latin word "morio" as far as I know.
> "die!" is "morere" if addressed to one person, and "morimini" if to
> several - there is no Latin word "morite" as far as I know.

It is not that bad. "Morite" is perfect Italian and does mean "die!" 
(addressed to several persons or one person addressed with the 
referential "voi"). And "morio" *is* actually perfect Latin after all. 
It means "fool". Go figure. :-)

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

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

#879

On 14/10/2011 13:26, Martin Wuerthner wrote:

> It is not that bad. "Morite" is perfect Italian and does mean "die!"
> (addressed to several persons or one person addressed with the
> referential "voi"). And "morio" *is* actually perfect Latin after all.
> It means "fool". Go figure. :-)

Yup.

Not because I'm smart or anything, just in the course of writing my 
message I spent a good few minutes playing with Google Translate (is it 
a rule that Latin is supposed to be written in uppercase?).

The only real issue I have about Translate is I really *REALLY* wish it 
would own up to words it doesn't know and drop them in square brackets 
to indicate translation failure. Example:

   "this is absolute bogusness" -> "ce n'est bogusness complète"

I'm not sure why it has the "n'est" instead of just being "c'est", but 
anyway, is "bogusness" a French word? Is it even an English word? Switch 
to Japanese and the translation fail becomes apparent:
   "これは完全なbogusnessです"  (kore wa kanzen'na bogusnessdesu)

However, even in Japanese words in roman characters crop up (poor 
people, that gives 'em four writing systems to contend with...) so we're 
back to square one - is this *really* how you write such a phrase, or is 
it an unknown word?

For what it's worth, how about "ボガスネッス" (bogas(u)ness(u))? (^_^)

</rant>


Best wishes,

Rick.

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

#881

On 14 Oct 2011 Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:
> Following this discussion of TaskWindow messages, I wanted to comment on
> the, um, interesting names of the TaskWindow messages.

The first thing I did when I started programming with the TaskWindow 
module was to create aliases for the TaskWindow messages in English 
rather than pseudo Latin, so I knew if I was coming or going!

Acorn's software QA department must have been on holiday the week that 
API was released, as you don't fine such nonsense anywhere else in the 
OS.

---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]

#883

druck <news@druck.freeuk.com> wrote:

> Acorn's software QA department must have been on holiday the week that 
> API was released, as you don't fine such nonsense anywhere else in the 
> OS.

You mean you don't think names like SWI Pelvis_ReperioPelvis would be
clearer? :-)

(beware literal translations!)

-- 
Stewart Brodie

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

#896

On 16/10/2011 23:28, Stewart Brodie wrote:
> druck<news@druck.freeuk.com>  wrote:
>
>> Acorn's software QA department must have been on holiday the week that
>> API was released, as you don't fine such nonsense anywhere else in the
>> OS.
>
> You mean you don't think names like SWI Pelvis_ReperioPelvis would be
> clearer? :-)

Makes naming them after Cambridge colleges far less cryptic!

---druck

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web