TaskObey-window without output

[fre...@freakmail.de]

Hallo,

on my RISC PC (ROS 4.02) I use a TaskObey-file, already for years. And
when double-clicking on it, it's always working without any output
(because there is no output).

Since using the same script on my BBxM (ROS 5.19), now always an empty
Taskwindow opens. It's pointless, if I use Zap or Edit for the
Taskwindow, both produce the empty window.
Trying to call the TaskObey-File from another Obey-File, redirecting
the output to "null:" didn't have the wished result either.

Is there anything I can do, to supress this behaviour?

Thanks in advance,
greetings, Juergen

[Jeremy Nicoll - news posts]

IIRC there's a parameter on the command that starts a taskwindow that
dictates whether the window will open immediately or will wait and only open
when some output is generated. A taskobey file has filetype &FD7.

If I look at the command associated with that sort of file, here, I see

Alias$@RunType_FD7 : TaskWindow |"Obey %*0|" -name |"Task Obey|" -quit

that's to say when you run a TaskObey file the system runs the TaskWindow
command with parameters to run an Obey command inside it, set the window
title to "Task Obey" and so on. To find out what parameters can be used:

*help taskwindow
==> Help on keyword TaskWindow (alias)
*TaskWindow is an aliased command.
Expansion: StrongTask %*0

==> Help on keyword TaskWindow
The *TaskWindow command allows a background task to be started, which will
obtain a task window if it needs to do any screen I/O.
<command> is the command to be executed
-wimpslot sets the memory to be allocated
-name sets the task name
-ctrl allows control characters through
-display opens the task window immediately, rather than waiting for
a character to be printed
-quit makes the task quit after the command even if the task window
has been opened
Note that fields must be in " " if they comprise more than one word
Syntax: *TaskWindow [<command>] [[-wimpslot] <n>K] [[-name] <taskname>]
[-ctrl] [-display] [-quit]

==> Help on keyword TaskWindow
Module is: TaskWindow 0.76 (04 Dec 2003)

Commands provided:
ShellCLI_Task ShellCLI_TaskQuit TaskWindow
*

So it looks to me as if one of your systems has "-display" in the command
and one does not.

Probably the command is defined when you start whichever editor you use to
support the TaskWindow environment. If you want a different process to take
place you need to redefine the contents of system variable

Alias$@RunType_FD7

by issuing an appropriate *set command.

Does that help?

--
Jeremy C B Nicoll - my opinions are my own.

Email sent to my from-address will be deleted. Instead, please reply
to newsre...@wingsandbeaks.org.uk replacing "aaa" by "284".

[fre...@freakmail.de]

In Nachricht <mpro.mkou83...@wingsandbeaks.org.uk.invalid>
Jeremy Nicoll - news posts
<jn.nntp....@wingsandbeaks.org.uk> haben Sie geschrieben:

> IIRC there's a parameter on the command that starts a taskwindow that
> dictates whether the window will open immediately or will wait and only open
> when some output is generated. A taskobey file has filetype &FD7.

> If I look at the command associated with that sort of file, here, I see

> Alias$@RunType_FD7 : TaskWindow |"Obey %*0|" -name |"Task Obey|" -quit

...

> ==> Help on keyword TaskWindow
> Module is: TaskWindow 0.76 (04 Dec 2003)

...

> So it looks to me as if one of your systems has "-display" in the command
> and one does not.

> Probably the command is defined when you start whichever editor you use to
> support the TaskWindow environment. If you want a different process to take
> place you need to redefine the contents of system variable

> Alias$@RunType_FD7

> by issuing an appropriate *set command.

> Does that help?

> --
> Jeremy C B Nicoll - my opinions are my own.

> Email sent to my from-address will be deleted. Instead, please reply
> to newsre...@wingsandbeaks.org.uk replacing "aaa" by "284".

Hallo Jeremy,

thanks for your answer, and sorry for my late reply.

Learned a bit about taskwindows from you (really :-) !), but
unfortunatly it didn't help me.
The "-display"-option isn't set anywhere, and I couldn't find any
other differences between the two scripts and the containing command.
Also the Alias-variable was set the same way as written by you.
Even the (at least in each case only) command in the scripts has the
same version, I explicitly copied the called file to both computers.

As an interim solution I re-typed the script from "Taskobey" to
"Obey". When calling the script now, no window opens. Probably ROS
5.19 handles a taskobey-file in another way ROS 4.02 (or other) do.

Help taskwindow gives the following output, usualy I'm using Zap:

==> Help on keyword TaskWindow

Module is: TaskWindow 0.75 (26 Apr 2012)


Greetings, Juergen

[Ron]

In message <284e533753.JF@freak67>
fre...@freakmail.de wrote:

<snip>

>
> As an interim solution I re-typed the script from "Taskobey" to
> "Obey". When calling the script now, no window opens. Probably ROS
> 5.19 handles a taskobey-file in another way ROS 4.02 (or other) do.
>

If you are calling the script from an Obey file (or others, probably),
you can use Taskwindow <scriptname>
and you will still get the benefits of running it as a task without
the display ( if there is no output to vdu: )
The benefits are sometimes visually subtle, and you might not need them.
I have seen it help get past an error so the calling program can
continue.
If you really need to click and run it, maybe you'll have to make
it into a plink application so the !Run file calls the taskwindow.
You have the advantage of assigning a sprite and a bit more power
because of the extra level you get from the !Run file.

HTH
Ron M. RO 5.18

[Jeremy Nicoll - news posts]

fre...@freakmail.de wrote:

>Help taskwindow gives the following output, usualy I'm using Zap:
>==> Help on keyword TaskWindow
>Module is: TaskWindow 0.75 (26 Apr 2012)

That's not very informative about what options, if any, Zap supports. My
system was based on a fairly old StrongED's StrongTask. I think you may
need to wait until a Zap expert happens along...

The other possibility is that something in your (Task)Obey file actually
does generate output under one OS but not the other. You could epperiment
with some very simple single-command TaskObey files and see if you always
get the same difference in behaviour, and if not, which contained command
causes the problem.

[druck]

On 03/04/2013 02:32, fre...@freakmail.de wrote:
> on my RISC PC (ROS 4.02) I use a TaskObey-file, already for years. And
> when double-clicking on it, it's always working without any output
> (because there is no output).
>
> Since using the same script on my BBxM (ROS 5.19), now always an empty
> Taskwindow opens. It's pointless, if I use Zap or Edit for the
> Taskwindow, both produce the empty window.
> Trying to call the TaskObey-File from another Obey-File, redirecting
> the output to "null:" didn't have the wished result either.

That wont work as each line in a Task Obey is run as an individual WimpTask.

> Is there anything I can do, to supress this behaviour?

You'll need to put a redirection on every line in TaskObey files.

I haven't checked, but alternatively you could also try changing the
TaskObey to a normal Obey and then call that from a new TaskObey,
redirecting the output of the Obey.

e.g. A TaskObey contains:-

Run <Obey$Dir>.MyObeyFile { > null: }

---druck