It is ages since I've been programming so apologies if this is a silly question.
Is there a way to call GhostScript from inside a BASIC program and return control to the BASIC program afterwards? I've just tried invoking GhostScript from a program using an OSCLI command but although
GhostScript then runs correctly it does not hand back control to the
BASIC program which just ends. I think I understand why it is happening
but is there any way to get around it?
On 8 Jun 2020 as I do recall,
Rob Hemmings (News) wrote:
It is ages since I've been programming so apologies if this is a silly question.
Is there a way to call GhostScript from inside a BASIC program and return control to the BASIC program afterwards? I've just tried invoking GhostScript from a program using an OSCLI command but although
GhostScript then runs correctly it does not hand back control to the
BASIC program which just ends. I think I understand why it is happening but is there any way to get around it?
Wimp_StartTask will launch a program from within BASIC, and will return
the task handle in R0 if successful.
SYS"Wimp_StartTask",cmd$ TO handle%
In Infozip, in order to avoid freezing the desktop I launched the
'child' task in a taskwindow, recorded the task handle as child%, then listened in on Wimp_Poll for the Wimp message &400C3 (TaskCloseDown)
being broadcast in order to detect when the child had finished. This is
a fairly crude approach which only allows for one child task to be
running at a time.
Wimp_StartTask will launch a program from within BASIC, and will return
the task handle in R0 if successful.
SYS"Wimp_StartTask",cmd$ TO handle%
In Infozip, in order to avoid freezing the desktop I launched the
'child' task in a taskwindow, recorded the task handle as child%, then listened in on Wimp_Poll for the Wimp message &400C3 (TaskCloseDown)
being broadcast in order to detect when the child had finished. This is
a fairly crude approach which only allows for one child task to be
running at a time.
On 2020-06-08, Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:
Wimp_StartTask will launch a program from within BASIC, and will return
the task handle in R0 if successful.
SYS"Wimp_StartTask",cmd$ TO handle%
Yes, this is pretty much how it works.
In Infozip, in order to avoid freezing the desktop I launched the
'child' task in a taskwindow, recorded the task handle as child%, then listened in on Wimp_Poll for the Wimp message &400C3 (TaskCloseDown)
being broadcast in order to detect when the child had finished. This is
a fairly crude approach which only allows for one child task to be
running at a time.
This isn't a great idea, however, as it fails with at least one of the popular TaskWindow providers (and ISTR that InfoZip has this problem, although I'm not 100% certain). There's no guarantee when calling Wimp_StartTask with *TaskWindow that the returned handle will be for the
task that you're interested in.
The better way is to check the handle returned from Wimp_StartTask to make sure that it isn't zero, which tells you that something has happened. Then listen out for Message_TaskInitialise, and check the names of new tasks to see if they match the one that you're expecting to start up. When you find it, you know the task handle from the sender field of the message block.
The key point is to launch the child by passing
TaskWindow <command> -wimpslot <slot> -name <name> -quit
-task <my_task_handle> -txt <arbitrary_id>
(obviously, all in one line) to Wimp_StartTask.
Then, you listen for the messages that TaskWindows sends to the given handle (i.e., to your application since you passed your own task handle), most notably TaskWindow_Ego, which tells your application the handle of your child.
Steve Fryatt <news@stevefryatt.org.uk> wrote:
On 2020-06-08, Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:
That might be better, but there is still more guesswork involved and
less control than using the TaskWindow protocol, which was specifically designed to allow tasks to control their TaskWindow children. Using
this protocol also makes you independent of any registered TaskWindow provider since your application itself becomes the TaskWindow provider.
The key point is to launch the child by passing
TaskWindow <command> -wimpslot <slot> -name <name> -quit
-task <my_task_handle> -txt <arbitrary_id>
(obviously, all in one line) to Wimp_StartTask.
Then, you listen for the messages that TaskWindows sends to the given
handle (i.e., to your application since you passed your own task
handle), most notably TaskWindow_Ego, which tells your application the
handle of your child. If you run several children, you can distinguish
them because the Ego message quotes the arbitrary id you passed. TaskWindow_Morio tells you that your child has died. While the child
runs, you can suspend it, resume it and kill it by sending messages TaskWindow_Suspend/Resume/Morite to your child handle. By listening to TaskWindow_Output you can receive the output of your child, e.g., any
error messages from Ghostscript.
That is how GView (http://www.mw-software.com/software/gview/gview.html) calls Ghostscript.
On 8 Jun 2020 as I do recall,
Martin Wuerthner wrote:
Then, you listen for the messages that TaskWindows sends to the given handle >> (i.e., to your application since you passed your own task handle), most
notably TaskWindow_Ego, which tells your application the handle of your
child.
Ah, that looks *much* more elegant than hacking around by doing literal string comparisons (which sounds like a recipe for obscure bugs in the future)... except that from the StronHelp manuals it sounds rather as
if you need to duplicate all functionality of the Taskwindow handler yourself, e.g. when the child task produces output, you need to display
the data. :-(
On 08/06/2020 21:15, Harriet Bazley wrote:
On 8 Jun 2020 as I do recall,
Martin Wuerthner wrote:
Then, you listen for the messages that TaskWindows sends to the
given handle (i.e., to your application since you passed your own
task handle), most notably TaskWindow_Ego, which tells your
application the handle of your child.
Ah, that looks *much* more elegant than hacking around by doing literal string comparisons (which sounds like a recipe for obscure bugs in the future)... except that from the StronHelp manuals it sounds rather as
if you need to duplicate all functionality of the Taskwindow handler yourself, e.g. when the child task produces output, you need to display
the data. :-(
You don't have to display the TaskWindow's task's output in a scrolling window. If you are calling a program to process a file (as in this case
with Ghostscript) the only output you are interested in is error
messages, and you can capture this output and display in an error box.
On 9 Jun 2020 as I do recall,
druck wrote:
On 08/06/2020 21:15, Harriet Bazley wrote:
On 8 Jun 2020 as I do recall,
Martin Wuerthner wrote:
Then, you listen for the messages that TaskWindows sends to the
given handle (i.e., to your application since you passed your own
task handle), most notably TaskWindow_Ego, which tells your
application the handle of your child.
Ah, that looks *much* more elegant than hacking around by doing literal string comparisons (which sounds like a recipe for obscure bugs in the future)... except that from the StronHelp manuals it sounds rather as
if you need to duplicate all functionality of the Taskwindow handler yourself, e.g. when the child task produces output, you need to display the data. :-(
You don't have to display the TaskWindow's task's output in a scrolling window. If you are calling a program to process a file (as in this case with Ghostscript) the only output you are interested in is error
messages, and you can capture this output and display in an error box.
Yes, but from Infozip's point of view I'm launching a program which can potentially prompt the user for input (and will hang mysteriously if it
fails to get it). Unfortunately detecting the identity of the child
with TaskWindow_Ego doesn't sound as if it will work, if I can only do
that by taking over the entire taskwindow handling myself.
I'd like to be able to use return codes from a unixlib program
but when called from an Obey file.
It looks like the only way to do this would be to have either a BASIC
or C wrapper/shell to do the running.
The only advantage would be that it could set a system variable that
an Obey file could read for any programs return code, avoiding setting
the system variable in every individual (ported) program.
On 13/06/2020 02:01, Ronald wrote:
I'd like to be able to use return codes from a unixlib program
but when called from an Obey file.
It looks like the only way to do this would be to have either a BASIC
or C wrapper/shell to do the running.
The only advantage would be that it could set a system variable that
an Obey file could read for any programs return code, avoiding setting
the system variable in every individual (ported) program.
RISC OS already does this, Sys$ReturnCode should be set to the result
from the program, but note that not all programs return a non zero code
in the case of an error.
---druck
It is ages since I've been programming so apologies if this is a silly question.
Is there a way to call GhostScript from inside a BASIC program and return control to the BASIC program afterwards? I've just tried invoking GhostScript from a program using an OSCLI command but although
GhostScript then runs correctly it does not hand back control to the
BASIC program which just ends. I think I understand why it is happening
but is there any way to get around it?
I guess checking for a file or system variable to be set with some sort of wimp poll so it's not grinding away in a loop. I've been experimenting
with pause%=INKEY 2000 any key press will stop the wait, useable to a
degree.
On 14 Jun, Ronald wrote in message
<d5bc4f8058.beeb@-.->:
I guess checking for a file or system variable to be set with some sort of wimp poll so it's not grinding away in a loop. I've been experimenting
with pause%=INKEY 2000 any key press will stop the wait, useable to a degree.
If you don't want to do the Message_TW_* stuff, then Message_TaskInitialise and Message_TaskCloseDown, as I originally posted. That way, there's no polling and no ugly time delay stuff: you just get messages sent in when there's something new to test against.
In message <mpro.qbwl7i0191pbo01u8.news@stevefryatt.org.uk>
Steve Fryatt <news@stevefryatt.org.uk> wrote:
If you don't want to do the Message_TW_* stuff, then
Message_TaskInitialise and Message_TaskCloseDown, as I originally
posted. That way, there's no polling and no ugly time delay stuff: you
just get messages sent in when there's something new to test against.
So where is the waiting done,
with Message_TaskCloseDown sitting there with the task handle (+4) you've asked for? Initially looks easy enough, the StrongHelp doesn't explain
where you would get the information for Message_TaskInitialise +20 +24
+28
Not saying it wouldn't be worth the effort,
it does sound like a job that a pre-existing library could do so you can
just run what you want without delving into wimp offsets.
The Zap complication hopefully will get fixed by Zap people.
On 14 Jun, Ronald wrote in message
<d5bc4f8058.beeb@-.->:
I guess checking for a file or system variable to be set with some sort of wimp poll so it's not grinding away in a loop. I've been experimenting
with pause%=INKEY 2000 any key press will stop the wait, useable to a degree.
If you don't want to do the Message_TW_* stuff, then Message_TaskInitialise and Message_TaskCloseDown, as I originally posted. That way, there's no polling and no ugly time delay stuff: you just get messages sent in when there's something new to test against.
The Zap complication hopefully will get fixed by Zap people.
Whilst a pre-existing library is a Very Good Idea, the code above is all
that you need (plus the usual to register interest in the two messages with Wimp_Initialise,
On 14 Jun 2020 as I do recall,
Steve Fryatt wrote:
[snip]
Whilst a pre-existing library is a Very Good Idea, the code above is all that you need (plus the usual to register interest in the two messages with Wimp_Initialise,
Note that you *will* need to do this, otherwise your task will mysteriously fail to receive the messages at all... ask me how I know ;-p
The FilerHRun module is not mentioned much these days but it may
have had this type of usage in mind.
It can run a binary directly from BASIC, but once again you have to
perform a wait. Haven't checked to see if SYS$RETURNCODE is possible.
On 15/06/2020 03:51, Ronald wrote:
The FilerHRun module is not mentioned much these days but it may
have had this type of usage in mind.
It can run a binary directly from BASIC, but once again you have to
perform a wait. Haven't checked to see if SYS$RETURNCODE is possible.
It wont be. Sys$Return code is only valid if you explicitly run a
program via OSCLI. Any sort of FilerRun, TaskObey or other Wimp
mechanism will usually return to you straight away, and queue the
program to be run when they get the next Wimp Poll. Only they will be
able to read Sys$Return code when the program exits and you can't rely
on this variable once Wimp Poll is called, as something else may have
exited.
---druck
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 65:22:23 |
Calls: | 6,488 |
Calls today: | 1 |
Files: | 12,096 |
Messages: | 5,274,922 |