Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.acorn.programmer > #604 > unrolled thread
| Started by | Gazza <usenet@garethlock.com> |
|---|---|
| First post | 2011-08-13 07:01 -0700 |
| Last post | 2011-08-13 18:00 +0100 |
| Articles | 16 — 5 participants |
Back to article view | Back to comp.sys.acorn.programmer
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
| From | Gazza <usenet@garethlock.com> |
|---|---|
| Date | 2011-08-13 07:01 -0700 |
| Subject | Can 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]
| From | Martin <News03@avisoft.f9.co.uk> |
|---|---|
| Date | 2011-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]
| From | Gazza <usenet@garethlock.com> |
|---|---|
| Date | 2011-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]
| From | Gazza <usenet@garethlock.com> |
|---|---|
| Date | 2011-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]
| From | Martin <News03@avisoft.f9.co.uk> |
|---|---|
| Date | 2011-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]
| From | Gazza <usenet@garethlock.com> |
|---|---|
| Date | 2011-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]
| From | Martin <News03@avisoft.f9.co.uk> |
|---|---|
| Date | 2011-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]
| From | Gazza <usenet@garethlock.com> |
|---|---|
| Date | 2011-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]
| From | Martin <News03@avisoft.f9.co.uk> |
|---|---|
| Date | 2011-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]
| From | Martin Bazley <martin.bazley@blueyonder.co.uk> |
|---|---|
| Date | 2011-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]
| From | Martin <News03@avisoft.f9.co.uk> |
|---|---|
| Date | 2011-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]
| From | "Barry Allen (news)" <evanallen@onetel.net.uk.invalid> |
|---|---|
| Date | 2011-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]
| From | Gazza <usenet@garethlock.com> |
|---|---|
| Date | 2011-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]
| From | Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> |
|---|---|
| Date | 2011-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]
| From | Gazza <usenet@garethlock.com> |
|---|---|
| Date | 2011-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]
| From | Martin Bazley <martin.bazley@blueyonder.co.uk> |
|---|---|
| Date | 2011-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