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

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

Calling Ghostscript from BASIC

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

Contents

  Calling Ghostscript from BASIC "Rob Hemmings (News)" <rhnews@dsl.pipex.com> - 2020-06-08 15:22 +0100
    Re: Calling Ghostscript from BASIC Harriet Bazley <harriet@bazleyfamily.co.uk> - 2020-06-08 15:39 +0100
      Re: Calling Ghostscript from BASIC "Rob Hemmings (News)" <rhnews@dsl.pipex.com> - 2020-06-08 15:44 +0100
      Re: Calling Ghostscript from BASIC Steve Fryatt <news@stevefryatt.org.uk> - 2020-06-08 16:19 +0100
        Re: Calling Ghostscript from BASIC Martin Wuerthner <spamtrap@mw-software.com> - 2020-06-08 20:22 +0200
          Re: Calling Ghostscript from BASIC Harriet Bazley <harriet@bazleyfamily.co.uk> - 2020-06-08 21:15 +0100
            Re: Calling Ghostscript from BASIC druck <news@druck.org.uk> - 2020-06-09 10:58 +0100
              Re: Calling Ghostscript from BASIC Harriet Bazley <harriet@bazleyfamily.co.uk> - 2020-06-09 15:09 +0100
                Re: Calling Ghostscript from BASIC Ronald <gettingchoppy@gmail.com> - 2020-06-13 13:01 +1200
                  Re: Calling Ghostscript from BASIC druck <news@druck.org.uk> - 2020-06-13 12:03 +0100
                    Re: Calling Ghostscript from BASIC Ronald <gettingchoppy@gmail.com> - 2020-06-14 01:29 +1200
          Re: Calling Ghostscript from BASIC "Rob Hemmings (News)" <rhnews@dsl.pipex.com> - 2020-06-08 23:37 +0100
    Re: Calling Ghostscript from BASIC Ronald <gettingchoppy@gmail.com> - 2020-06-14 16:38 +1200
      Re: Calling Ghostscript from BASIC Steve Fryatt <news@stevefryatt.org.uk> - 2020-06-14 07:40 +0100
        Re: Calling Ghostscript from BASIC "Rob Hemmings (News)" <rhnews@dsl.pipex.com> - 2020-06-14 08:48 +0100
        Re: Calling Ghostscript from BASIC Ronald <gettingchoppy@gmail.com> - 2020-06-14 20:27 +1200
          Re: Calling Ghostscript from BASIC Steve Fryatt <news@stevefryatt.org.uk> - 2020-06-14 10:01 +0100
            Re: Calling Ghostscript from BASIC Harriet Bazley <harriet@bazleyfamily.co.uk> - 2020-06-14 15:41 +0100
              Re: Calling Ghostscript from BASIC Ronald <gettingchoppy@gmail.com> - 2020-06-15 14:51 +1200
                Re: Calling Ghostscript from BASIC druck <news@druck.org.uk> - 2020-06-15 08:56 +0100
                  Re: Calling Ghostscript from BASIC Ronald <gettingchoppy@gmail.com> - 2020-06-15 20:30 +1200
          Re: Calling Ghostscript from BASIC Harriet Bazley <harriet@bazleyfamily.co.uk> - 2020-06-14 15:44 +0100

Page 1 of 2  [1] 2  Next page →

#6138 — Calling Ghostscript from BASIC

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?

-- 
------------------------------------------------------------- 
 Rob Hemmings                        Southport       
 
 rhnews@dsl.pipex.com                  

[toc] | [next] | [standalone]

#6139

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.

-- 
Harriet Bazley                     ==  Loyaulte me lie ==

The attacker must vanquish; the defender need only survive.

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

#6140

In article <20b36f7d58.harriet@bazleyfamily.co.uk>,
   Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:
> 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.

Thanks Harriet, that is very helpful.

-- 
------------------------------------------------------------- 
 Rob Hemmings                        Southport       
 
 rhnews@dsl.pipex.com                  

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

#6141

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 problem with taking the handle from Wimp_StartTask is that if the 
registered TaskWindow provider is Zap, and Zap isn't running, 
Wimp_StartTask returns the handle of another task, whose purpose seems to 
be to get Zap up and running. This task starts the task that you're 
after, and then exits immediately.

If you're listening for Message_TaskCloseDown, so that you can clean up 
after the process, and match on the task handle from Wimp_StartTask, you 
do the clean up just as your task is getting going. PrintPDF deletes the 
intermediate PostScript file from the queue, and until I changed to the 
more long-winded approach, it deleted the file just as GhostScript was 
starting to read it if Zap wasn't loaded at the time.

-- 
Steve Fryatt - Leeds, England

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

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

#6142

Steve Fryatt <news@stevefryatt.org.uk> wrote:

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

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.

-- 
Martin Wuerthner         MW Software      http://www.mw-software.com/

------- RISC OS Software for Design, Printing and Publishing --------

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

#6143

On 8 Jun 2020 as I do recall,
          Martin Wuerthner  wrote:

[snip]


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

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

The zip utilities, for instance, not only display progress messages but
sometimes prompt for input, and implementing an entire scrolling
input/output display is the sort of reinvention of the wheel that using
a taskwindow to handle command-line utilities was supposed to avoid.


-- 
Harriet Bazley                     ==  Loyaulte me lie ==

Old Programmers never die. They just terminate and stay resident

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

#6145

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.

---druck

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

#6146

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.


-- 
Harriet Bazley                     ==  Loyaulte me lie ==

It is better to be deceived by a friend, than to suspect him.

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

#6150

In message <54d9f07d58.harriet@bazleyfamily.co.uk>
          Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

> 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.
Don't know how well this would work or if it would help Harriets case.

Ronald

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

#6151

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

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

#6152

In message <rc2bqu$8mt$1@dont-email.me>
          druck <news@druck.org.uk> wrote:

> 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

So it does, looking forward to using it.
Important failures can be acted upon loudly now.

Ronald
 

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

#6144

In article <mpro.qbmdp5006xksu081o.spamtrap@mw-software.com>,
   Martin Wuerthner <spamtrap@mw-software.com> wrote:
> Steve Fryatt <news@stevefryatt.org.uk> wrote:

> > On 2020-06-08, Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:
> > 

[Snip]

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

Thanks very much indeed to both Steve and Martin for the very thorough
and helpful explanations.  Really useful although I'm going to have to do
some more reading of my Programmer's Reference Manuals!

-- 
------------------------------------------------------------- 
 Rob Hemmings                        Southport       
 
 rhnews@dsl.pipex.com                  

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

#6153

In message <587d6e2a47rhnews@dsl.pipex.com>
          "Rob Hemmings (News)" <rhnews@dsl.pipex.com> 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?
>
 
Without going into the heavy Taskwindow stuff, one way is to filer_run
an obey file containing whatever, could even be a Taskwindow command 
running yet another obey file with desired actions for within the
taskwindow.

The main consideration is that the BASIC file will continue to
the end unless you put have a wait routine straight after.

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

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

#6154

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.

-- 
Steve Fryatt - Leeds, England

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

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

#6155

In article <mpro.qbwl7i0191pbo01u8.news@stevefryatt.org.uk>,
   Steve Fryatt <news@stevefryatt.org.uk> wrote:
> 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 TaskWindow and messaging approach was fairly easy to set up once
Martin had explained it and does work very well.  

I just wish I could resolve the issue I have with GhostScript as easily!

-- 
------------------------------------------------------------- 
 Rob Hemmings                        Southport       
 
 rhnews@dsl.pipex.com                  

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

#6156

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

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

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.

Ronald

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

#6157

On 14 Jun, Ronald wrote in message
    <1cb5648058.beeb@-.->:

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

Nowhere.

My suggestion is that your task does nothing, thereby allowing the
processing task to do as much work as possible, until the processing task
ends. The Wimp will then send it a message to let it know.

> 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

You start your task:

  TaskName$ = "MyTaskName"
  TaskHandle% = 0
  command$ = "TaskWindow MyTask 256k -name """ + TaskName$ + """ -quit"
  SYS "XWimp_StartTask", command$ TO handle%
  IF handle% = 0 THEN PRINT "Failed to start"

and then return control to Wimp_Poll(Idle)

Your Message_TaskInitialise handler:

  PROCmessage_task_initialise(message%)
  LOCAL name$

  SYS "XOS_GenerateError", message% + 28 TO name$
  IF name$ = TaskName$ THEN TaskHandle% = message%!4
  ENDPROC

Your Message_TaskCloseDown handler:

  PROCmessage_task_close_down(message%)
  IF TaskHandle% <> 0 AND message%!4 = TaskHandle% THEN
    TaskHandle% = 0
    PROCdo_something_useful_when_task_exits
  ENDIF
  ENDPROC

> Not saying it wouldn't be worth the effort,

The code is above; less than 20 lines. Untested, as I work mainly in C these
days, but it's a translation into BASIC from what PrintPDF does.

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

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, and the usual to identify the incoming messages and call
the handler procedures).

> The Zap complication hopefully will get fixed by Zap people.

Who be they, then? :-)

-- 
Steve Fryatt - Leeds, England

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

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

#6161

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

-- 
Harriet Bazley                     ==  Loyaulte me lie ==

Confession is good for the soul, but bad for the career.

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

#6163

In message <ecf7868058.harriet@bazleyfamily.co.uk>
          Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

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

Two places I can think of that you might run binaries from BASIC would
be AppBasic and Confix is predisposed for BASIC scripts.
Actually AppBasic seemed to call a binary OK.
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.

I'm putting PDF's on my chromebook, quite a fast startup,
not a bad pdf viewer, can do it in bed! (Winter here)
I think the PRM's need a separate index built so you can get to
where you want quicker. For one thing the pdf page numbers differ.

Ronald

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

#6164

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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web