En essayant de définir la largeur d'affichage d'une colonne dans JSL à l'aide de JMP 16.2.0 (MacOS), je constate plusieurs problèmes que je n'ai pas vus avec JMP 15.
1. Le Définir la largeur d'affichage La fonction semble fonctionner en deux modes, selon la façon dont elle est utilisée. S'il est appelé avec une valeur arg codée en dur, il semble être permanent.
col = Column("SN");
col << Set Display Width( 200 );Cependant, s'il est appelé avec un argument var, il s'affiche comme souhaité, mais ne semble pas être enregistré avec le fichier. (Ou, du moins, pas enregistré comme prévu.)
x = 100;
col << Set Display Width( x );
Dans ce dernier cas, si le fichier est enregistré puis rouvert, il s'affiche avec une largeur de 200, (vraisemblablement, après avoir exécuté l'ancien code). Ainsi, le 200 persiste à travers un fichier-save-close-and-reopen, mais pas le 100.
Encore plus étrange, si j'ouvre la table avec JMP 15, il rend la largeur de 100, (et un y = col << Obtenir la largeur d'affichage() l'instruction le confirme). Mais ensuite, revenir en arrière et ouvrir avec JMP 16 rend une largeur de 200. Cela suggère qu'en effet, les deux valeurs sont enregistrées avec le fichier, et JMP a ajouté un nouveau mode à l'attribut de largeur de colonne dans JMP 16. Pour référence, le fichier joint présente le problème.
2. Si le Définir la largeur d'affichage() fonction est la dernière fonction du script JSL, et elle utilise un argument variable, elle manifeste un Inscriptible[] erreur, et l'opération ne semble pas avoir lieu. Cependant, si une valeur codée en dur est donnée, tout semble bien fonctionner (et la valeur définie est affichée dans le journal). Existe-t-il peut-être une nouvelle exigence de syntaxe pour cette fonction ou pour les terminaisons de script JSL pour JMP 16 ? Je remarque que ce comportement ne se produit pas avec JMP 15.
3. Un peu sans rapport, mais découvert en essayant de comprendre cela, avec JMP 16, une chaîne avec un caractère de nouvelle ligne semble nécessiter au moins un autre caractère non blanc, sinon il semble être ignoré. Je ne sais pas s'il s'agit d'un changement de conception ou d'un oubli SQA.
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);Production:
y = 200;---
y = 200;
Si, par exemple, un point est ajouté devant la nouvelle ligne dans la chaîne, ".\!n" , la nouvelle ligne est reconnue :
y = 200;.
---
y = 200;
Salut @SteveTerry - Il semble que <
Eval(EvalExpr(col << Set Display Width( Expr(x) )));
Nous chercherons à corriger l'évaluation dans une prochaine version.
Pour le problème de nouvelle ligne, je suggérerais d'essayer "\!N" plutôt que "\!n".Le premier insère un saut de ligne qui dépend de l'environnement hôte, tandis que le second est un caractère "nouvelle ligne" spécifique.Votre exemple sur mon Mac semble fonctionner sans le changement, mais je ne sais pas si cela peut dépendre des paramètres système.
Merci pour la solution de contournement, @danschikore . Sur le problème solitaire "\!n", "\!N" n'a pas fait de différence -- (et "\!n" a toujours bien fonctionné sur un Mac). Un collègue a également confirmé ce comportement (sur 16.1). Quelle est la meilleure façon de le signaler à l'équipe JMP ?
