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

Is this a Bug?

Expand Messages
  • Baz
    Hi all, I am new to Liberty Basic, whilst looking at and trying different code from LB forums, Etc. I keep finding little snippets of code like below that I
    Message 1 of 12 , Aug 22, 2010
      Hi all,

      I am new to Liberty Basic, whilst looking at and trying different code from LB forums, Etc.
      I keep finding little snippets of code like below that I would like to use but I keep getting the following error message.
      BASIC Compile Halted: Type mismatch-valid formats:
      using(template$,number), from what I can understand the "a$" in the code below is causing is the problem?
      I can only conclude that this might be a bug in
      "Liberty Basic Pro V4.04" as I don't think it's a typo, because this error appears many times from different programs.

      print #main.graphicbox1, "stringwidth? a$ FieldWidth"
      wend
      end if
      CurStr$ = space$(padNum) + "$" + Using("####.##",a$)
      CurrencyFormatStr$ = CurStr$

      Any suggestions?
    • Gary Passmore
      From the Help file: USING(templateString, numericExpression) But, you are using a StringExpression, i.e., a$ However, the command works for me either with a
      Message 2 of 12 , Aug 24, 2010
        From the Help file:

        USING(templateString, numericExpression)

        But, you are using a StringExpression, i.e., a$

        However, the command works for me either with a numeric or string variable, so
        it should for you.

        Viz.

        [code]
            nomainwin
            WindowWidth = 375
            WindowHeight = 410
            UpperLeftX=int((DisplayWidth-WindowWidth)/2)
            UpperLeftY=int((DisplayHeight-WindowHeight)/2)
            graphicbox #main.graphicbox1,   5,   7, 360, 370
            open "STRINGWIDTH TEST" for window as #main
            #main.graphicbox1 "down; fill white; flush"
            #main "font ms_sans_serif 10"
            #main "trapclose [quit]"
            '(wend)
            '(end if)
            padNum=5
            'a$=using("####.##","453.129")
            a=453.129
            a$=str$(a)
            #main.graphicbox1 "place 10 20"
            #main.graphicbox1 "\a$ = ";a$
            #main.graphicbox1 "stringwidth? a$ FieldWidth"
            #main.graphicbox1 "\a$ FieldWidth = ";FieldWidth
            #main.graphicbox1 "\";Using("####.##",a)
            CurStr$ = space$(padNum) + "$" + Using("####.##",a)
            #main.graphicbox1 "\";CurStr$;" (using a)"
            CurStr$ = space$(padNum) + "$" + Using("####.##",a$)
            #main.graphicbox1 "\";CurStr$;" (using a$)"
            wait
        [quit]
            close #main
            end
        [/code]

        Frankly, I can't see where your code went wrong. The 'end if' and 'wend'
        indicates that it may be in the missing portion.

        ...from the world according to GaRPMorE




        ________________________________
        From: Baz <robazz@...>
        To: libertybasic@yahoogroups.com
        Sent: Sun, August 22, 2010 10:37:43 AM
        Subject: [libertybasic] Is this a Bug?

         
        Hi all,

        I am new to Liberty Basic, whilst looking at and trying different code from LB
        forums, Etc.
        I keep finding little snippets of code like below that I would like to use but I
        keep getting the following error message.
        BASIC Compile Halted: Type mismatch-valid formats:
        using(template$,number), from what I can understand the "a$" in the code below
        is causing is the problem?
        I can only conclude that this might be a bug in
        "Liberty Basic Pro V4.04" as I don't think it's a typo, because this error
        appears many times from different programs.

        print #main.graphicbox1, "stringwidth? a$ FieldWidth"
        wend
        end if
        CurStr$ = space$(padNum) + "$" + Using("####.##",a$)
        CurrencyFormatStr$ = CurStr$

        Any suggestions?







        [Non-text portions of this message have been removed]
      • Gary Passmore
        I see, of course, that no matter how careful, I always find something wrong when reviewing the message again, after it has been sent. :(   Here is a third
        Message 3 of 12 , Aug 24, 2010
          I see, of course, that no matter how careful, I always find something 'wrong'
          when reviewing the message again, after it has been sent. :(
           
          Here is a third method I meant to include:
           
          [code]
              a$=using("####.##","453.129")
              CurStr$ = space$(padNum) + "$" + a$
              #main.graphicbox1 "\";CurStr$;" (using 'using' a$)"
          [/code]

          which explains the unused line:
          ' a$=using("####.##","453.129")

          from the confusing world according to GaRPMorE




          [Non-text portions of this message have been removed]
        • JanetTerra
          Gary, Which version of LB are you using? In LB 4.04 using( ####.## , 123.4 ) rather than using( ####.## , 123.4) will definitely give the BASIC Compile
          Message 4 of 12 , Aug 24, 2010
            Gary,
            Which version of LB are you using? In LB 4.04 using("####.##", "123.4") rather than using("####.##", 123.4) will definitely give the "BASIC Compile Halted: Type mismatch - valid formats: using(template$, number)" error message. The number to be formatted must be a number and not a string.

            --- In libertybasic@yahoogroups.com, Gary Passmore <garpmore@...> wrote:
            >
            > From the Help file:
            >
            > USING(templateString, numericExpression)
            >
            > But, you are using a StringExpression, i.e., a$
            >
            > However, the command works for me either with a numeric or string variable, so
            > it should for you.
            >
            > Viz.
            >
          • garpmore
            ... Janet, Although I have downloaded LB4.04Pro, it is yet to be installed, and I am still using V4.03. Since all of forms I used, including the two you cite,
            Message 5 of 12 , Aug 25, 2010
              --- In libertybasic@yahoogroups.com, "JanetTerra" <janetterra@...> wrote:
              > Gary,
              > Which version of LB are you using? In LB 4.04 using("####.##", "123.4") rather than using("####.##", 123.4) will definitely give the "BASIC Compile Halted: Type mismatch - valid formats: using(template$, number)" error message. The number to be formatted must be a number and not a string.


              Janet,
              Although I have downloaded LB4.04Pro, it is yet to be installed, and I am still using V4.03. Since all of forms I used, including the two you cite, compile and run successfully. I wonder why 4.04 has trouble with it. I don't see that as an improvement, unless the code was changed to match the Help File. Why not change the Help File? Will I have to "unlearn" LB for the upgrade?

              In fact, since "stringwidth? string$ sringwidth" must have a string, you could do this to get the pixels of the reformated string:
              a$=using("####.##","453.129")
              #main.graphicbox1 "stringwidth? a$ FieldWidth"
              #main.graphicbox1 "\a$ FieldWidth = ";FieldWidth
              which is four pixels less than the unrounded numeric value.
              This also runs without error in V4.03

              I have just tested this, with the added lines, and it runs fine:

              [code]
              nomainwin
              WindowWidth = 375
              WindowHeight = 410
              UpperLeftX=int((DisplayWidth-WindowWidth)/2)
              UpperLeftY=int((DisplayHeight-WindowHeight)/2)
              graphicbox #main.graphicbox1, 5, 7, 360, 370
              open "STRINGWIDTH TEST" for window as #main
              #main.graphicbox1 "down; fill white; flush"
              #main "font ms_sans_serif 10"
              #main "trapclose [quit]"
              padNum=5
              a=453.129
              a$=str$(a)
              #main.graphicbox1 "place 10 20"
              #main.graphicbox1 "\a$ = ";a$
              #main.graphicbox1 "stringwidth? a$ FieldWidth"
              #main.graphicbox1 "\a$ FieldWidth = ";FieldWidth
              #main.graphicbox1 "\";Using("####.##",a)
              CurStr$ = space$(padNum) + "$" + Using("####.##",a)
              #main.graphicbox1 "\";CurStr$;" using(''####.##'',a)"
              CurStr$ = space$(padNum) + "$" + Using("####.##",a$)
              #main.graphicbox1 "\";CurStr$;" using(''####.##'',a$)"
              a$=using("####.##","453.129")
              CurStr$ = space$(padNum) + "$" + a$
              #main.graphicbox1 "\";CurStr$;" where a$=using(''####.##'',''453.129'')"
              CurStr$ = space$(padNum) + "$" + using("####.##", "123.4")
              #main.graphicbox1 "\";CurStr$;" using (''####.##'', ''123.4'')"
              CurStr$ = space$(padNum) + "$" + using("####.##", 123.4)
              #main.graphicbox1 "\";CurStr$;" using(''####.##'', 123.4)"
              #main.graphicbox1 "\";Using("####.##",453.129)
              #main.graphicbox1 "\";Using("####.##","453.129")
              wait
              [quit]
              close #main
              end
              [/code]
            • JanetTerra
              One of the advantages of 4.04 over 4.03 is better error trapping and then improved error messaging. This wasn t done to conform with the help file, it was
              Message 6 of 12 , Aug 25, 2010
                One of the advantages of 4.04 over 4.03 is better error trapping and then improved error messaging. This wasn't done to conform with the help file, it was done to conform with the intent of the language structure.

                It's not much different from 3.+ which lacked a tab command and many programs were written using tab as a variable. Those programs will give an error message when loaded into the LB 4.+ IDE. So some of those programs have needed to be tweaked.

                Will you have to unlearn LB? Nah, the error message will tell you exactly what you need to fix. :)

                I have always used
                #main.g, "Down; Cls; Fill Red"

                Turns out using a comma without the preceding print is an undocumented feature and, while it works now, it may not work in future versions, so I've had to rethink my coding style, but that doesn't mean I had to relearn LB.


                --- In libertybasic@yahoogroups.com, "garpmore" <garpmore@...> wrote:
                >
                >
                >
                >
                >
                >
                >
                > --- In libertybasic@yahoogroups.com, "JanetTerra" <janetterra@> wrote:
                > > Gary,
                > > Which version of LB are you using? In LB 4.04 using("####.##", "123.4") rather than using("####.##", 123.4) will definitely give the "BASIC Compile Halted: Type mismatch - valid formats: using(template$, number)" error message. The number to be formatted must be a number and not a string.
                >
                >
                > Janet,
                > Although I have downloaded LB4.04Pro, it is yet to be installed, and I am still using V4.03. Since all of forms I used, including the two you cite, compile and run successfully. I wonder why 4.04 has trouble with it. I don't see that as an improvement, unless the code was changed to match the Help File. Why not change the Help File? Will I have to "unlearn" LB for the upgrade?
                >
                > In fact, since "stringwidth? string$ sringwidth" must have a string, you could do this to get the pixels of the reformated string:
                > a$=using("####.##","453.129")
                > #main.graphicbox1 "stringwidth? a$ FieldWidth"
                > #main.graphicbox1 "\a$ FieldWidth = ";FieldWidth
                > which is four pixels less than the unrounded numeric value.
                > This also runs without error in V4.03
                >
                > I have just tested this, with the added lines, and it runs fine:
                >
                > [code]
                > nomainwin
                > WindowWidth = 375
                > WindowHeight = 410
                > UpperLeftX=int((DisplayWidth-WindowWidth)/2)
                > UpperLeftY=int((DisplayHeight-WindowHeight)/2)
                > graphicbox #main.graphicbox1, 5, 7, 360, 370
                > open "STRINGWIDTH TEST" for window as #main
                > #main.graphicbox1 "down; fill white; flush"
                > #main "font ms_sans_serif 10"
                > #main "trapclose [quit]"
                > padNum=5
                > a=453.129
                > a$=str$(a)
                > #main.graphicbox1 "place 10 20"
                > #main.graphicbox1 "\a$ = ";a$
                > #main.graphicbox1 "stringwidth? a$ FieldWidth"
                > #main.graphicbox1 "\a$ FieldWidth = ";FieldWidth
                > #main.graphicbox1 "\";Using("####.##",a)
                > CurStr$ = space$(padNum) + "$" + Using("####.##",a)
                > #main.graphicbox1 "\";CurStr$;" using(''####.##'',a)"
                > CurStr$ = space$(padNum) + "$" + Using("####.##",a$)
                > #main.graphicbox1 "\";CurStr$;" using(''####.##'',a$)"
                > a$=using("####.##","453.129")
                > CurStr$ = space$(padNum) + "$" + a$
                > #main.graphicbox1 "\";CurStr$;" where a$=using(''####.##'',''453.129'')"
                > CurStr$ = space$(padNum) + "$" + using("####.##", "123.4")
                > #main.graphicbox1 "\";CurStr$;" using (''####.##'', ''123.4'')"
                > CurStr$ = space$(padNum) + "$" + using("####.##", 123.4)
                > #main.graphicbox1 "\";CurStr$;" using(''####.##'', 123.4)"
                > #main.graphicbox1 "\";Using("####.##",453.129)
                > #main.graphicbox1 "\";Using("####.##","453.129")
                > wait
                > [quit]
                > close #main
                > end
                > [/code]
                >
              • Stefan Pendl
                ... LB4.04 does not have a problem, LB4.03 does not catch all type mismatch errors. The definition of the function is USING(FormatString$, Number). If the
                Message 7 of 12 , Aug 29, 2010
                  >
                  > Janet,
                  > Although I have downloaded LB4.04Pro, it is yet to be
                  > installed, and I am still using V4.03. Since all of forms I
                  > used, including the two you cite, compile and run
                  > successfully. I wonder why 4.04 has trouble with it. I don't
                  > see that as an improvement, unless the code was changed to
                  > match the Help File. Why not change the Help File? Will I
                  > have to "unlearn" LB for the upgrade?
                  >

                  LB4.04 does not have a problem, LB4.03 does not catch all type mismatch errors.

                  The definition of the function is USING(FormatString$, Number).

                  If the syntax parser allows bad syntax, then there will be problems.

                  The syntax parser of LB4.04 was improved to better catch syntax errors and give better feedback to the user to allow for faster
                  fixing of syntax problems.

                  If it is allowed to write things in a way, that is not documented and not by definition, how would one be able to work out bugs in
                  his code?

                  ---
                  Stefan Pendl
                  http://stefanpendl.runbasichosting.com/

                  Liberty BASIC 4.04 Pro ... http://www.libertybasic.com/assist.html
                  Liberty BASIC 4.04 ....... http://www.libertybasic.com/lb404setup.exe

                  Books at http://www.lulu.com/ and http://www.amazon.com/
                  Alyce Watson ... APIs for Liberty BASIC
                  Carl Gundel .... Beginning Programming with Liberty BASIC

                  Windows 7 Home Premium 64-bit RTM
                  AMD Turion X2 RM-70 2GHz, 4GB RAM
                • Richard
                  ... If the issue was simply that LB 4.03 fails to detect and report a Type Mismatch error, then the following statement would print zero, or nothing, or some
                  Message 8 of 12 , Aug 29, 2010
                    --- In libertybasic@yahoogroups.com, "Stefan Pendl" wrote:
                    > LB4.04 does not have a problem, LB4.03 does not catch all type
                    > mismatch errors.
                    >
                    > The definition of the function is USING(FormatString$, Number).

                    If the issue was simply that LB 4.03 fails to detect and report a Type Mismatch error, then the following statement would print zero, or nothing, or some other meaningless value:

                    print using("###", "123")

                    But that's not what happens. In fact, the statement prints '123'! So there wasn't a Type Mismatch to report (or not): LB 4.03 converts the string "123" into the numeric 123 and then works normally.

                    Admittedly this behaviour may be an undocumented feature of LB 4.03, but all languages have undocumented features that people come to rely upon, and users of LB 4.04 are entitled to be surprised that it no longer works. It cannot be called a bug, but dismissing it as "not a problem" is equally unreasonable.

                    Richard.
                  • Gary Passmore
                    ...   Stefan, I am aware of that. It was the first thing I said in my original post of 8/24. But when I tested it to be sure, I found it worked both ways.
                    Message 9 of 12 , Aug 29, 2010
                      >The definition of the function is USING(FormatString$, Number).
                       
                      Stefan, I am aware of that. It was the first thing I said in my original post of
                      8/24. But when I tested it to be sure, I found it worked both ways. This did not
                      surprise me particularly, as I have found a number of such contradictions in the
                      Help File.

                       
                      However, since it was working without error in 4.03 (as far as I have tested),
                      then where was the bug? If it had said one thing but required another, then
                      there would be a bug. Instead, it said one thing but accepted an alternative as
                      well. Is that a bad thing?
                       
                      Rather, the definition could be corrected to say Number Value or Number String.
                       
                      >If the syntax parser allows bad syntax, then there will be problems.
                       
                      If  print using("###.##","123.456") works without a problem, why is the syntax
                      "bad?"
                       
                      LB has a great syntax parser, but I enjoyed the less rigid syntax of Commodore
                      Basic, which recognized that "::", or a colon at the end of the line, with
                      nothing following was meaningless, and was more forgiving about semicolons, as
                      well. You could (as I recall) use a command like "print a$b$, and the
                      interpreter realized that if was two strings to be printed (like print a$;b$).

                       
                      >The syntax parser of LB4.04 was improved to better catch syntax errors and give
                      >better feedback to the user to allow for faster
                      fixing of syntax problems.
                      >If it is allowed to write things in a way, that is not documented and not by
                      >definition, how would one be able to work out bugs in
                      his code?
                       
                      It was not a 'bug' in 4.03. It was working fine. However 4.04 has created one
                      for code written with the former version, if it is run on the 'improved'
                      version. Backward compatability and maximum flexibility would be strived for.
                      This is a case of fixing something that was not broken, in my view.
                       
                      Respectfully,
                       
                      Gary




                      [Non-text portions of this message have been removed]
                    • Stefan Pendl
                      ... There have been other places, where a type mismatch was not caught, which resulted in problems, so the fixing of the type checker is catching those too
                      Message 10 of 12 , Aug 30, 2010
                        >  
                        > >The syntax parser of LB4.04 was improved to better catch
                        > syntax errors and give
                        > >better feedback to the user to allow for faster
                        > fixing of syntax problems.
                        > >If it is allowed to write things in a way, that is not
                        > documented and not by
                        > >definition, how would one be able to work out bugs in
                        > his code?
                        >  
                        > It was not a 'bug' in 4.03. It was working fine. However 4.04
                        > has created one
                        > for code written with the former version, if it is run on the
                        > 'improved'
                        > version. Backward compatability and maximum flexibility would
                        > be strived for.
                        > This is a case of fixing something that was not broken, in my view.
                        >  

                        There have been other places, where a type mismatch was not caught, which resulted in problems, so the fixing of the type checker is
                        catching those too now.

                        If the parser is too forgiving, how would one struggle, if he advances to another language, which is not that forgiving?

                        In my opinion, programming languages should be black and white, without a gray area.
                        There is only true or false or one and zero in the digital world.

                        ---
                        Stefan Pendl
                        http://stefanpendl.runbasichosting.com/

                        Liberty BASIC 4.04 Pro ... http://www.libertybasic.com/assist.html
                        Liberty BASIC 4.04 ....... http://www.libertybasic.com/lb404setup.exe

                        Books at http://www.lulu.com/ and http://www.amazon.com/
                        Alyce Watson ... APIs for Liberty BASIC
                        Carl Gundel .... Beginning Programming with Liberty BASIC

                        Windows 7 Home Premium 64-bit RTM
                        AMD Turion X2 RM-70 2GHz, 4GB RAM
                      • Richard
                        ... That is an idealistic view, and not achievable in practice. In the real world there will be differences between what the documentation says and how the
                        Message 11 of 12 , Aug 30, 2010
                          --- In libertybasic@yahoogroups.com, "Stefan Pendl" wrote:
                          > In my opinion, programming languages should be black and white,
                          > without a gray area. There is only true or false or one and zero
                          > in the digital world.

                          That is an idealistic view, and not achievable in practice. In the 'real world' there will be differences between what the documentation says and how the language actually behaves.

                          When the language's behaviour is actually more flexible than the documentation implies (which was the case with LB 4.03's handling of 'USING') don't you think it would be better to bring them into line by updating the documentation, rather than 'downgrading' the language to match the documentation?

                          Richard.
                        • Stefan Pendl
                          ... On the other hand, why implement separate variable types for numeric and string values, if we can just use one variable type and the interpreter/compiler
                          Message 12 of 12 , Aug 31, 2010
                            > >  
                            > > >The syntax parser of LB4.04 was improved to better catch
                            > > syntax errors and give
                            > > >better feedback to the user to allow for faster
                            > > fixing of syntax problems.
                            > > >If it is allowed to write things in a way, that is not
                            > > documented and not by
                            > > >definition, how would one be able to work out bugs in
                            > > his code?
                            > >  
                            > > It was not a 'bug' in 4.03. It was working fine. However 4.04
                            > > has created one
                            > > for code written with the former version, if it is run on the
                            > > 'improved'
                            > > version. Backward compatability and maximum flexibility would
                            > > be strived for.
                            > > This is a case of fixing something that was not broken, in my view.
                            > >  
                            >
                            > There have been other places, where a type mismatch was not
                            > caught, which resulted in problems, so the fixing of the type
                            > checker is catching those too now.
                            >

                            On the other hand, why implement separate variable types for numeric and string values, if we can just use one variable type and the
                            interpreter/compiler will decide, if it is a numerical or string value.

                            Take a look at Tcl/Tk, which does only have string variables and determines, if the content is numeric by the use of the variable.

                            Automatic type casting is a good thing, but do you really like to have the interpreter overrule your intention?

                            ---
                            Stefan Pendl
                            http://stefanpendl.runbasichosting.com/

                            Liberty BASIC 4.04 Pro ... http://www.libertybasic.com/assist.html
                            Liberty BASIC 4.04 ....... http://www.libertybasic.com/lb404setup.exe

                            Books at http://www.lulu.com/ and http://www.amazon.com/
                            Alyce Watson ... APIs for Liberty BASIC
                            Carl Gundel .... Beginning Programming with Liberty BASIC

                            Windows 7 Home Premium 64-bit RTM
                            AMD Turion X2 RM-70 2GHz, 4GB RAM
                          Your message has been successfully submitted and would be delivered to recipients shortly.