Consistent use of quotation marks for function arguments

I've used the StrExtract() function a number of times in the past, and have just used the default settings, even though it would have been nice to use a different separator. Today, working on something new, I finally worked-out why I've got/ have had a problem with it -> not Reading The Fine Manual properly/ literally!

I started with this:

cnsObjNum= 1 ;
dbgInfo= StrExtract("0,0,120,120", cnsObjNum, "=") ;

, which produces an "Error 5" when doing a code check:
image

, yet, when I use:
dbgInfo = StrExtract("0,0,120,120", cnsObjNum, '=') ;

, absolutely no problem! The only difference between them is the use of double and single quotation marks for the value supplied to the separator argument.

Out of habit, and consistent code formatting style, I tend to use double quotes for encapsulating whole strings that are stored in variables, and single quotes for any within-string quotations, eg.
txtVar = "Mary had a little 'lamb', whose fleece was ..." ;

As far as I'm aware, StrExtract() is the only function that's so pedantic about how strings/ characters are passed-in. Most of the AB functions accept their arguments with double quote marks.

Does anyone know of any others, or why this is so?

Third parameter of StrExtract is not type string but type number.

See

var = ',';
printf( "type of ',' is: %s", typeof(var) );

So since it is number this

var = ',';

is the same as

var = 44;

->

var = ',';
printf( "\n',' returns: %g", var );

559

Take a look at ASCII table.

If you do this in C (character to int and vice versa)

int i;

char c = ',';
i = (int)c;
printf("char c to int i: %d\n", i);

i = 44;
c = (char)i;
printf("int i to char c: %c\n", c);

Then output would be

char c to int i: 44
int i to char c: ,

since there is a leading answer already, in "other" words the function allows you to use only a single character as a delimiter and not a string (or multiple characters) which you'd be familiar with in MS Excel for eg.

one that comes to my mind is
https://www.amibroker.com/guide/afl/addcolumn.html

AddColumn( IIf( Buy, 66, 83 ), "Signal", formatChar );
// is synonymous with
AddColumn( IIf( Buy, 'b', 's' ), "Signal", formatChar );

//but NOT
AddColumn( IIf( Buy, "buy", "sell" ), "Signal", formatChar );    // Erroneous

one could use an array of characters in other sense for AddColumn() otherwise you'd have to use AddTextColumn() which doesn't accept Arrays.

No, it is not.

There is fundamental difference between string (enclosed in " double quotation marks) and single character (enclosed in ' single apostrophes). String is a sequence of characters (actually it is array of characters (bytes) with null (zero byte) automatically appended at the end of the array). This is C-language convention for strings.

Single character (enclosed in single apostrophe) in C language and in AFL is actually just a integer number representing ASCII code of given character.

So single character can be used wherever a NUMBER is needed. String is NOT a number so these two are different types.

So 'a' is actually just a number and it has value of ASCII code of letter a, which is 97 (decimal) see http://www.asciitable.com/

https://www.quora.com/What-is-the-difference-between-a-string-constant-and-a-character-constant

http://c-faq.com/~scs/cgi-bin/faqcat.cgi?sec=charstring

If you ever wanted to convert from string to ascii code there is an ASC function for that
http://www.amibroker.com/f?asc (of course it converts ONE of characters from the string to ASCII code)

2 Likes

Everyone, thank you for your feedback & explanations, they make perfect and logical sense, I should have thought it through a bit more.

As AB “hides” or “takes care of” a lot of stuff behind the scenes, so that users don’t trip-up over too many of pedantries imposed by lower-level languages, I guess I was expecting this to also be the case, ie, that the type of quotation marks used was irrelevant, and I also presumed that the use of single quotation marks in the User Manual, separator = ',', was an arbitrary choice by the author at the time. Obviously, not. In the future, I'll try to pay a bit more attention to seemingly insignificant details.

@fxshrat – thanks for demonstrating that AB uses quotation marks for implied typecasting. I’ve learnt something new.

Yes, I’ve seen the ASCII table many times, and thanks for the link, I’ll save it for later use. I have a number of named constants for special ASCII characters, that I use every now and then, eg. mscChr171 = "½" ; // Maths: half, 1/2. The onscreen character can be generated by entering it on your keyboard, using Alt + ASCII code, but the ASCII code must be entered via the PCs numeric keypad (not the numbers across the top of the keyboard), use the “NumLock” button to turn the numeric keypad on/off.

Given your level of proficiency though, I’m probably preaching to the converted, however, others who read this post might benefit from the info.

Have you tried ASCII to EBCDIC conversions – they’re fun!!

@travick – thanks for the additional functions. In regard to:

the function allows you to use only a single character as a delimiter and not a string (or multiple characters) which you'd be familiar with in MS Excel for eg.

, there are times when you might want/ need to use multiple characters (a substring) as the delimiter.

Also, I think I expected all the Str…() functions to accept substrings, particularly when it’s possible to find the first occurrence of a substring with StrFind( string, substring ), and how many times a substring occurs using StrCount( ''string'', ''substring'' ) - I guess my logic was: if there’s a function that can find the number of instances of a substring, then surely it’s just a short step to use that same functionality for “cutting-up” a parent string. Oh-well.

@Tomasz – thanks for the explanation about the structure of strings and characters – like I said above, I didn’t expect some of the C-language pedanticness to be “leaking” through into AB, but I understand the reason for it: it’s a form of validating the input, forcing the users to comply with certain standards.

I guess, going forward, the choices that I can think of are:

  1. Do nothing, and hope that there aren’t too many more dummies like me to waste other people’s time.
  2. Update the User Manual, giving a little bit more detail about how to structure the “separator” argument, eg. “Note: the separator must be a single character, which must be defined by using single quotation marks before and after the character, or, provide its ASCII code equivalent (a number).” Preferably, also provide the link to the ASCII table mentioned by @fxshrat and @Tomasz , and how it can be entered via the keyboard.
  3. Update the function to permit the separator to be defined with double quotes, and internally, the function only uses the first character (if more than one is supplied).
  4. Update the function to permit multi-character separators.