Can't identify next operand

[Brian Alvarez]

 Hello Charles, i implemented the double pointer to fix an issue as you suggested like this:

Code: [Select]

FUNCTION OPTIONALLYADDFUNC(?ARR_STRINGDATA *sd, LONG *index, STRING **ce) AS LONG

END FUNCTION
 This fixes all the issues with any variable type, but if i ever invoke the function using a literal string like this:

Code: [Select]

OPTIONALLYADDFUNC(sd, index, "0, ")
 I get this during compilation:

Code: [Select]

ERROR: ASSEMBLER:
 ERR: lea eax,"0, "!!  Can't identify next operand '
LINE: 1094
FILE: "main source
 I know removing the double pointer fixes it but i cant generate different code depending on how it is invoked because a function can be invoked in several ways throgouth the program. Is there another way to avoid this?

 The code compiles fine when it is a function, like this:

Code: [Select]

OPTIONALLYADDFUNC(sd, index, TRIM$("0, ", 0, null))
 So i wonder if this is an issue with Oxygen?

[Charles Pegge]

Hi Brian,

Theproblem is passing string literals and string expressions to functions expecting an array block of strings (double pointered).

Currently, this is resolved by passing literals and expressions to a temp string beforehand and passing the temp string, but I'm working on a solution.

[JRS]

The literal vs. variable state isn't an easy nut to crack when using them as arguments to procedures. SB converts all string literals to a temp null terminated string before passing them along. Literals are like comments that assume to be code. Pointerless references.

[Brian Alvarez]

 Thanks Charles!, i appreciate it.