Loading ...
Sorry, an error occurred while loading the content.

Re: [libertybasic] use of "on .... goto" in older version of Basic

Expand Messages
  • Brad and Anna Moore
    That is a form of error checking. LB does not have universal error trapping. You will have to be proactive in insuring an error condition does not exist
    Message 1 of 7 , Mar 29 1:38 PM
    • 0 Attachment
      That is a form of error checking. LB does not have universal error
      trapping. You will have to be proactive in insuring an error condition does
      not exist BEFORE you make the call that might cause an error. Typically
      these are file open, read and write operations. It is possible to make LB
      quite bullet proof in these areas by insuring that your file is there before
      you open it. Use the FILE command to check for a file. The other tool is
      the EOF function that will detect the end of file if you are reading
      serially before over reading past the end of the file. Check both of these
      commands out in the LB help system. Also one of the tutorials in the help
      system (I think number 3 or 4) deals with file I/O.

      Good luck.

      BRad

      ----- Original Message -----
      From: "fencer22002" <fencer22002@...>
      To: <libertybasic@yahoogroups.com>
      Sent: Saturday, March 29, 2003 8:02 PM
      Subject: [libertybasic] use of "on .... goto" in older version of Basic


      > I am trying to implement code that was written in an old version of
      > Basic. It uses an on...goto statement. Of course "on" is not
      > recognized by liberty basic. It seems that "If" could be
      > substituted for "on".
      >
      > Is this a correct assumption?
      >
      > Is there some other meaning attached to "on" that I may be missing?
      >
      >
      >
      > To unsubscribe from this group, send an email to:
      > libertybasic-unsubscribe@egroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
      >
    • fencer22002
      I am trying to implement code that was written in an old version of Basic. It uses an on...goto statement. Of course on is not recognized by liberty
      Message 2 of 7 , Mar 29 3:32 PM
      • 0 Attachment
        I am trying to implement code that was written in an old version of
        Basic. It uses an on...goto statement. Of course "on" is not
        recognized by liberty basic. It seems that "If" could be
        substituted for "on".

        Is this a correct assumption?

        Is there some other meaning attached to "on" that I may be missing?
      • carlgundel
        Actually there is also a form that works like a case statement, but only for numeric values. You would say: on varName goto 200, 300, 400, 500 If varName is
        Message 3 of 7 , Mar 29 6:07 PM
        • 0 Attachment
          Actually there is also a form that works like a case statement, but
          only for numeric values. You would say:

          on varName goto 200, 300, 400, 500

          If varName is 1, it would goto 200, if 2 it would goto 300, etc.

          The closest thing you have now is SELECT CASE.

          Here's a clip from the help file:

          num = 3

          select case num
          case 1
          print "one"
          case 2
          print "two"
          case 3
          print "three"
          case else
          print "other number"
          end select

          -Carl

          --- In libertybasic@yahoogroups.com, "Brad and Anna Moore"
          <bjaz.moore@v...> wrote:
          > That is a form of error checking. LB does not have universal error
          > trapping. You will have to be proactive in insuring an error
          condition does
          > not exist BEFORE you make the call that might cause an error.
          Typically
          > these are file open, read and write operations. It is possible to
          make LB
          > quite bullet proof in these areas by insuring that your file is
          there before
          > you open it. Use the FILE command to check for a file. The other
          tool is
          > the EOF function that will detect the end of file if you are
          reading
          > serially before over reading past the end of the file. Check both
          of these
          > commands out in the LB help system. Also one of the tutorials in
          the help
          > system (I think number 3 or 4) deals with file I/O.
          >
          > Good luck.
          >
          > BRad
          >
          > ----- Original Message -----
          > From: "fencer22002" <fencer22002@y...>
          > To: <libertybasic@yahoogroups.com>
          > Sent: Saturday, March 29, 2003 8:02 PM
          > Subject: [libertybasic] use of "on .... goto" in older version of
          Basic
          >
          >
          > > I am trying to implement code that was written in an old version
          of
          > > Basic. It uses an on...goto statement. Of course "on" is not
          > > recognized by liberty basic. It seems that "If" could be
          > > substituted for "on".
          > >
          > > Is this a correct assumption?
          > >
          > > Is there some other meaning attached to "on" that I may be
          missing?
          > >
          > >
          > >
          > > To unsubscribe from this group, send an email to:
          > > libertybasic-unsubscribe@egroups.com
          > >
          > >
          > >
          > > Your use of Yahoo! Groups is subject to
          http://docs.yahoo.com/info/terms/
          > >
          > >
          > >
        • Foon
          ... Well, yeah, you CAN use it like that. But as has been pointed out, this code structure (on... goto...) was designed for handling errors which have been
          Message 4 of 7 , Mar 30 10:30 AM
          • 0 Attachment
            > Actually there is also a form that works like a case statement, but
            > only for numeric values. You would say:
            >
            > on varName goto 200, 300, 400, 500
            >
            > If varName is 1, it would goto 200, if 2 it would goto 300, etc.
            >
            > The closest thing you have now is SELECT CASE.
            >
            > Here's a clip from the help file:

            Well, yeah, you CAN use it like that. But as has been pointed out, this code structure (on... goto...) was designed for handling errors which have been TRAPped, which is quite different from exception handling (if you happen to have run across that term). The point of that syntax is to be able to branch based on a 1,2,3,etc error "return code" from a process (either internal to the pgm or external (hard or soft)).

            Many of us, and it would be ALL of us if we ALL knew the value of it, are hoping and praying that Carl will implement error trapping in LB. As odd as it may sound, it's MUCH easier to handle an error, and correct it, AFTER it occurs rather than trying to anticipate and head off all possible errors BEFORE they can occur. The opposite is true, of course, for issues like input validation, but that a whole 'nother thing. ;)

            Anyway, I wouldn't get too attached to the on..goto.. syntax, since it's more clearly coded in a case statement... until we get error trapping. :)

            Still agitating for that, Carl, since you know we need it. I mean, even 20-yr-old BASICs had it. (Not jabbin' at ya, just joining the petition. :)

            Happy trails,
            - Foon
          • fencer22002
            ... but ... out, this code structure (on... goto...) was designed for handling errors which have been TRAPped, which is quite different from exception handling
            Message 5 of 7 , Mar 31 5:05 AM
            • 0 Attachment
              --- In libertybasic@yahoogroups.com, "Foon" <foon@s...> wrote:
              > > Actually there is also a form that works like a case statement,
              but
              > > only for numeric values. You would say:
              > >
              > > on varName goto 200, 300, 400, 500
              > >
              > > If varName is 1, it would goto 200, if 2 it would goto 300, etc.
              > >
              > > The closest thing you have now is SELECT CASE.
              > >
              > > Here's a clip from the help file:
              >
              > Well, yeah, you CAN use it like that. But as has been pointed
              out, this code structure (on... goto...) was designed for handling
              errors which have been TRAPped, which is quite different from
              exception handling (if you happen to have run across that term). The
              point of that syntax is to be able to branch based on a 1,2,3,etc
              error "return code" from a process (either internal to the pgm or
              external (hard or soft)).
              >
              > Many of us, and it would be ALL of us if we ALL knew the value of
              it, are hoping and praying that Carl will implement error trapping in
              LB. As odd as it may sound, it's MUCH easier to handle an error, and
              correct it, AFTER it occurs rather than trying to anticipate and head
              off all possible errors BEFORE they can occur. The opposite is true,
              of course, for issues like input validation, but that a whole 'nother
              thing. ;)
              >
              > Anyway, I wouldn't get too attached to the on..goto.. syntax,
              since it's more clearly coded in a case statement... until we get
              error trapping. :)
              >
              > Still agitating for that, Carl, since you know we need it. I
              mean, even 20-yr-old BASICs had it. (Not jabbin' at ya, just joining
              the petition. :)
              >
              > Happy trails,
              > - Foon

              Thanks for the input.

              I should have included an example of the on...goto.. statement, so
              here it is.

              LET T$ = " "
              LET P(9) = 1
              LET L = X(0,0)
              ON L > 0 GOTO 1110

              As mentioned earlier, it seems as though "if" may be substituted
              for "on" with no ill effects. True?

              Concerning "select case", I looked at the definition in Help and it
              seems like just another way to say if...then... How is it different?

              And the error trapping thing is about 2 millimeters above my head. I
              sort of know what you are talking about, but not really.

              Thanks to all,
              Fencer
            • Foon
              ... Well, y know, I just played around a bit with on... goto... and I couldn t get it to work at all. I assume it s no longer supported in 3.02...? But yes,
              Message 6 of 7 , Mar 31 6:57 PM
              • 0 Attachment
                > Thanks for the input.
                >
                > I should have included an example of the on...goto.. statement, so
                > here it is.
                >
                > LET T$ = " "
                > LET P(9) = 1
                > LET L = X(0,0)
                > ON L > 0 GOTO 1110
                >
                > As mentioned earlier, it seems as though "if" may be substituted
                > for "on" with no ill effects. True?

                Well, y'know, I just played around a bit with "on... goto..." and I couldn't get it to work at all. I assume it's no longer supported in 3.02...?

                But yes, the way you were trying to use it, the "if" would substitute. The whole idea of "on... goto..." is to have multiple branches for multiple values of the tested variable, as in "on x goto 10, 20, 30, 40, 50".

                > Concerning "select case", I looked at the definition in Help and it
                > seems like just another way to say if...then... How is it different?

                It's different because the case structure is easier to read and follow than many blocks of "ELSEIF code" (which isn't supported by LB yet anyway). If you only have two sets of code to potentially run (with one block executed un a special condition and the other block always run if that condition is false), an "if... then... else... end if) block is perfect.

                But if you wanted to run various sets of commands based on a potentially non-sequential (or large) number of possible values for a variable, then the case statement structure is far easier to code and later follow when reading.

                > And the error trapping thing is about 2 millimeters above my head. I
                > sort of know what you are talking about, but not really.

                No sweat. Whenever Carl implements error trapping, there will be a LOT of discussion about it here. <chuckle>

                Take care,
                - Foon
              • carlgundel
                ... and I couldn t get it to work at all. I assume it s no longer supported in 3.02...? ON GOTO has never been a supported feature of Liberty BASIC. ...
                Message 7 of 7 , Mar 31 7:05 PM
                • 0 Attachment
                  --- In libertybasic@yahoogroups.com, "Foon" <foon@s...> wrote:
                  > Well, y'know, I just played around a bit with "on... goto..."
                  and I couldn't get it to work at all. I assume it's no longer
                  supported in 3.02...?

                  ON GOTO has never been a supported feature of Liberty BASIC.

                  > It's different because the case structure is easier to read and
                  follow than many blocks of "ELSEIF code" (which isn't supported by
                  LB yet anyway).

                  Nested block IF/THEN statements are supported in Liberty BASIC, but
                  not in precisely the way they are implemented in QBasic.

                  Just as a short example, the following is valid in LB:

                  if a < b then
                  'do something
                  if x < y then
                  'do something else
                  end if
                  else
                  'do even more stuff
                  end if

                  -Carl
                Your message has been successfully submitted and would be delivered to recipients shortly.