¿Usas las preferencias?A través de Archivo/Preferencias, puede cambiar la configuración estándar de Jmp.
Muy bueno para ajustar Jmp a tus necesidades.:)
Pero encontré un problema sutil, en combinación con la funcionalidad para generar automáticamente código JSL (guardar en script, registro avanzado, paneles, registro, generador de flujo de trabajo...)
El siguiente código cambia las preferencias, así que piénselo dos veces si quiere probarlo.
La historia:
Un usuario ajusta algunas configuraciones (Conmutador condicional y de columnas Conservar configuración de eje) a través de Archivo/Preferencias
- Luego genera un informe con la configuración predeterminada (lo ha hecho manualmente, no hay posibilidad de generar el código a través del registro mejorado):
Names Default to Here(1);
dt = Open( "$SAMPLE_DATA/Big Class.jmp" );
Set Preferences(
Data Filter Conditional( 1 ),
Column Switcher Retain Axis Setting( 1 )
);
Graph Builder(
Variables( X( :height ), Y( :weight ), Overlay( :sex ) ),
Elements( Points( X, Y, Legend( 1 ) ), Smoother( X, Y, Legend( 2 ) ) ),
Local Data Filter(
Conditional(0),
Add Filter(
columns( :sex, :name )
)
),
Column Switcher( :weight, {:age, :weight}, Retain Axis Settings( 0 ) )
)Luego ajusta el informe de forma interactiva a través de la GUI y guarda el script (utilizando la funcionalidad de registro mejorada de JMP).
El script generado se verá así:
Graph Builder(
Variables( X( :height ), Y( :weight ), Overlay( :sex ) ),
Elements( Points( X, Y, Legend( 1 ) ), Smoother( X, Y, Legend( 2 ) ) ),
Local Data Filter(
Add Filter(
columns( :sex, :name ),
Display( :name, N Items( 15 ), Find( Set Text( "" ) ) )
)
),
Column Switcher( :weight, {:age, :weight} )
)Tenga en cuenta:
Condicional (0) -> ¡ eliminado automáticamente!
Retain Axis Settings( 0 ) -> removed automatically!
The finding:
Default settings are automatically removed from the code - "ya que no tendrán efecto para un sistema estándar".
Lo mismo sucede si los usos utilizan el Informe dentro de un Panel (!): no se agregarán las configuraciones predeterminadas.
Ahora, el usuario ejecuta el código nuevamente; imagine cómo se verá el Informe...
Puedo entender por qué es así: no es un error, es una característica interesante que Jmp limpia automáticamente el código para eliminar líneas innecesarias.
Pero en combinación con un usuario que se atreve a cambiar la configuración de las preferencias, definitivamente actúa como un error: ¡un error grave!
Mi solución actual: simplemente cambie las preferencias donde esté seguro de que NUNCA (!!!) usará la configuración predeterminada.
Esta regla es perjudicial, especialmente en los casos en los que uso la configuración ajustada en el 99% de los casos, y el 1% es la configuración predeterminada.
Entonces, la regla no me permite ajustar las preferencias. Me veo obligado a vivir con la configuración predeterminada y tengo que ajustarla manualmente en el 99% de los casos.
¿Existe una solución mejor? ¿Cómo resuelve USTED este problema en la vida laboral diaria?
Automatización y secuencias de comandosRe: ¿Usas las preferencias?Según el soporte de Jmp (TS-00061254):
esto está funcionando según lo diseñado.
Entonces:
Con configuraciones CAMBIADAS en las preferencias, un usuario pierde la oportunidad de usar Dashboard Builder para generar paneles que abren plataformas en su sistema con configuraciones ESTÁNDAR 
Solución alterna:
Abra el script fuente del Panel y agregue manualmente el código para la configuración estándar.
Re: ¿Usas las preferencias?El soporte de Jmp sugirió escribir una publicación para la lista de deseos.
Aquí lo tienes:
Configuración modificada en Preferencias -> solucionar el problema
Re: ¿Usas las preferencias?@hogi , probé tu código y veo a qué te refieres. después de cambiar la preferencia para el filtro y el conmutador de columnas y luego usar opciones que coincidan con los valores predeterminados de preferencia (no con la preferencia actual), se genera un informe. Luego, al guardar el script no se molesta en incluir las configuraciones que coincidan con los valores predeterminados para que el script no reproduzca su informe. ¿Y está interpretando que (¿y el soporte afirmó?) que esto es intencional para limpiar todo lo que no sería necesario si hubiera dejado su sistema con las preferencias predeterminadas ? es decir. ¿Condicional (0) no incluido porque no sería necesario si tuviera la preferencia predeterminada aunque sea relevante actualmente?
Pero eso no es lo que veo en las preferencias del propio Graph Builder. Si cambio mi preferencia de Graph Builder para que no muestre el título, por ejemplo, y luego creo un generador de gráficos y pido (ya sea en JSL o manualmente después del hecho) que muestre el título, obtengo un script con showtitle(1) incluido. . El tipo de configuración redundante que podría verse como conditional(0), una que no necesita si tiene preferencias predeterminadas. Creo que lo que veo en general es que no incluye configuraciones que no son necesarias con las preferencias que tengo actualmente. Ahora que desactivé mostrar título en mis Preferencias, si solicito showtitle(0) no me molesta mencionarlo en el script.
Entonces, parecen 2 problemas: (1) a uno le gustaría capturar todas las opciones independientemente de si coinciden con sus preferencias o no y (2) me parece que las opciones de tipo "obtener secuencia de comandos" tratan el filtro y el conmutador de columnas de manera diferente que tratan el resto de la plataforma. no le proporciona una secuencia de comandos que funcione con sus preferencias actuales como lo hace con las preferencias de plataforma. Puedo apreciar que eliminar cláusulas innecesarias es intencional, pero no que la definición de innecesario sea diferente para filter que para settitle().
2. Me parece un error que esté eliminando cosas no por ser iguales a las preferencias actuales sino por ser iguales a las predeterminadas.
1. Parece que es similar al elemento de mi lista de deseos sobre Usar el separador de miles ( interrogar Usar el separador de miles usando JSL - Comunidad de usuarios JMP ), donde tal vez una solución podría ser una opción para devolver un script más detallado, uno que no No elimine nada que sea simplemente "igual que las preferencias".
Genial, ahora mis preferencias están todas arruinadas... 
Re: ¿Usas las preferencias?100% de acuerdo 
especialmente el
- Puedo apreciar que eliminar cláusulas innecesarias es intencional.
- pero no es que la definición de innecesario sea diferente para filter que para settitle().
Hay muchas más configuraciones que se comportan como el conmutador de columnas y el filtro de datos, incluso configuraciones que afectan directamente a Graph Builder:
Si cambia la configuración predeterminada para Estadísticas de resumen, Espaciado de gráficos, etc. en las preferencias, todo su código JSL generado automáticamente tendrá una sección con:
Estadística resumida ("Mediana"),
Espaciado de gráficos (4)
... hasta que intentas restablecerlo a los valores predeterminados. Si selecciona la configuración predeterminada, la configuración no aparecerá en el script JSL generado, con un problema similar al Condicional: no hay posibilidad de generar un código JSL automáticamente con la configuración predeterminada.
Re: ¿Usas las preferencias?Como hay mucho espacio entre
- eliminar cláusulas "innecesarias"
- escribir todas las configuraciones de manera que el resultado sea el mismo en CUALQUIER sistema, independientemente de la configuración actual.
Entonces, ¿qué tal un detallado (0), detallado (0.3), detallado (0.5), detallado (0.7), detallado (1)?
- 0: elimina todo el código "innecesario" como ahora - modo de compatibilidad
- 0.3: genera todo el código JSL necesario para generar el mismo resultado en este sistema. [soluciona el problema con el condicional]
- 0.5: genera todo el código JSL necesario para generar el mismo resultado en un sistema predeterminado . [soluciona el problema con la configuración de gradiente definida por el usuario]
- 0,7: según los gráficos/informes generados de los últimos 6 meses, incluye todas las configuraciones que se cambiaron >=3 veces. Genere un código que sea robusto frente a todas las configuraciones.
- 1: código JSL robusto frente a cualquier configuración en las preferencias.
0.7: súper útil - ¡mi favorito!
- ¿A quién le importan 5 líneas adicionales de código? - Si generarán un resultado más sólido en cualquier sistema de sus colegas.
- ¿Con qué frecuencia generaste una concatenación y luego te preguntaste sobre la redacción exacta de anexar a la tabla principal (1) ?
Re: ¿Utilizas las preferencias?Un compañero encontró un buen ejemplo que muestra un error similar causado por un conflicto de diferentes configuraciones en Graph Builder:
Un usuario no puede definir una configuración como ESTÁNDAR si en un nivel superior se aplica una configuración no estándar.
En el Generador de gráficos, hay un control para la configuración de los ejes, y dentro de la configuración de los ejes hay un control para las líneas de referencia.
Las líneas de referencia parecen heredar la configuración de fuente de la configuración del eje.
Y la única forma de "eliminar" una configuración heredada es: aplicar una configuración no estándar y, de ese modo, sobrescribir la configuración heredada.
Difícil de explicar, pero fácil de "experimentar":
El texto de la etiqueta "estándar" debería ser "estándar", no en negrita. Ejecuta el código y prueba suerte.

dt = new table("test", new column ("X"));
Graph Builder(
Size( 469, 260 ),
Graph Spacing( 4 ),
Variables( X( :X ) ),
Elements( Points( X, Legend( 2 ) ) ),
SendToReport(
Dispatch( {}, {:X}, ScaleBox,
{Min( 0 ), Max( 50 ), Inc( 10 ), Minor Ticks( 1 ),
Add Ref Line(
20,
"Solid",
"Black",
"italic",
1,
1,
Label Settings( {Set Font Style( "Italic" )} )
), Add Ref Line( 30, "Solid", "Black", "standard", 1 ),
Label Row( Set Font Style( "Bold" ) )}
)
)
);
Un problema similar surge con las preferencias y la configuración personalizada. Si una configuración en las preferencias difiere de la configuración estándar, el usuario se ve obligado a usarla. Es prácticamente imposible forzar que un informe utilice la configuración estándar, sobre todo después de haberlo modificado y guardado el script. En ese caso, la opción de "restablecer a la configuración estándar" deja de ser viable.
Peor aún con las líneas de referencia: ¿no hay ninguna posibilidad de restablecer la configuración?
Re: ¿Utilizas las preferencias?Existe un conflicto similar con la configuración de marcadores y colores en el creador de gráficos:
Existen diferentes formas de ajustar la configuración de los marcadores:
- estado de fila para filas individuales
- Configuración de marcadores a través del menú de leyenda en el Creador de gráficos
- Configuración de marcadores globales en el menú de preferencias
[Lo que no es posible en JMP 19 es controlar la configuración de los marcadores mediante una propiedad de columna: "Marcadores de valor " -> ¡Siga el enlace y vote!]
Los problemas:
La configuración a través del menú de leyenda anula la configuración de los estados de fila .
La excepción es el marcador predeterminado . Si se selecciona el marcador estándar en el menú de la leyenda, JMP asume que el usuario desea restablecer la configuración, por lo que el comando se ignora y se vuelve a activar la configuración del marcador de los estados de fila. La única forma de anular los estados de fila es asignar un marcador especial . No es posible invalidar los estados de fila con el marcador predeterminado.
Similarly, settings via the legend menu override the settings in the preferencias.
The exception is again the default marker. If the setting is switched to the standard marker, JMP assumes that the user wants to 'reset' the settings, so the preferences will be activated again. Consequently, one must assign a marcador no estándar to override the settings in the preferences. It is not possible to overrule marker settings from the preferences with a 'default marker': In the vide, the user selects "dot" - and Graph Builder uses "FilledSquare" (from the preferences).
My recommendation: don't touch the marker setting in the preferences!!
Lo mismo se aplica a los colores :
No es posible cambiar el color del estado de una fila por el negro (el color predeterminado).
Names Default to Here(1);
dt = Open( "$SAMPLE_DATA/Big Class.jmp" );
Graph Builder(
Size( 437, 413 ),
Graph Spacing( 4 ),
Variables( X( :height ), Y( :weight ), Overlay( :sex ) ),
Elements( Points( X, Y, Legend( 1 ) ), Smoother( X, Y, Legend( 2 ) ) ),
SendToReport(
Dispatch( {}, "Graph Builder", FrameBox, {Marker Size( 10 ), Marker Drawing Mode( "Outlined" )} ),
Dispatch( {}, "400", LegendBox, {Legend Position( {1, [2, 3], 2, [0, 1]} )} )
)
);
wait(2);
// Set selected rows' markers
dt << Clear Select << Select Rows( [5] ) << Markers( "Circle" );
wait(2);
// please go to the preferences and set it back after running this code:
Set Preferences( Graph Marker( "FilledSquare" ));