Announcement

Collapse
No announcement yet.

2 Questions

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 2 Questions

    1. PDS provides a method for obtaining an ASM + BASIC code listing at compile time which I have found invaluable for tweeking and debugging. Is there a method for obtaining a comparable listing in PB3.5?

    2. Sometimes, but not in every case, when I declare a sub procedure using BYVAL in the argument list, I receive the compile error "TYPE MISMATCH, MAY REQUIRE BY COPY." Is there some sort of special syntax that is not documented and sometimes I do it correctly and sometimes not? For Example:

    DEFINT A - Z

    DECLARE MySub(BYVAL F)
    DECLARE SomeSub(A$, B, C)

    CALL SomeSub(B$, C, D)

    END

    SUB SomeSub(C$, Q, R)

    CALL MySub(F)
    END SUB

    SUB MySub(BYVAL G)

    END SUB

    Will sometimes produce the error, while othertimes it will not.
    Walt Decker

  • #2
    1. Search the net for "disassembler" - you should find something that will help you.

    2. This is obviously psuedocode, as your declare statements are not compilable as they stand. I'll assume that this is just to show the general "lay of the land" in the code where you experience the problem?

    If you can locate a real source code module that can compiled and demonstrate this error, please email it to Tech Support and we'll look into the issue. Thanks!

    ------------------
    Lance
    PowerBASIC Support
    mailto:[email protected][email protected]</A>
    Lance
    mailto:[email protected]

    Comment


    • #3
      1. I hoped that an "undocumented" compile time swithch existed. Oh well.

      2. Yes, it is pseudo code, the real code is rather long and requires about 80Mb of support files. But why is it not compileable the way it stands? Although it does nothing it should still compile.

      I assume that I will also have to supply the serial number of the PB3.5 copy. Is that located on the PB disk?

      ------------------


      [This message has been edited by Walt Decker (edited May 20, 2000).]
      Walt Decker

      Comment


      • #4
        Walt,
        I like your number 2 question, I have asked Tech the question?
        Can I have a procedure call a procedure, they answered NO!
        I have called routines, from procedures, but only when they were
        compiled as units, which I guess 'CALLED', may not be the best
        terminology, hope you get my meaning.
        At any rate, I like the question, just wish I had a better answer.

        - Rick

        ------------------

        Comment


        • #5
          Just a thought, haven't tried it, but even though it is "within the rules" I'd avoid using both C (implied integer) and C$ (explicit string) so interchangebly.

          Either that, or procedure headers (SUB or FUNCTION lines) are not respecting the DEFINT statement and expect the default single precision.

          Bottom line, you should send compilable (in your case, non-compilable) code to PB. They don't need the support files, because the problem is not with running the code.

          MCM
          Michael Mattias
          Tal Systems Inc. (retired)
          Racine WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            Originally posted by Richard L Bianchi:
            I like your number 2 question, I have asked Tech the question?
            Can I have a procedure call a procedure, they answered NO!
            You must be thinking of some other "Tech"? This has always been permitted in every single compiler sold by PowerBASIC.

            Regardless, this is a completely different topic from Walter's original question, where he says that he intermittently gets a compile-time error on what appears to be perfect code. The problem is that we (PowerBASIC) need to see the problem before we can establish where the problem is.

            Walter, the code is not compilable as it stands because your declare statements are missing a clause. BTW, when/if you fix this, you'll find that this code DOES compile correctly, as expected!




            ------------------
            Lance
            PowerBASIC Support
            mailto:[email protected][email protected]</A>
            Lance
            mailto:[email protected]

            Comment


            • #7
              Yes, now that you point out that a clause is missing, I see why it is not compilable as it stands. I do not normally leave out things like that.

              I'll be sending the code to support shortly.

              Thank you, Lance.

              ------------------
              Walt Decker

              Comment


              • #8
                For anyone following this thread, the problem turned out to be an attempt to invoke a subroutine with parenthesis around the argument, but with no CALL keyword. The solution was to either add a CALL keyword, or omit the parenthesis from the statement.

                The real problem was partially obscured by the BYCOPY error message.


                ------------------
                Lance
                PowerBASIC Support
                mailto:[email protected][email protected]</A>
                Lance
                mailto:[email protected]

                Comment


                • #9
                  To amplify Lance's message, there are two ways to call a procedure:

                  Code:
                  CALL ProcedureName(Param1, Param2)
                  and

                  Code:
                  ProcedureName Param1, Param2
                  If you try to use

                  Code:
                  ProcedureName(Param1, Param2)
                  you will get a compile-time error. Unfortunately, the error message is misleading, so you just have to remember this one on your own. I recommend people use only one style of procedure call in all their programs; that way, they will seldom mix the two methods and see this error.

                  Alan

                  ------------------
                  Alan C. Earnshaw
                  Information Management Systems, Inc.
                  http://www.infoms.com
                  Alan C. Earnshaw
                  Information Management Systems, Inc.
                  http://www.infoms.com

                  Comment

                  Working...
                  X