Splitting a long string to shorter strings + funny bug

urpok

After this nice 2013 R2 we have been able to use text strings of unlimited length.
This is very handy, but it also causes a need to split them into smaller chunks.
I created a function that does exactly that, but bumped into a funny bug:
It seems that if you give an array as a parameter to a function, called function sets the size of the local array to match the size of the array in calling function!

The POC code below has an array of 100 in the calling function, and an array of 2 in the called function, and yet it seems to be working fine! (At least in my NAV 2013 R2 build 36897)

This is funny, since it eliminates the need to declare an array in a function way too big. I would have reported this to Microsoft also, but it seems that I would have to pay 299€ for that, since we don't seem to have any technical credits left

Please find stringwrapper function below, and enjoy!

OBJECT Codeunit 50101 TestCodeunit
{
  OBJECT-PROPERTIES
  {
    Date=04.07.14;
    Time=10:58:00;
    Modified=Yes;
    Version List=INN000;
  }
  PROPERTIES
  {
    OnRun=VAR
            tempArray@1000000004 : ARRAY [100] OF Text;
            OK@1000000002 : Boolean;
            i@1000000001 : Integer;
            MsgText@1000000000 : Text;
          BEGIN
            CLEAR(tempArray);
            tempArray[1] := 'This is a long text i want to wrap to lines with max 5 characters long';
            OK := WrapText(tempArray,5);
            i := 0;
            REPEAT
              i +=1;
              MsgText += FORMAT(i) + ': "' + tempArray[i] + '"\';
            UNTIL(STRLEN(tempArray[i])=0);

            MESSAGE('Success:' + FORMAT(OK) + '\' + MsgText);
          END;

  }
  CODE
  {

    PROCEDURE WrapText@1000000000(VAR inText@1000000000 : ARRAY [2] OF Text;MaxLen@1000000001 : Integer) OK : Boolean;
    VAR
      i@1000000002 : Integer;
    BEGIN
      //Spreads the first line of inText array to other lines as MaxLen long strings, returns ok if no overflow
      IF (ARRAYLEN(inText) < 2) THEN
        ERROR('Array must be bigger than 1');
      IF (MaxLen < 1) THEN
        ERROR('MaxLen has to be a positive integer');
      FOR i := 1 TO ARRAYLEN(inText)-1 DO BEGIN
        inText[i+1] := COPYSTR(inText[i],MaxLen+1);
        inText[i]   := COPYSTR(inText[i],1,MaxLen);
        IF (STRLEN(inText[i+1]) <= MaxLen) THEN
          EXIT(TRUE);
      END;
      EXIT (STRLEN(inText[i]) <= MaxLen);
    END;

    BEGIN
    END.
  }
}

//Urpok

tinoruijs

Handy those unlimited texts indeed. I also created a kind of wrapper. Works great!
:-)
Thanks for sharing!

thegunzo

There is nothing strange about this behaviour when using the parameter as a reference to the original variable.

VAR inText@1000000000 : ARRAY [2] OF Text

means that inText will always be the parameter that you use when calling this function.

having

inText@1000000000 : ARRAY [2] OF Text

will not do this. Then again you will need to have

VAR outText@1000000000 : ARRAY [2] OF Text

to return the split string.

urpok

Thank you Gunnar for clarifying this. It actually makes sense when you put it that way.
I tested this with other Var'ed parameters, and it seems to be working similarly every time! This really opens up some new ways how to resolve certain problems

This behaviour also reveals something about how C/AL works internally. I somehow have always thought that parameters are separated from internal variables following way: when a function receives a variable as a parameter, it is converted to local variable, manipulated inside the function and copied back to calling variable when returning it to calling function.
Instead of that they really are references to calling variables. Local dimensions are totally overriden.

But why bother declare any dimensions to var'ed parameter in a function at all (other than code readablity, that is ?

//urpok