topic Re: Do you use the preferences? in Discussions

Do you use the preferences?

hogi — Thu, 18 Jul 2024 09:34:47 GMT

Via File/Preferences, you can change the standard settings of Jmp.

Very cool to adjust Jmp to your needs :)

But I found a subtle issue - in combination with the functionality to automatically generate JSL code (save to script, advanced log, Dashboards, log, Workflow Builder ...)

The below code changes the preferences, so - please think twice if you want to try it .

The story:

A user adjusts some settings (Conditional & Column Switcher Retain Axis Setting) via File/Preferences
- an then generates a report with the default setting (he has do this manually, no chance to generate the code via enhanced log):

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 ) )
)

Then he adjusts the Report interactively via the GUI and saves the script (using the enhanced log functionality of JMP).

The generated script will look like this:

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} )
)

Please note:
Conditional(0) -> removed automatically!

Retain Axis Settings( 0 ) -> removed automatically!

The finding:
Default settings are automatically removed from the code - "as they won't have an effect for a standard system".

Same happens if the uses uses the Report inside a Dashboard (!) - default settings won't be added.

Now, the user runs the code again - imagine how the Report will look like ...

I can understand why it is like this - it is no bug it's a cool Feature that Jmp automatically cleans code to remove unnecessary lines.

But in combination with a user who dares to change settings in the preferences it definitely acts like a bug - a severe bug!

My current workaround: Just change preferences where you are sure that you won't EVER (!!!) use the default setting.
This rule hurts - especially for cases where I use the adjusted setting in 99% of the cases - and 1% the default setting.
Then, the rule doesn't allow me to adjust the preferences. I am forced lo live with the default setting and have to manually adjust the setting in 99% of the cases.

Is there a better solution - how do YOU solve this issue in daily work life?

Re: Do you use the preferences?

hogi — Wed, 18 Oct 2023 12:42:55 GMT

Accoring to Jmp support (TS-00061254):

this is working as designed.

So:
With CHANGED settings in the preferences, a user loses the chance to use Dashboard Builder to generate Dashboards which open platforms on his system with STANDARD settings :(

Workaround:

Open the source script of the Dashboard and manually add the code for the standard setting.

Re: Do you use the preferences?

hogi — Wed, 18 Oct 2023 12:49:23 GMT

Jmp support suggested to write a post for the wish list.

Here it is:

Re: Do you use the preferences?

hardner — Thu, 21 Mar 2024 21:05:56 GMT

@hogi, I tried your code and see what you mean. having changed the preference for the filter and the column switcher and then using choices that match the preference defaults (not the current preference) you make a report. Then saving script doesn't bother to include the settings that match the defaults so the script doesn't reproduce your report. And you are interpreting that (and support claimed?) that this is intentional to clean out anything that wouldn't be needed if you had left your system at the default preferences? ie. Conditional(0) not included because it wouldn't be needed if you had default preference even though it's relevant currently?

But that is not what I see for the preferences for Graph Builder itself. If I change my Preference for Graph Builder to not show title, for example, and then I make a graph builder and ask (either in JSL or manually after the fact) to show title, I do get a script with showtitle(1) included. The kind of redundant setting that conditional(0) could be seen as, one you don't need if you have default preferences. I think what I see generally is it does not include settings that aren't needed with the preferences I have currently. Now that I turned off showing title in my Preferences, if I ask for showtitle(0) it doesn't bother to mention that in the script.

So, seems like 2 issues: (1) one might like to capture all the options regardless of whether they match your preferences or not and (2) the "get script" type options appear to me to treat the filter and col switcher differently than they treat the rest of the platform. it fails to give you a script that works with your current preferences like it does for platform preferences. I can appreciate that removing unnecessary clauses is intentional but not that the definition of unnecessary is different for filter than for settitle().?

2. seems like a bug to me that it's eliminating things not for being same as current preferences but for being same as defaults.

1. seems like it is indeed similar to my wish list item about Use Thousands Separator (interrogate Use Thousands Separator using JSL - JMP User Community), where maybe one solution could be an option for a more verbose script to be returned, one that doesn't eliminate anything as just "same as preferences".

Great, now my preferences are all screwed up... :)

Re: Do you use the preferences?

hogi — Thu, 21 Mar 2024 21:44:42 GMT

100% agree :)

especially the
- I can appreciate that removing unnecessary clauses is intentional

- but not that the definition of unnecessary is different for filter than for settitle().?

there are many more settings which behave like the column switcher and the data filter - even settings which directly affect Graph Builder:

If you change the default settings for Summary Statistics, Graph Spacing etc. in the preferences, all your automatically generated JSL code will have a section with:
Summary Statistic( "Median" ),
Graph Spacing( 4 )

... till you try to set it back to the default values. If you hit the default setting, the settings will not show up in the generated JSL script - with a similar issue like Conditional: no chance to generate a JSL code automatically with the default settings.

Re: Do you use the preferences?

hogi — Thu, 18 Jul 2024 09:46:34 GMT

As there is so much room between
- removing "unnecessary" clauses

- writing all settings such that the result is the same on ANY system - independent of the current settings.

So, how about a verbose(0), verbose(0.3), verbose (0.5), verbose(0.7), verbose(1)

- 0: strip all the "unneccessary" code like now - compatibility mode
- 0.3: generate all the JSL code that is necessary to generate the same result on this system. [fixes the issue with Conditional]
- 0.5: generate all the JSL code that is necessary to generate the same result on a default system. [fixes the issue with the user defined gradient setting]

- 0.7: based on the generated graphs/ reports of the last 6 months, include all settings which are changed >=3 times. Generate a code which is robust against all the settings.

- 1: JSL code robust against any settings in the preferences.

0.7: super useful - my favorite!
- who cares about 5 additional lines of code - if they will generate a more robust result on any system of your colleages.
- how often did you generate a concatenate and wondered later about the exact wording of append to main table(1)?

Re: Do you use the preferences?

hogi — Thu, 13 Nov 2025 13:58:15 GMT

A colleague found a nice example which shows a similar bug caused by a conflict of different settings in Graph Builder:
A user is not allowed to define a setting to be STANDARD if on a higher level a non-standard setting is applied.

In Graph Builder, there is a control for the axis settings - and within the axis settings there is a control for the reference lines.
The reference lines seem to inherit the font settings from the axis settings.
And the only way to "delete" an inherited setting is: apply a non-standard setting and thereby overwrite the inherited setting.
Difficult to explain - but easy to "experience":
The text of the label "standard" should be "standard", not Bold - run the code and try your luck:

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" ) )}
		)
	)
);

A similar issue arises with preferences and custom settings. Once a setting in the preferences differs from the standard setting, the user is forced to use this setting. There is little chance of forcing a report to use the standard settings, especially after the report has been changed and the script saved. This is the time where "reset to standard" gets lost.

Even worse with reference lines: no chance to reset the setting at all?

Re: Do you use the preferences?

hogi — Fri, 14 Nov 2025 20:20:58 GMT

A similar conflict exists for Marker and color settings in Graph builder:

There are different ways to adjust the settings for markers:

row state for individual rows
marker settings via the legend menu in Graph Builder
global marker settings in the preferences menu

[what is not possible in JMP 19 is controlling the marker settings via a " -> please follow the link and vote! ]

The issues:

Settings via the legend menu override the settings from the row states.
The exception is the default marker. If the standard marker is selected in the legend menu, JMP assumes that the user wants to 'reset' the settings, so the command will be "ignored" and the marker setting from the row states gets active again. The only way to 'fight' against row states is to assign a special marker. It is not possible to overrule row states with the 'default marker'.

Similarly, settings via the legend menu override the settings in the preferences.
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 non-standard marker 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!!

The same applies to colors:
it is not possible to override a row state color with black (the default color).

(view in My Videos)

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" ));