260256_en-US

liliconcom

JSL and Preferences

Hi,

 

Background: Recently we had a run-in on one of our add-ins where a user had changed a default platform preference that our add-in didn't specifically override. In this case, it was the Model Dialog -> Keep Dialog Open preference and the result was a large number of Fit Model windows opening up (since the add-in in question was building multiple models). This was easily resolved by explicitly setting the option Keep dialog open(0) in the Fit Model calls in our script.

 

Opportunity: I really don't want to spell out every possible option someone COULD hypothetically change in a platform. Some platforms have a huge number of options in the preferences. I ran across something called Ignore Platform Preferences that could hypothetically be added, but that line still has to repeatedly be typed in to every JSL platform call. Is there some overarching call that can be run at the start of a script, maybe similar to Names Default to Here, but instead have it be Use Default Preferences Here or something like that? So the system preferences don't get touched at all, but we know exactly what behavior to expect when an add-in runs? I'm thinking this option isn't available based on this discussion.

 

It's also unclear in the Scripting Index and the JMP Help as to whether the Ignore Platform Preferences message simply forces JMP to use the platform defaults, or if it is doing something else (like assuming all preferences unchecked?). Any insights here?

 

Thanks,

 

Michael

Re: JSL and Preferences

that would be a nice thing to have, maybe add it to the wish list.

 

The draconian approach is pretty effective.  When I'm doing hands on training I use something like this in a set up script.

It drives me nuts when people show up and have crazy preferences set, and then they complain that the course examples don't look like what they see on the screen.

 

old=getpreferences();
set old=expr(set preferences());
for(i=1, i<= narg(old), i++,
 insert into(set old, arg(old,i)););
//you script here
//including setting all the preferences you want to control
// at the end restore
setold;

 

Re: JSL and Preferences

I'm not a fan of this. I don't intentionally write buggy code, but it does happen occasionally that a user dreams up a combination of inputs that I don't trap/catch that can cause an Add-in to throw an error during execution. If this happens, the preferences that are captured at the start of the Add-in don't get reset. I would prefer a simple one-line JMP command (similar to how we control variables into namespaces) that would do this local to the script that is running. I guess one could put the entire Add-in code into a Try, but that defeats the purpose of error catching...

Re: JSL and Preferences

This gets a little invasive, but for a massively deployed add-in for creative JMPers, it might be an option.

 

At the beginning of your script you could get the preferences, and store it.

Then use set preferences to force all preferences to be default, or what every you like.

Run your script, then at the end use set preferences to restore the preferences you captured at the beginning.

 

If you wipe out someone's preferences, they get a little testy, so be careful to set them back if you choose to do this.