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

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

Testing from a BASIC program the existence of a module

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

Contents

  Testing from a BASIC program the existence of a module xltardy@gmail.com - 2018-07-20 01:40 -0700
    Re: Testing from a BASIC program the existence of a module Vince M Hudd <atdotcodotuk@dotcodotukat.co.uk> - 2018-07-20 11:08 +0100
    Re: Testing from a BASIC program the existence of a module "John Williams (News)" <UCEbin@tiscali.co.uk> - 2018-07-20 17:48 +0100
      Re: Testing from a BASIC program the existence of a module Vince M Hudd <atdotcodotuk@dotcodotukat.co.uk> - 2018-07-20 18:58 +0100
        Re: Testing from a BASIC program the existence of a module "John Williams (News)" <UCEbin@tiscali.co.uk> - 2018-07-20 19:47 +0100
      Re: Testing from a BASIC program the existence of a module Steve Fryatt <news@stevefryatt.org.uk> - 2018-07-20 20:01 +0100
        Re: Testing from a BASIC program the existence of a module lydia.harston2@gmail.com - 2018-07-21 08:53 -0700
          Re: Testing from a BASIC program the existence of a module Vince M Hudd <atdotcodotuk@dotcodotukat.co.uk> - 2018-07-21 22:28 +0100
            Re: Testing from a BASIC program the existence of a module lydia.harston2@gmail.com - 2018-07-22 04:01 -0700

#5483 — Testing from a BASIC program the existence of a module

As the title says, how can I test, from BASIC, the existence of a module ?

I'd like a real test for existence please, not a call and handling an error returned if the module is not present. Thanks in advance.

[toc] | [next] | [standalone]

#5484

On 20/07/18 09:40, xltardy@gmail.com wrote:

> As the title says, how can I test, from BASIC, the existence of a module ?

> I'd like a real test for existence please, not a call and handling an error returned if the module is not present. Thanks in advance.

OS_Module 18 is probably the best you're going to get. According to the 
documentation on the ROOL site, it does return an error pointer if the 
module doesn't exist, but looks as though it should be simple to handle.

https://www.riscosopen.org/wiki/documentation/show/OS_Module%2018

This call was brought to my attention recently when I was discussing the 
possibility of adding a module check to WaitUntil. In the end, though, 
neither I nor the person I was discussing it with couldn't see any real 
purpose for the addition.

(I'm not even entirely sure why I had the idea in the back of my mind - 
possibly it was something requested an awfully long time ago!)

-- 
Vince M Hudd - Soft Rock Software   - www.softrock.co.uk
                RISCOSitory          - www.riscository.com

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

#5485

In article <2c617d2a-d8ae-45e3-b90b-4845c5eb243a@googlegroups.com>,
   Xavier Louis Tardy <xltardy@gmail.com> wrote:

> As the title says, how can I test, from BASIC, the existence of a module ?

> I'd like a real test for existence please, not a call and handling an
> error returned if the module is not present. Thanks in advance.

Normally one would use the OS command RMEnsure in a Run file to check for
the presence of a module and this allows a command to be executed if it's
not present.

Normally this would be a command to RMLoad the module.  But it could be
anything.  It could be to raise an error, but it could be something else

You obviously have some reason for doing this from within a BASIC program,
whether multi or single-tasking.

I think if I had this problem I would call an Obeyfile from within the
BASIC and get it to set a system variable depending on the result.

When this OSCLI command returned to BASIC I would interrogate the system
variable using a routine such as this:

  :
  DEF FN_readsysvariable(sysvar$)
  SYS"OS_ReadVarVal",sysvar$,block%,255,0,3 TO ,,val%
  block%?val%=13
  val$=$block%
  =val$
  :

Note that this requires a variable block% to have been dimensioned to size
255.

You then treat the returned string as a flag and do whatever you wish with
it.

This avoids the error scenario as you wish.

John

-- 
John Williams, now back in the UK - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!
Who is John Williams? http://petit.four.free.fr/picindex/author/

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

#5486

On 20/07/18 17:48, John Williams (News) wrote:
> In article <2c617d2a-d8ae-45e3-b90b-4845c5eb243a@googlegroups.com>,
>     Xavier Louis Tardy <xltardy@gmail.com> wrote:
> 
>> [Check for the existence of a module from BASIC]

[...]

> I think if I had this problem I would call an Obeyfile from within the
> BASIC and get it to set a system variable depending on the result.

[snip function to read a system variable]

As I said earlier, OS_Module 18. The docs I linked to said - and 
probably still do for that matter! - that if the module is there, R0 is 
preserved (18, the reason code), otherwise it contains an error pointer.

This is untested, and based purely on that, but if I read it right this 
should work:

DEF FN_CheckForModule(ModuleName$)
   LOCAL Result%
   SYS "XOS_Module",18,ModuleName$ TO Result%
   IF Result%=18 THEN =TRUE ELSE =FALSE

-- 
Vince M Hudd - Soft Rock Software   - www.softrock.co.uk
                RISCOSitory          - www.riscository.com

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

#5487

In article <IIqdnWTKe9w3v8_GnZ2dnUU7-XnNnZ2d@giganews.com>,
   Vince M Hudd <atdotcodotuk@dotcodotukat.co.uk> wrote:

> This is untested, and based purely on that, but if I read it right this 
> should work:

OK - I'm conVinced!

John

-- 
John Williams, now back in the UK - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!
Who is John Williams? http://petit.four.free.fr/picindex/author/

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

#5488

On 20 Jul, "John Williams (News)" wrote in message
    <571aa88b3dUCEbin@tiscali.co.uk>:

> I think if I had this problem I would call an Obeyfile from within the
> BASIC and get it to set a system variable depending on the result.
> 
> When this OSCLI command returned to BASIC I would interrogate the system
> variable using a routine such as this:

Why an Obey file? Why not just

  OSCLI("Set MyApp$MyModPresent 1")
  OSCLI("RMEnsure MyModule Set MyApp$MyModPresent 0")

Although, as Vince says, using OS_Module 18 looks to be a much better
solution.

-- 
Steve Fryatt - Leeds, England

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

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

#5489

Steve Fryatt  wrote:
> Why an Obey file? Why not just
>   OSCLI("Set MyApp$MyModPresent 1")
>   OSCLI("RMEnsure MyModule Set MyApp$MyModPresent 0")

Whenever I've had a need to check for the presence of a
module, it's always been the case that it's a fault if
it's not present, so the following has always been adequate:

*RMEnsure ModuleName 0.00 Error ModuleName not present

Otherwise,
SYS "XOS_Module",18,ModuleName$ TO ; Flags%
ModulePresent%=(Flags% AND 1)<>1

I'd prefer to test for the explicit case of an error being
returned, not for the case that R0<>18. I know it's as close
to impossible as makes no difference to have an error block
at address 18, but I would still prefer to test that an
*error* has been return, not for something that would also
be returned when an error is returned.

Unless the canonical Acorn documentation specifies something
else.

jgh

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

#5491

On 21/07/18 16:53, lydia.harston2@gmail.com wrote:

[snips]

> Otherwise,
> SYS "XOS_Module",18,ModuleName$ TO ; Flags%
> ModulePresent%=(Flags% AND 1)<>1

> I'd prefer to test for the explicit case of an error being
> returned, not for the case that R0<>18.

Yes - but Xavier said:

"I'd like a real test for existence please, not a call and handling an 
error returned if the module is not present."

Strictly speaking, doing it correctly as above or checking for R0<>18 is 
still "handling an error returned" but I read that as not wanting to 
check the flags for whatever reason.

-- 
Vince M Hudd - Soft Rock Software   - www.softrock.co.uk
                RISCOSitory          - www.riscository.com

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

#5492

Vince M Hudd wrote:
> Strictly speaking, doing it correctly as above or checking for R0<>18 is 
> still "handling an error returned" but I read that as not wanting to 
> check the flags for whatever reason.

Thinking a few thoughts, it is practically impossible for an
error block to be in the system zero page, and impossible for
it to be in the hardware vector space, and a lot of API calls
use <256 to test for non-address vs address, so I think I'd
be minded to use present=(R0<256), absent=(R0>255).

[toc] | [prev] | [standalone]

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

csiph-web