460192_en-US

liliconcom

Preference vs Add-in

Hi Folks,
I got a question from the biggest customer in Korea.
Not sure who to discuss with, so I am writing here.

Situation
1) JMP users change the Default of Preferences according to their preferences.
2) They use add-ins a lot to use for common analysis of multiple employees
3) Sometimes, add-ins do not work properly due to differences in personal preference settings.

Their Needs
1) Please let Add-in(Script) take precedence over personal preference.
2) Or, is there any way to check the difference with personal preference settings when installing Add-ins?

Looking forward to sharing your ideas.
Ikju

Re: Preference vs Add-in

Hi Ikju

I have had company’s use the preference manager to align employees preferences. This will not solve step 1 in your situation but it will ensure that the preferences are setup correctly for the Add-ins.

Here is a link to the preference manager: https://community.jmp.com/t5/JMP-Add-Ins/Preferences-Manager-with-import-export/ta-p/85117

Hope it helps.

Best

Christian

Re: Preference vs Add-in

I haven't seen the Preference Manager up close, but it must rely on the fact that (via JSL) it's easy to get all the preferences, persist them (in the current session, or to disk), and then reinstate them. So in more 'corporate', multi-user settings, exploiting this is definitely a best practice to help[ to make sure things don't break.

So you could put this burden on all the scripts that are in the add-in, and then the users don't even know what's happening and can have any preferences they like. Implementing this would just require that those who write add-ins use a template that has a small block of code at the start and at the end of each script. Additionally, you can set things up so that the script editor automatically starts up with this template code. 

Re: Preference vs Add-in

Thats a cool idea Ian. It would proberply be the same script that could be added to the start and end of each Add-In making this a one time assignment. 

to Ikju: If you can get your customers to post the question on how to achive Ians idea, I am certain a helpful someone would answer him there. 

Re: Preference vs Add-in

Not sure about this, unfortunately: 'It would probably be the same script that could be added to the start and end of each Add-In making this a one time assignment'. If the add-in had, say two menu options (scripts), a user could use one, do something else, then use another. So I think it has to be at the script level. But the 'template' idea helps out here.

Re: Preference vs Add-in

Our JMP training for scripting identifies many steps of 'defensive scripting' including identifying dependence on preferences. Then the script should save preferences, modify them to suit its needs, and then restore.

It is more work for the person writing the script, but actually not much more. The user is happy and the editor is happy. Win-win!

Re: Preference vs Add-in

I feel that the approach suggested by Ian would make more sense than using company wide preferences. Where I have seen the later implemented, I have heard frustration from regular JMP users who want to use their own preferences.

Re: Preference vs Add-in

The Ignore Platform Preferences() option in platform launches should cause the platform to launch with the default options.

From the Scripting Index:

Names Default To Here( 1 );
dt = Open( "$SAMPLE_DATA/Big Class.jmp" );
dt << Bivariate(
 Ignore Platform Preferences( 1 ),
 Y( :height ),
 X( :weight ),
 Action(
  Distribution(
   Y( :height, :weight ),
   Histograms Only
  )
 )
);