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


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

Can anyone spot why this menu doesn't change anything please.

Started byGazza <usenet@garethlock.com>
First post2011-08-13 07:01 -0700
Last post2011-08-13 18:00 +0100
Articles 16 — 5 participants

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


Contents

  Can anyone spot why this menu doesn't change anything please. Gazza <usenet@garethlock.com> - 2011-08-13 07:01 -0700
    Re: Can anyone spot why this menu doesn't change anything please. Martin <News03@avisoft.f9.co.uk> - 2011-08-13 16:18 +0100
      Re: Can anyone spot why this menu doesn't change anything please. Gazza <usenet@garethlock.com> - 2011-08-13 09:47 -0700
        Re: Can anyone spot why this menu doesn't change anything please. Gazza <usenet@garethlock.com> - 2011-08-13 11:41 -0700
          Re: Can anyone spot why this menu doesn't change anything please. Martin <News03@avisoft.f9.co.uk> - 2011-08-13 23:35 +0100
            Re: Can anyone spot why this menu doesn't change anything please. Gazza <usenet@garethlock.com> - 2011-08-13 15:45 -0700
              Re: Can anyone spot why this menu doesn't change anything please. Martin <News03@avisoft.f9.co.uk> - 2011-08-14 10:54 +0100
                Re: Can anyone spot why this menu doesn't change anything please. Gazza <usenet@garethlock.com> - 2011-08-14 04:27 -0700
                  Re: Can anyone spot why this menu doesn't change anything please. Martin <News03@avisoft.f9.co.uk> - 2011-08-14 12:43 +0100
                    Re: Can anyone spot why this menu doesn't change anything please. Martin Bazley <martin.bazley@blueyonder.co.uk> - 2011-08-14 14:18 +0100
                      Re: Can anyone spot why this menu doesn't change anything please. Martin <News03@avisoft.f9.co.uk> - 2011-08-14 15:24 +0100
                        Re: Can anyone spot why this menu doesn't change anything please. "Barry Allen (news)" <evanallen@onetel.net.uk.invalid> - 2011-08-14 15:48 +0100
                        Re: Can anyone spot why this menu doesn't change anything please. Gazza <usenet@garethlock.com> - 2011-08-14 08:46 -0700
                          Re: Can anyone spot why this menu doesn't change anything please. Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2011-08-14 18:36 +0100
                            Re: Can anyone spot why this menu doesn't change anything please. Gazza <usenet@garethlock.com> - 2011-08-21 02:50 -0700
    Re: Can anyone spot why this menu doesn't change anything please. Martin Bazley <martin.bazley@blueyonder.co.uk> - 2011-08-13 18:00 +0100

#604 — Can anyone spot why this menu doesn't change anything please.

FromGazza <usenet@garethlock.com>
Date2011-08-13 07:01 -0700
SubjectCan anyone spot why this menu doesn't change anything please.
Message-ID<f6e2409c-426d-4f95-acff-5120b244411b@e7g2000vbw.googlegroups.com>
I've been playing around with the following piece of BASIC for a while
now and just can't seem to get it to do what it's supposed to do...

   REPEAT
    CLS:PRINT:PRINT
    PROCrec_stats(rec_mod%,rec_add%,rec_ptr%,rec_sval%)
    PRINT:PRINT
    PRINT"       Options Menu"
    PRINT:PRINT
    PRINT"   (A)utosave feature.   Currently
"+FNdev_iifs(FNdev_tstbit(0,rec_opt%),"ON","OFF")
    PRINT"   (C)onfigure Autosave. Currently set at : "+STR$(asnum%)
    PRINT"   (S)tatistics display. Currently
"+FNdev_iifs(FNdev_tstbit(1,rec_opt%),"ON","OFF")
    PRINT:PRINT
    PRINT"        Enter Selection or (B)ack to main menu."
    PRINT:PRINT
    REPEAT:l$=GET$:UNTIL INSTR("AaCcSsBb",l$)<>0
    CASE l$ OF
     WHEN "A","a" : PROCdev_togglebit(0,rec_opt%)              :REM
Autosave feature On/Off.
     WHEN "C","c" : REM Set auto-save activation threshold.
      INPUT"   Enter autosave activation threshold. ENTER to go
back.";m$
      IF FNdev_validnum(m$) THEN rec_asnum%=FNdev_iif(m$<>"",VAL(m
$),rec_asnum%)
     WHEN "S","s" : PROCdev_togglebit(1,rec_opt%)              :REM
Statistics display On/Off.
     OTHERWISE    : REM Save changes to file and return to main menu.
      PROCfile_opts_io(FALSE,rec_opt%,junk%,rec_asnum%):done%=TRUE
    ENDCASE
   UNTIL done%


DEFPROCrec_stats()                                              :
Displays some statistics.
DEFPROCfile_opts_io(<read>,<opt>,<null>,<opt2>)  : Reads/Writes
options file. If <read> TRUE reads.
DEFFNdev_tstbit(<pos>,<mask>)                            : Returns
TRUE if bit at <pos>  in <mask> set.
DEFPROCdev_togglebit(<pos>,RETURN <mask>)    : Toggle bit at <pos>
position in bitmask <mask>
DEFFNdev_iif(<cond>,<true>,<false>)                      : C/C++
inline if (returns one of two ints)
DEFFNdev_iifs(<cond>,<true>,<false>)                    : C/C++ inline
if (returns one of two strings)
DEFFNdev_validnum(<num>)                                   : Check
validity.

The ENTER to go back works and saves the options to a file as it
should, as does the second option (C)onfigure, but the two that change
the options bitmask just don't do anything. I can provide the code for
dev_tstbit() and dev_togglebit() if it helps. However, I've already
used these simple generic two or three liners in a number of other
programs and they work as they should do.

It's probably something very simple, but I can't see it for the life
of me. This is only a snippet of the actual program, but I can provide
full listings of the !RunImage from which this extract was taken and
the libraries they use.

Thanks in advance.

[toc] | [next] | [standalone]


#607

FromMartin <News03@avisoft.f9.co.uk>
Date2011-08-13 16:18 +0100
Message-ID<52022bf40bNews03@avisoft.f9.co.uk>
In reply to#604
On 13 Aug, in article
<f6e2409c-426d-4f95-acff-5120b244411b@e7g2000vbw.googlegroups.com>,
   Gazza <usenet@garethlock.com> wrote:
> I've been playing around with the following piece of BASIC for a while
> now and just can't seem to get it to do what it's supposed to do...

[big snip]

Are you certain that you are entering PROCdev_togglebit correctly and
with the right parms? 

Are you certain PROCdev_togglebit doing what it should, and returning the
correct mask?

If *I* had that problem, I would use Reporter to see exactly what is
going on.  I would not mess around trying to work out what a program
should be doing, you need to see what it *is* doing. Then you can correct
it.

<plug>
See http://www.avisoft.f9.co.uk/ for details and download of Reporter.
</plug>

Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

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


#609

FromGazza <usenet@garethlock.com>
Date2011-08-13 09:47 -0700
Message-ID<b2230d7b-032b-4702-a3d4-83b43f648b42@c19g2000yqe.googlegroups.com>
In reply to#607
On Aug 13, 4:18 pm, Martin <New...@avisoft.f9.co.uk> wrote:
> On 13 Aug, in article
> <f6e2409c-426d-4f95-acff-5120b2444...@e7g2000vbw.googlegroups.com>,
>    Gazza <use...@garethlock.com> wrote:
>
> Are you certain PROCdev_togglebit doing what it should, and returning the
> correct mask?

The only thing I can think of there would be that dev_togglebit()
isn't RETURNing <mask> as it should. But this is just a wrapper around
three other routines...

DEFPROCdev_togglebit(pos%,RETURN mask%)
 IF FNdev_tstbit(pos%,mask%) THEN PROCdev_clrbit(pos%,mask%) ELSE
PROCdev_setbit(pos%,mask%)
ENDPROC

DEFPROCdev_clrbit(pos%,RETURN mask%)
... <clear bit at pos% in bitmask mask%>
ENDPROC

DEFPROCdev_setbit(pos%,RETURN mask%)
... <set bit at pos% in bitmask mask>
ENDPROC

The other thought is that BASIC gets itself tied up in knots when
passing RETURNed variables up and down levels like this. Caller uses
mask% with mask% RETURNed by the routine that's called. So the source
variable and the destination variable are the same.

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


#610

FromGazza <usenet@garethlock.com>
Date2011-08-13 11:41 -0700
Message-ID<c8d4a0be-0a64-4a30-b83b-772fc0f489a6@z7g2000vbp.googlegroups.com>
In reply to#609
Anyhow, I've had another look and still can't find the culprit.
However, I've just ZIPped up the three files involved and they can be
downloaded from http://www.garethlock.com/acorn/umoria/mkobj.zip

Yeah... The clue's in the path there. My current project is a complete
re-write of UMoria in BBC BASIC. I think I've got most of the code
understood, this was just a side project to make entering the database
just a little less of a troll...

I'd like to get it to work because I've still got at least half the
database to enter.

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


#611

FromMartin <News03@avisoft.f9.co.uk>
Date2011-08-13 23:35 +0100
Message-ID<520253e51cNews03@avisoft.f9.co.uk>
In reply to#610
On 13 Aug, in article
<c8d4a0be-0a64-4a30-b83b-772fc0f489a6@z7g2000vbp.googlegroups.com>,
   Gazza <usenet@garethlock.com> wrote:
> Anyhow, I've had another look and still can't find the culprit.
> However, I've just ZIPped up the three files involved and they can be
> downloaded from http://www.garethlock.com/acorn/umoria/mkobj.zip

Sorry, but I have not got time to debug my programs, never mind other
peoples!

Have you tried my suggestion of using Reporter to tell you what is going
on?

Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

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


#612

FromGazza <usenet@garethlock.com>
Date2011-08-13 15:45 -0700
Message-ID<b23406a1-d5de-42a9-8904-ae0fcdc5b8ab@s7g2000yqk.googlegroups.com>
In reply to#611
On Aug 13, 11:35 pm, Martin <New...@avisoft.f9.co.uk> wrote:
> On 13 Aug, in article
> <c8d4a0be-0a64-4a30-b83b-772fc0f48...@z7g2000vbp.googlegroups.com>,
>    Gazza <use...@garethlock.com> wrote:
>
> > Anyhow, I've had another look and still can't find the culprit.
> > However, I've just ZIPped up the three files involved and they can be
> > downloaded fromhttp://www.garethlock.com/acorn/umoria/mkobj.zip
>
> Sorry, but I have not got time to debug my programs, never mind other
> peoples!
>
> Have you tried my suggestion of using Reporter to tell you what is going
> on?
>
> Martin
>
> --
> Martin Avison
> Note that unfortunately this email address will become invalid
> without notice if (when) any spam is received.

Will take a look in the morning. I'm about beat for tonight.

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


#613

FromMartin <News03@avisoft.f9.co.uk>
Date2011-08-14 10:54 +0100
Message-ID<5202921b82News03@avisoft.f9.co.uk>
In reply to#612
If you change the code in Glue to add just three debugging statements ...

 REM Toggle a bit in a given bitmask.
 DEFPROCdev_togglebit(pos%,RETURN mask%)
   *Report "Toggle" ~mask% pos%
   IF FNdev_tstbit(pos%,mask%) THEN
     mask%=mask% OR (0<<pos%)
     *Report "True " ~mask%
   ELSE
     mask%=mask% OR (1<<pos%)
     *Report "False" ~mask%
   ENDIF
 ENDPROC

you will immediately see that all is not well, as mask% never changes.

A moments contemplation and you will realise 'mask% OR (0<<pos%)' does
NOT set a bit off!

An exellent example of why you need to see what IS happening, rather than
what you expect to happen.

<plug type=shameless>

Use Reporter!

Tip: If you run your single-tasking program in a Task Window, you can see
the Reporter information as it happens. And the source.

</plug>

Yes, you can also just use PRINT ~mask%, but it can mess up your output,
and is not so easy to identify to remove after debugging.

Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

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


#614

FromGazza <usenet@garethlock.com>
Date2011-08-14 04:27 -0700
Message-ID<5cfafa70-0593-461f-a7e5-0acda11e9a84@s7g2000yqk.googlegroups.com>
In reply to#613
On Aug 14, 10:54 am, Martin <New...@avisoft.f9.co.uk> wrote:
> If you change the code in Glue to add just three debugging statements ...
>
>  REM Toggle a bit in a given bitmask.
>  DEFPROCdev_togglebit(pos%,RETURN mask%)
>    *Report "Toggle" ~mask% pos%
>    IF FNdev_tstbit(pos%,mask%) THEN
>      mask%=mask% OR (0<<pos%)
>      *Report "True " ~mask%
>    ELSE
>      mask%=mask% OR (1<<pos%)
>      *Report "False" ~mask%
>    ENDIF
>  ENDPROC
>
> you will immediately see that all is not well, as mask% never changes.
>
> A moments contemplation and you will realise 'mask% OR (0<<pos%)' does
> NOT set a bit off!
>
> An exellent example of why you need to see what IS happening, rather than
> what you expect to happen.
>
> <plug type=shameless>
>
> Use Reporter!
>
> Tip: If you run your single-tasking program in a Task Window, you can see
> the Reporter information as it happens. And the source.
>
> </plug>
>
> Yes, you can also just use PRINT ~mask%, but it can mess up your output,
> and is not so easy to identify to remove after debugging.
>
> Martin
>
> --
> Martin Avison
> Note that unfortunately this email address will become invalid
> without notice if (when) any spam is received.

Thanks...
I guess that's a case of me not fully checking stuff I get off
Newsgroups then... I asked about this a wjhile ago, and got a
response. I did some testing of course, but seems like I stopped short
of testing dev_clrbit() which was pulled in from another library with
this full set of routines in. All I did when I created dev_togglebit()
later than the set & clear routines was to copy the set & clear code.
That might explain some strange behaviour in another project I
finished with a while ago.

Now I guess I'll have to find a bit of code that DOES clear the bit at
<pos> in bitmask <mask> lol...

Thanks again.

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


#616

FromMartin <News03@avisoft.f9.co.uk>
Date2011-08-14 12:43 +0100
Message-ID<52029c18aaNews03@avisoft.f9.co.uk>
In reply to#614
On 14 Aug, in article
<5cfafa70-0593-461f-a7e5-0acda11e9a84@s7g2000yqk.googlegroups.com>,
   Gazza <usenet@garethlock.com> wrote:
> That might explain some strange behaviour in another project I
> finished with a while ago.

Low level code MUST be tested, for just these reasons.

> Now I guess I'll have to find a bit of code that DOES clear the bit at
> <pos> in bitmask <mask> lol...

You could try...
    mask% = mask% AND NOT (1<<pos%)

but *you* MUST test it!

Remember that code always does what you ask! The difficult bit is seeing
where YOU have asked it to do the wrong thing. That is why you need a
strict debugging and testing routine. NEVER assume that code works as you
want! Most of the programming queries you have posted fall into this
category. I say again, try Reporter - it is why it was written in the
first place!!

And that is all bitter experience after a mere 42 years of trying to get
computers to do what I want!

Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

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


#619

FromMartin Bazley <martin.bazley@blueyonder.co.uk>
Date2011-08-14 14:18 +0100
Message-ID<1fc4a40252.martin@blueyonder.co.uk>
In reply to#616
The following bytes were arranged on 14 Aug 2011 by Martin :

> On 14 Aug, in article
> <5cfafa70-0593-461f-a7e5-0acda11e9a84@s7g2000yqk.googlegroups.com>,
>    Gazza <usenet@garethlock.com> wrote:
> > Now I guess I'll have to find a bit of code that DOES clear the bit at
> > <pos> in bitmask <mask> lol...
>
> You could try...
>     mask% = mask% AND NOT (1<<pos%)

Oh, dear, oh, dear, I did rather suspect this from your unusually
excessive use of entire procedures to perform trivial tasks like those
above, and from vague memory of your other queries.

I'm not going to explain the entire set of principles behind Boolean
algebra to you - look it up yourself for a change, you won't get
anywhere in programming if you have no idea how it works - but another
change you should have made is replacing PROCdev_togglebit with this:

mask% = mask% EOR (1<<pos%)

-- 
  __<^>__   === RISC OS is a work of art.  Some people adore it,  ===
 / _   _ \  === others can't see the point of it, and it's really ===
( ( |_| ) ) === expensive.                                        ===
 \_>   <_/  ======================= Martin Bazley ===================

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


#622

FromMartin <News03@avisoft.f9.co.uk>
Date2011-08-14 15:24 +0100
Message-ID<5202aac778News03@avisoft.f9.co.uk>
In reply to#619
On 14 Aug, in article <1fc4a40252.martin@blueyonder.co.uk>,
   Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
> The following bytes were arranged on 14 Aug 2011 by Martin :

> > On 14 Aug, in article
> > <5cfafa70-0593-461f-a7e5-0acda11e9a84@s7g2000yqk.googlegroups.com>,
> >    Gazza <usenet@garethlock.com> wrote:
> > > Now I guess I'll have to find a bit of code that DOES clear the bit
> > > at <pos> in bitmask <mask> lol...
> >
> > You could try...
> >     mask% = mask% AND NOT (1<<pos%)

> Oh, dear, oh, dear, I did rather suspect this from your ...

Can I assume this is referring to Gazza? 

> ...unusually excessive use of entire procedures to perform trivial tasks
> like those above, and from vague memory of your other queries.

> I'm not going to explain the entire set of principles behind Boolean
> algebra to you - look it up yourself for a change, you won't get
> anywhere in programming if you have no idea how it works - but another
> change you should have made is replacing PROCdev_togglebit with this:

> mask% = mask% EOR (1<<pos%)

Yup. That is indeed much simpler and neater. I was just trying to show
the statement that was wrong, not optimise the code!

Martin A

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

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


#624

From"Barry Allen (news)" <evanallen@onetel.net.uk.invalid>
Date2011-08-14 15:48 +0100
Message-ID<5202acfa2cevanallen@onetel.net.uk.invalid>
In reply to#622
In article <5202aac778News03@avisoft.f9.co.uk>, Martin
<News03@avisoft.f9.co.uk> wrote:
> On 14 Aug, in article <1fc4a40252.martin@blueyonder.co.uk>, Martin
>    Bazley <martin.bazley@blueyonder.co.uk> wrote:
> > The following bytes were arranged on 14 Aug 2011 by Martin :

> > > On 14 Aug, in article
> > > <5cfafa70-0593-461f-a7e5-0acda11e9a84@s7g2000yqk.googlegroups.com>,
> > >    Gazza <usenet@garethlock.com> wrote:
> > > > Now I guess I'll have to find a bit of code that DOES clear the
> > > > bit at <pos> in bitmask <mask> lol...
> > >
> > > You could try... mask% = mask% AND NOT (1<<pos%)

> > Oh, dear, oh, dear, I did rather suspect this from your ...

> Can I assume this is referring to Gazza? 

He is rather undiplomatic and charmless isn't he.

-- 
Barry A.
To reply by email:- barry d o t allen a t talktalk d o t net
Replace the d o t and a t by the usual.

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


#627

FromGazza <usenet@garethlock.com>
Date2011-08-14 08:46 -0700
Message-ID<03d56980-eb37-4d78-b57b-a738f2ca075d@v3g2000vbx.googlegroups.com>
In reply to#622
Haven't tried the EOR method yet, but the AND NOT method works...

Like I said before, I obtained this code from csap a while ago. I
guess this is one of the few occasions where I took it as red that it
would work. Teach me eh!! Thanks again.

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


#630

FromAlan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk>
Date2011-08-14 18:36 +0100
Message-ID<gemini.lpxi9100k5k1a01to.spamhater@keepyourfilthyspamtoyourself.co.uk>
In reply to#627
Gazza <usenet@garethlock.com> wrote:

> I guess this is one of the few occasions where I took it as red

You were obviously being a bit green.

-- 
RISC OS - you know it makes cents

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


#643

FromGazza <usenet@garethlock.com>
Date2011-08-21 02:50 -0700
Message-ID<6e3f3ce6-58cc-4567-b6a4-33d85a6412e3@w11g2000vbp.googlegroups.com>
In reply to#630
Data entry program complete and all dungeon object data entered... I
will be ZIPping listings and posting updates to this whole UMoria
conversion in time, for now, I need to clone and modify that little
data entry program to handle the monsters in the same way.

Thanks for all the help.

Any updates can be found at http://www.garethlock.com/acorn/umoria

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


#608

FromMartin Bazley <martin.bazley@blueyonder.co.uk>
Date2011-08-13 18:00 +0100
Message-ID<3f49350252.martin@blueyonder.co.uk>
In reply to#604
The following bytes were arranged on 13 Aug 2011 by Gazza :

>    REPEAT
>     CLS:PRINT:PRINT
>     PROCrec_stats(rec_mod%,rec_add%,rec_ptr%,rec_sval%)
>     PRINT:PRINT
>     PRINT"       Options Menu"
>     PRINT:PRINT
>     PRINT"   (A)utosave feature.   Currently
> "+FNdev_iifs(FNdev_tstbit(0,rec_opt%),"ON","OFF")
>     PRINT"   (C)onfigure Autosave. Currently set at : "+STR$(asnum%)
>     PRINT"   (S)tatistics display. Currently
> "+FNdev_iifs(FNdev_tstbit(1,rec_opt%),"ON","OFF")
>     PRINT:PRINT
>     PRINT"        Enter Selection or (B)ack to main menu."
>     PRINT:PRINT
>     REPEAT:l$=GET$:UNTIL INSTR("AaCcSsBb",l$)<>0
>     CASE l$ OF
>      WHEN "A","a" : PROCdev_togglebit(0,rec_opt%)              :REM
> Autosave feature On/Off.
>      WHEN "C","c" : REM Set auto-save activation threshold.
>       INPUT"   Enter autosave activation threshold. ENTER to go
> back.";m$
>       IF FNdev_validnum(m$) THEN rec_asnum%=FNdev_iif(m$<>"",VAL(m
> $),rec_asnum%)
>      WHEN "S","s" : PROCdev_togglebit(1,rec_opt%)              :REM
> Statistics display On/Off.
>      OTHERWISE    : REM Save changes to file and return to main menu.
>       PROCfile_opts_io(FALSE,rec_opt%,junk%,rec_asnum%):done%=TRUE
>     ENDCASE
>    UNTIL done%
>
>
> DEFPROCrec_stats()                                              :
> Displays some statistics.
> DEFPROCfile_opts_io(<read>,<opt>,<null>,<opt2>)  : Reads/Writes
> options file. If <read> TRUE reads.
> DEFFNdev_tstbit(<pos>,<mask>)                            : Returns
> TRUE if bit at <pos>  in <mask> set.
> DEFPROCdev_togglebit(<pos>,RETURN <mask>)    : Toggle bit at <pos>
> position in bitmask <mask>
> DEFFNdev_iif(<cond>,<true>,<false>)                      : C/C++
> inline if (returns one of two ints)
> DEFFNdev_iifs(<cond>,<true>,<false>)                    : C/C++ inline
> if (returns one of two strings)
> DEFFNdev_validnum(<num>)                                   : Check
> validity.

Your less than verbose program listing didn't help, but considering that
problems only arise when PROCdev_togglebit is involved, I'd be very
inclined to suspect that.

The other possible culprits are FNdev_tstbit and FNdev_iifs.  Have you
actually checked the saved configuration?  It may well be that rec_opt%
is changing as scheduled, but your TRUE/FALSE display mechanism is
malfunctioning, so it seems to be incorrect when it isn't.

Personally, I don't see any real reason for FNdev_tstbit or
PROCdev_togglebit to exist at all, since the tasks they perform are so
trivial.  FNdev_iif[s] is borderline - I think I'd probably just use
inline IFs.  I don't know if it would work, but I'd probably write
tighter code, like this:

REPEAT
  CLS:PRINT'
  PROCrec_stats(rec_mod%,rec_add%,rec_ptr%,rec_sval%)
  PRINT''"       Options Menu"''
  PRINT"   (A)utosave feature.   Currently ";
  PRINT FNdev_iifs((rec_opt% AND 1)<>0,"ON","OFF")
  PRINT"   (C)onfigure Autosave. Currently set at : "+STR$(asnum%)
  PRINT"   (S)tatistics display. Currently ";
  PRINT FNdev_iifs((rec_opt% AND 2)<>0,"ON","OFF")
  PRINT''"        Enter Selection or (B)ack to main menu."''
  REPEAT:l$=GET$:UNTIL INSTR("AaCcSsBb",l$)<>0
  CASE l$ OF
    WHEN "A","a":rec_opt%=(rec_opt% EOR 1)
    WHEN "C","c":
      INPUT"   Enter autosave activation threshold. ENTER to go back.";m$
      IF FNdev_validnum(m$) rec_asnum%=FNdev_iif(m$<>"",VAL(m$),rec_asnum%)
    WHEN "S","s":rec_opt%=(rec_opt% EOR 2)
  OTHERWISE
    PROCfile_opts_io(FALSE,rec_opt%,junk%,rec_asnum%):done%=TRUE
  ENDCASE
UNTIL done%
...
DEF PROCrec_stats()...ENDPROC
DEF PROCfile_opts_io()...ENDPROC
DEF FNdev_validnum()...=...
DEF FNdev_iif(bool%,trueval%,falseval%)
IF bool% =trueval% ELSE =falseval%
DEF FNdev_iifs(bool%,trueval$,falseval$)
IF bool% =trueval$ ELSE =falseval$

In grandest Usenet tradition, all entirely untested.

-- 
  __<^>__
 / _   _ \         You always find something in the last place you look.
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

[toc] | [prev] | [standalone]


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


csiph-web