Method ADD-FIELDS-FROM except list expression does not remov

Try removing space between comma and column name when you define cSkipList variable. This should work.

Code after removing space:

DEF VAR hTempTable AS HANDLE NO-UNDO. 
DEF VAR cTableName AS CHAR NO-UNDO INIT "Customer".
DEF VAR cSkipList AS CHAR NO-UNDO INIT "Fax,Comments".
DEF VAR hBuffer AS HANDLE NO-UNDO.
DEF VAR lii AS INT NO-UNDO.
/* Create TEMP-TABLE */
CREATE TEMP-TABLE hTempTable.
hTempTable:ADD-FIELDS-FROM(cTableName, cSkipList).
hTempTable:TEMP-TABLE-PREPARE(cTableName).
hBuffer = hTemptable:DEFAULT-BUFFER-HANDLE.
REPEAT lii = 1 TO hBuffer:NUM-FIELDS:
   DISP SUBST("&1. &2", lii, hBuffer:BUFFER-FIELD (lii):NAME).
END.

Thanks for pointing it out [mention:f2c3b268940943f69cb639470006dc63:e9ed411860ed4f2ba0265705b8793d05].

Although its very stupid-ish from Progress to have such a "featured bug".

[mention:43713cf888d84bdcb3637e465ffa1de6:e9ed411860ed4f2ba0265705b8793d05] - Well going by your statement Progress should change the documentation in lot of places to say `<delimiter>+space delimited list`(Example: ENTRY function). In my opinion "field1,field2" should be treated same as "field1, field2" . Having a space between comma separated list usually improves readability (yes it does :-)). So skipping all the field after space without any error information is perhaps not the right way of doing it.

I don't mind having the list with or without spaces. As long as documentation is consistent (which doesn't seem to be), I'm fine with it. :)

Now we seem to be on the same page Brian. Yes I will create an enhancement request.

Thanks.

[mention:c897c4efd7814789b6aaf20f2b3bdaeb:e9ed411860ed4f2ba0265705b8793d05] - Yes plz vote. Thanks.

community.progress.com/.../method_add-fields-from_should_trim_space_characters_from_except-list_expression

lookup("b","a,b,c") is 2

lookup("b","a, b,c")   /* one space before "b" */  is 0

Should ignore the left trailing space? I think: no.

And, if it did ignore the spaces, what would you do when you had a case where the space was significant.  The only reason for the space is to make it more easily read by a human.  

"The only reason for the space is to make it more easily read by a human. "

Isn't that a good reason? In a 4GL?

Not everybody does generate every line of ABL code like you do. Maintainable and future-proof code needs to remain readable by humans. So in cases, where the list cannot contain entries with white spaces (ADD-FIELDS-FROM, the original topic) here - what would be the problem with ignoring those white spaces?

In cases with NUM-ENTRIES, ENTRY, ... we'd need an additional argument, to ignore white spaces at the beginning and end of entries. But not add methods like ADD-FIELDS-FROM, ATTACH-DATA-SOURCE, etc.... where the ABL knows, the entries must be field names.

Exactly my reason [mention:6e3b17cb0ff148039a2aabb4c7834ce4:e9ed411860ed4f2ba0265705b8793d05]. Thanks.

Also if at all having a space is a problem then why not throw error rather then silently truncating all the fields after the space.

It is not truncating all the fields after the space; it just skip the one with the space, but if there are more fields without space they are finded correctly.

That's simply great. It's even inconsistent in skipping fields.

Example 1: "Fax, Comments,Email,Discount". Fax and Discount fields are skipped but Comments and Email are not.

Example 2: "Fax, Comments,Email". Fax field is skipped but Comments and Email are not.

I think the important thing is to make this consistent either this way or that way. So

1. either the ADD-FIELDS-FROM method (which expects field names) skips spaces from the list OR

2. should throw appropriate error info so that the users know not to have spaces in the list.