Announcement

Collapse
No announcement yet.

Why the comma

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

  • Why the comma

    I have noticed, but don't know why, some PB statements require a comma before arguments:

    Control Add Label, hDlg, ...

    and some don't?

    Control Get Text hDlg, ...

    Does someone know why?

    Thanks,
    Gary

  • #2
    Silly thing to point out is:
    CONTROL ADD classname$, hDlg, id&, txt$, x, y, xx, yy [, [style&] [, [exstyle&]]] [[,] CALL callback]

    So:
    CONTROL ADD LABEL, hDlg, id&, txt$, x, y, xx, yy [, [style&] [, [exstyle&]]] [[,] CALL callback]

    Is merely using an internally defined constant to add a specific type of control.
    Furcadia, an interesting online MMORPG in which you can create and program your own content.

    Comment


    • #3
      I thought of that, but the last capitalized word in the statement isn't always followed by a comma, as in this example:

      DIALOG SET ICON hDlg, newicon$


      What you say can still be true, but I was hoping there was some visual/cerebral way to know without having to simply memorize which statement uses them, and which don't.

      Comment


      • #4
        Features created on different days and/or by different people and neither the beta testers nor the PB quality control people noticed this inconsistency.

        That, or a burning desire to send all users to the help file as often as possible.

        Maybe some day the BASIC compiler will treat 'comma' the way COBOL does: as white space, just like space or tab. That is, in COBOL, all commas are documentary-only. I think there are most a handful of PB statements which would require revision to support this, none of which occur to me off my head, except the couple which support "null/none" parameters and require commas as 'placeholders' , eg... MSGBOX
        Last edited by Michael Mattias; 15 Jan 2009, 02:56 PM.
        Michael Mattias
        Tal Systems (retired)
        Port Washington WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          Memorize? You mean we're supposed to know this stuff that well?

          Personally, with the number of languages I work with on a daily basis, I'm lucky to remember that the particular language I'm working with will do something, and remember how to locate the information on the syntax.

          For those, you could remember it as:
          DIALOG -> I'm telling the dialog to do something.
          SET -> it needs to set something to the main dialog internal logic.
          ICON -> I want it to have a new icon.
          hDlg -> which dialog.
          , newicon$ -> this icon.
          Furcadia, an interesting online MMORPG in which you can create and program your own content.

          Comment


          • #6
            The irregularity of the comma is pretty sloppy design and wouldn't be remarkable in most Basics. I suspect it stands out in PB because there's so much very careful design and so very little sloppiness.

            Barry

            Comment


            • #7
              I'm a beta tester and this question did come up early in the development of DDT. As I remember it... there is a logical reason, I just can't... remember it. I know that's not very helpful but maybe it will ring a bell with another tester.

              Sloppy? Unlikely.

              -- Eric
              "Not my circus, not my monkeys."

              Comment


              • #8
                I was hoping there was some visual/cerebral way to know without having to simply memorize which statement uses them, and which don't.
                Looks to me like all of the CONTROL ADD xxxx statements have a comma after the xxxx
                None of the other CONTROL statements use a comma.

                Paul.

                Comment


                • #9
                  For the CONTROL ADD xxxx statements, I always thought that the command was "CONTROL ADD" and the "xxxx" was the first argument.

                  Comment


                  • #10
                    Originally posted by Charles Dietz View Post
                    For the CONTROL ADD xxxx statements, I always thought that the command was "CONTROL ADD" and the "xxxx" was the first argument.
                    I think Charles has something there. In my mind, there are three ways of expressing code:
                    1. FUNCTION/END FUNCTION
                    2. SUB/END SUB
                    3. DDT Statements

                    FUNCTION/END FUNCTION statements
                    Purpose
                    Define a Function block.

                    Syntax
                    [CALLBACK | THREAD] FUNCTION FuncName [BDECL | CDECL | SDECL] [ALIAS "AliasName"] [([arguments])] [EXPORT | PRIVATE] [AS type]
                    [DIM | LOCAL | STATIC variable list]

                    {statements}

                    [{FuncName | FUNCTION} = ReturnValue]

                    {statements}

                    [EXIT FUNCTION]

                    {statements}

                    END FUNCTION
                    Notice that [([arguments])] [ are optional, but if used, must be enclosed in parentheses.


                    SUB/END SUB statements
                    Purpose
                    Define a Sub block.

                    Syntax
                    [STATIC] SUB ProcName [BDECL | CDECL | SDECL] [ALIAS "AliasName"] [([arguments])] [EXPORT | PRIVATE] [STATIC]

                    [LOCAL variable_list]

                    [STATIC variable_list]

                    {statements}

                    [EXIT SUB]

                    {statements}

                    END SUB

                    Remarks
                    All executable code must reside in a Sub (Function. Method, or Property) block. You cannot define a procedure inside another procedure.

                    SUB and END SUB define a subroutine-like block of statements called a procedure (or subprogram), which is invoked with the CALL statement, and may be passed parameters by value or by reference.

                    A Sub may also be invoked without the use of the CALL statement. If the CALL statement is omitted, the parentheses around the arguments list must also be omitted.
                    The DDT statements, as well as the XPRINT, GRAPHICS and etc., statements are similar to the SUB/END SUB statements without the CALL. That is, the parentheses are omitted and the arguments are separated with commas. The problem with these statements is in determining what the statement is and what are the first and subsequent arguments, especially where the statement has multiple words. Consider the following statement:

                    CONTROL ADD BUTTON, hDlg, id&, txt$, x, y, xx, yy [, [style&] [, [exstyle&]]] [[,] CALL callback]
                    If "BUTTON" were an argument, it would be preceded with a comma. Instead, it is followed by a comma since hDlg is the first argument.

                    So, the statements in the help pages are shown in all capital letters, followed by a comma, followed by the list of arguments, separated by commas. This helps to understand which words constitute the statement, and which are arguments. For this reason, it may be useful to set your editor's option to capitalize the keywords. You don't have to memorize statement's format, but frequent use of the help manual will eventually set it in your mind.
                    Last edited by Robert DeBolt; 17 Jan 2009, 02:21 AM.
                    Regards,
                    Bob

                    Comment

                    Working...
                    X