• Calling Ghostscript from BASIC

    From Harriet Bazley@21:1/5 to All on Mon Jun 8 15:39:04 2020
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rob Hemmings (News)@21:1/5 to Harriet Bazley on Mon Jun 8 15:44:43 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rob Hemmings (News)@21:1/5 to All on Mon Jun 8 15:22:18 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Fryatt@21:1/5 to Harriet Bazley on Mon Jun 8 16:19:57 2020
    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/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Wuerthner@21:1/5 to Steve Fryatt on Mon Jun 8 20:22:17 2020
    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 --------

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Harriet Bazley@21:1/5 to Martin Wuerthner on Mon Jun 8 21:15:33 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rob Hemmings (News)@21:1/5 to Martin Wuerthner on Mon Jun 8 23:37:21 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From druck@21:1/5 to Harriet Bazley on Tue Jun 9 10:58:55 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Harriet Bazley@21:1/5 to druck on Tue Jun 9 15:09:43 2020
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ronald@21:1/5 to Harriet Bazley on Sat Jun 13 13:01:42 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From druck@21:1/5 to Ronald on Sat Jun 13 12:03:55 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ronald@21:1/5 to druck on Sun Jun 14 01:29:38 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ronald@21:1/5 to rhnews@dsl.pipex.com on Sun Jun 14 16:38:33 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Fryatt@21:1/5 to Ronald on Sun Jun 14 07:40:36 2020
    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/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rob Hemmings (News)@21:1/5 to Steve Fryatt on Sun Jun 14 08:48:41 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Fryatt@21:1/5 to Ronald on Sun Jun 14 10:01:22 2020
    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/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ronald@21:1/5 to Steve Fryatt on Sun Jun 14 20:27:36 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Harriet Bazley@21:1/5 to Ronald on Sun Jun 14 15:44:38 2020
    On 14 Jun 2020 as I do recall,
    Ronald wrote:

    [snip]


    The Zap complication hopefully will get fixed by Zap people.



    I imagine that the Zap attitude is 'the task may *expect* to receive the
    handle of a child taskwindow from the registered taskwindow handler, but
    this is not actually specified by the relevant WIMP protocols, and provided
    the taskwindow is eventually created the handler can implement the actual creation however it likes'.

    Short version: 'tasks should not rely on undocumented behaviour' :-P

    --
    Harriet Bazley == Loyaulte me lie ==

    A man's best friend is his dogma.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Harriet Bazley@21:1/5 to Steve Fryatt on Sun Jun 14 15:41:49 2020
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ronald@21:1/5 to Harriet Bazley on Mon Jun 15 14:51:36 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From druck@21:1/5 to Ronald on Mon Jun 15 08:56:01 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ronald@21:1/5 to druck on Mon Jun 15 20:30:39 2020
    In message <rc79ih$h23$1@dont-email.me>
    druck <news@druck.org.uk> wrote:

    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

    OK, getting back to being better running the binary in an Obey
    for that kind of simplicity then.
    My Fetchmail program is in an obey file called by a Taskwindow.
    It is well suited for Sys$ReturnCode it can range from O to 16 or so.
    0 for mail received, 1 for no mail to retrieve, and higher numbers
    reflect various authorisation or network faults.
    Thanks
    Ronald

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)