Questions about "Set Display Width" behavior in JMP 16.2.0

[#1]

In trying to set a column's display width in JSL using JMP 16.2.0 (MacOS), I'm seeing several issues that I didn't see with JMP 15.

1.  The Set Display Width function appears to operate in two modes, depending on how it's used.  If it's called with a hard-coded arg value, it seems to be permanent.

col = Column("SN");
col << Set Display Width( 200 );

However, if it's called with a var arg, it displays as desired, but doesn't seem to get saved with the file.  (Or, at least, not saved as expected.)

x = 100; 
col << Set Display Width( x );

In the latter case, if the file is saved and then reopened, it renders with width 200, (presumably, from having run the former code).  Thus the 200 persists thru a file-save-close-and-reopen, but the 100 does not.

Even more strangely, if I open the table with JMP 15, it renders the width as 100, (and a y = col << Get Display Width() instruction confirms that).  But then going back and opening with JMP 16 renders a width of 200.  This suggests that, indeed, both values are saved with the file, and JMP has added a new mode to the column width attribute in JMP 16.  For reference, the attached file exhibits the issue.

2.  If the Set Display Width() function is the last function in the JSL script, and it uses a variable argument, it manifests a Scriptable[] error, and the operation does not appear to take place.  However, if a hard-coded value is given, everything seems to work well (and the set value is displayed in the log).  Is there maybe a new syntax requirement for this function or for JSL script terminations for JMP 16?  I notice that this behavior does not occur with JMP 15.

3.  A bit unrelated, but discovered when trying to understand this, with JMP 16, a string with a newline character seems to require at least one other non-whitespace character, otherwise it seems to be ignored.  Not sure if this is a design change or an SQA oversight.

col << Set Display Width( 200 );
y = col << Get Display Width();
Show(y);  Write("\!n");
Write("---");
x=100; 
col << Set Display Width( x );
y = col << Get Display Width();
Show(y);

Output:

y = 200;---
y = 200;

If, say, a period is added in front of the newline in the string, ".\!n", the newline is recognized:

y = 200;.
---
y = 200;

[#2 · Accepted solution]

Hi @SteveTerry - It does look like <<Set Display Width() is inconsistent.  The data table does not process the expression argument, but the data table view does.  One way to handle JSL messages like this is to force evaluation of the argument before the message is sent:

Eval(EvalExpr(col << Set Display Width( Expr(x) )));

We will look at fixing the evaluation in a future release.

For the newline issue, I would suggest trying "\!N" rather than "\!n".  The former will insert a line break that is dependent on the host environment, while the latter is a specific "newline" character.  Your example on my Mac seems to work without the change, but I'm not sure if this might be dependent on system settings.

[#3]

Thanks for the workaround, @danschikore.  On the solitary "\!n" issue, "\!N" didn't make a difference -- (and "\!n" has always worked well on a Mac).  A colleague has also confirmed this behavior (on 16.1).  What is the best way to report it to the JMP team?

[#4]

Hi @SteveTerry  - please report the newline issue to support@jmp.com.  I don't know why I didn't see the problem on my Mac, but they may be able to do some additional testing and create an issue that development can track if necessary.