VBA Argument Lists

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • NeoPa
    Recognized Expert Moderator MVP
    • Oct 2006
    • 32633

    VBA Argument Lists

    Originally posted by ZeppHead80
    ZeppHead80:
    From syntax error, missing operator (Post #19).
    but FindFirst doesn't require ( ) when passing arguments in.
    Technically, there are two basic types of procedure - Sub procedure and Function procedure (although there are also Methods, but they too can be broken down in the same way into Subs and Functions). The difference being that Function procedures return values whereas Sub procedures don't. VBA is a bit of a mess with what is allowed syntactically. Due mainly to being a derivative of early BASIC PLs which were introduced to make coding possible for those without so much experience. Unlike most other language families which typically have sterner syntax requirements.

    What that means for this is that VBA allows both types of procedure to be called as both types. A sub procedure should really be called similarly to a simple statement. In that version no parentheses are used and the parameters are supplied as a list after the name of the procedure call. A Function procedure, on the other hand, should be called in code that processes the return value - typically, but not limited to, assigning the value to a variable. When a function procedure is used in this way the parameters that follow the procedure call are enclosed in parentheses.

    To allow function calls to avoid using or saving their returned values there is a Call statement. This really just says - Run the Function procedure but just drop the returned result. In this situation the procedure is treated as a function and the parameters are enclosed in parentheses. Sub procedures can also be used with the Call statement, and their parameters are handled the same way.

    What all this boils down to is that the parentheses are not assoiciated with any particular procedure, but rather with how they are referenced in the code.
    Last edited by NeoPa; Oct 5 '11, 07:53 PM.
  • patjones
    Recognized Expert Contributor
    • Jun 2007
    • 931

    #2
    NeoPa
    VBA is a bit of a mess with what is allowed syntactically. Due mainly to being a derivative of early BASIC PLs which were introduced to make coding possible for those without so much experience.
    A bit off topic, but since you brought it up...I've been working with VBA for about five years now and honestly don't see how it's a derivative of BASIC. As with so many people, BASIC was my first programming language. To me, they don't appear to resemble each other in any manner. What gives?

    Comment

    • NeoPa
      Recognized Expert Moderator MVP
      • Oct 2006
      • 32633

      #3
      As you say, a little off-topic (Started by my trying to explain something mentioned earlier but veering off even then). I'll create a new thread from these posts. It won't be of any great interest to anybody but leaves it public without interfering with this thread.

      Comment

      • NeoPa
        Recognized Expert Moderator MVP
        • Oct 2006
        • 32633

        #4
        Originally posted by ZeppHead80
        ZeppHead80:
        To me, they don't appear to resemble each other in any manner. What gives?
        Time and evolution Pat. Just that (as far as I can see).

        I'm a little surprised you don't see any similarities though. For me, as I have used some of the other languages where typeing is mandated etc, VBA seems grouped with other BASICs I've used. I never touched any form of BASIC in my professional career until the late 1980s, and I can see the similarities across the various dialects. For me, the general feel of the syntax is quite recognisable, and quite different from most other languages I've used.
        Last edited by NeoPa; Oct 5 '11, 08:03 PM.

        Comment

        • patjones
          Recognized Expert Contributor
          • Jun 2007
          • 931

          #5
          It could be a function of me not having worked with BASIC in twenty years; my memory is certainly fragmented. The use of line numbers, GOTO, GOSUB, PRINT, and LET are all things that immediately come to mind though. I see similarities with control structures like IF...THEN...ELS E and FOR...NEXT.

          I think a huge difference arose with some important modifications:
          • The deprecation of line numbers and GOTO as a means of controlling flow of execution.
          • The introduction of stronger data typing and more flexibility with variable naming.
          • The introduction of procedures and functions.
          • The introduction of objects and use of associated methods.

          The list certainly isn't exhaustive. I'm sure others can contribute more. All this being said, I don't deny the connection!

          Comment

          • NeoPa
            Recognized Expert Moderator MVP
            • Oct 2006
            • 32633

            #6
            Line numbers have certainly become more optional as time has passed. There may still be some varieties that use them still though. GOTO, PRINT and LET are all still valid parts of the syntax. Labels were introduced to replace the need for line numbers some while back. LET is still an optional part of the syntax for an assignment. Try it. It still works. I'm not sure about GOSUB.

            Object Oriented was always a requirement for VBA so it had to be able to handle objects. Part of why PRINT is most known as Debug.Print nowadays, but there is also the facility to Print to logical files.
            • Definitely deprecated. GoTo discouraged.
            • And the 'option' to insist on declaring all variables. That's new, and almost professional :-D
            • Technically only the separating out of the procedures. GoSub was previously used to invoke subroutine procedures. Not functions though if I remember correctly.
            • The objects and methods were a requirement from the inception (of VBA). It was almost the raison d'etre.

            Comment

            Working...