260256_it-IT

liliconcom

JSL e Preferenze

Ciao,

 

Sfondo: recentemente abbiamo avuto un incontro con uno dei nostri componenti aggiuntivi in cui un utente aveva modificato una preferenza di piattaforma predefinita che il nostro componente aggiuntivo non ha sovrascritto in modo specifico. In questo caso, si trattava della preferenza Finestra di dialogo Modello -> Mantieni finestra di dialogo aperta e il risultato è stato l'apertura di un gran numero di finestre Adatta modello (poiché il componente aggiuntivo in questione stava creando più modelli). Questo problema è stato facilmente risolto impostando esplicitamente l'opzione Mantieni la finestra di dialogo aperta(0) nelle chiamate Fit Model nel nostro script.

 

Opportunità: non voglio davvero precisare tutte le opzioni possibili che qualcuno POTREBBE ipoteticamente cambiare in una piattaforma. Alcune piattaforme hanno un numero enorme di opzioni nelle preferenze. Mi sono imbattuto in qualcosa chiamato Ignora Platform Preferences che potrebbe ipoteticamente essere aggiunto, ma quella riga deve ancora essere digitata ripetutamente in ogni chiamata della piattaforma JSL. C'è qualche chiamata generale che può essere eseguita all'inizio di uno script, magari simile a Nomi predefiniti qui, ma invece è Usa preferenze predefinite qui o qualcosa del genere? Quindi le preferenze di sistema non vengono affatto toccate, ma sappiamo esattamente quale comportamento aspettarci quando viene eseguito un componente aggiuntivo? Sto pensando che questa opzione non è disponibile in base a questa discussione .

 

Non è inoltre chiaro nell'indice di scripting e nella guida di JMP se il messaggio Ignora Platform Preferences costringe semplicemente JMP a utilizzare le impostazioni predefinite della piattaforma o se sta facendo qualcos'altro (come presumere che tutte le preferenze siano deselezionate?). Qualche spunto qui?

 

Grazie,

 

Michael

Ri: JSL e Preferenze

sarebbe una bella cosa da avere, magari aggiungerlo alla lista dei desideri.

 

L'approccio draconiano è piuttosto efficace. Quando mi alleno in modo pratico, uso qualcosa di simile in uno script di configurazione.

Mi fa impazzire quando le persone si fanno vedere e hanno delle preferenze folli, e poi si lamentano del fatto che gli esempi dei corsi non assomiglino a quello che vedono sullo schermo.

 

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;

 

Ri: JSL e Preferenze

Non sono un fan di questo. Non scrivo intenzionalmente codice difettoso, ma occasionalmente capita che un utente sogni una combinazione di input che non intercetto/cattura che può causare un errore durante l'esecuzione di un componente aggiuntivo. In questo caso, le preferenze acquisite all'inizio del componente aggiuntivo non vengono reimpostate. Preferirei un semplice comando JMP a una riga (simile a come controlliamo le variabili negli spazi dei nomi) che lo farebbe localmente allo script in esecuzione. Immagino che si possa inserire l'intero codice del componente aggiuntivo in una prova, ma ciò vanifica lo scopo della cattura degli errori ...

Ri: JSL e Preferenze

Questo diventa un po' invasivo, ma per un componente aggiuntivo distribuito in modo massiccio per JMPer creativi, potrebbe essere un'opzione.

 

All'inizio del tuo script potresti ottenere le preferenze e memorizzarlo.

Quindi usa imposta le preferenze per forzare tutte le preferenze a essere predefinite o ciò che ti piace.

Esegui il tuo script, quindi alla fine usa imposta le preferenze per ripristinare le preferenze che hai catturato all'inizio.

 

Se cancelli le preferenze di qualcuno, diventa un po' irritabile, quindi fai attenzione a reimpostarle se scegli di farlo.