Why the comma

[Gary Beene]

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

[colin glenn]

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.

[Gary Beene]

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.

[Michael Mattias]

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

[colin glenn]

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.

[Barry Marks]

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

[Eric Pearson]

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

[Paul Dixon]

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.

[Charles Dietz]

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

[Robert DeBolt]

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.