JSL und EinstellungenHi,
Hintergrund: Kürzlich hatten wir einen Run-In bei einem unserer Add-Ins, bei dem ein Benutzer eine Standardplattformeinstellung geändert hatte, die unser Add-In nicht ausdrücklich überschrieb. In diesem Fall war es die Einstellung „Modelldialog“ -> „Dialog offen lassen“, und das Ergebnis war, dass sich eine große Anzahl von Fenstern „Modell anpassen“ öffnete (da das fragliche Add-In mehrere Modelle erstellte). Dies wurde leicht gelöst, indem die Option Keep dialog open(0) in den Fit Model-Aufrufen in unserem Skript explizit gesetzt wurde.
Gelegenheit: Ich möchte wirklich nicht jede mögliche Option aufzählen, die jemand hypothetisch auf einer Plattform ändern KÖNNTE. Einige Plattformen haben eine große Anzahl von Optionen in den Einstellungen. Ich bin auf etwas namens Ignore Platform Preferences gestoßen, das hypothetisch hinzugefügt werden könnte, aber diese Zeile muss immer noch wiederholt in jeden JSL-Plattformaufruf eingegeben werden. Gibt es einen übergreifenden Aufruf, der am Anfang eines Skripts ausgeführt werden kann, vielleicht ähnlich wie „Names Default to Here“, aber stattdessen „Use Default Preferences Here“ oder so ähnlich? Die Systemeinstellungen werden also überhaupt nicht berührt, aber wir wissen genau, welches Verhalten zu erwarten ist, wenn ein Add-In ausgeführt wird? Ich denke, diese Option ist basierend auf nicht verfügbar diese Diskussion .
Im Scripting-Index und in der JMP-Hilfe ist auch unklar, ob die Meldung Ignore Platform Preferences JMP einfach dazu zwingt, die Plattformstandardwerte zu verwenden, oder ob es etwas anderes tut (z. B. davon ausgeht, dass alle Einstellungen deaktiviert sind?). Irgendwelche Erkenntnisse hier?
Vielen Dank,
Michael
Re: JSL und EinstellungenDas wäre eine nette Sache, vielleicht auf die Wunschliste setzen.
Der drakonische Ansatz ist ziemlich effektiv. Wenn ich praktisches Training mache, verwende ich so etwas in einem Setup-Skript.
Es macht mich wahnsinnig, wenn Leute auftauchen und verrückte Vorlieben haben, und sich dann beschweren, dass die Kursbeispiele nicht so aussehen, wie sie auf dem Bildschirm zu sehen sind.
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 und EinstellungenIch bin kein Fan davon. Ich schreibe nicht absichtlich fehlerhaften Code, aber es kommt gelegentlich vor, dass sich ein Benutzer eine Kombination von Eingaben ausdenkt, die ich nicht auffange/auffange, was dazu führen kann, dass ein Add-In während der Ausführung einen Fehler ausgibt. In diesem Fall werden die beim Start des Add-Ins erfassten Einstellungen nicht zurückgesetzt. Ich würde einen einfachen einzeiligen JMP-Befehl bevorzugen (ähnlich wie wir Variablen in Namespaces steuern), der dies lokal für das ausgeführte Skript tun würde. Ich schätze, man könnte den gesamten Add-In-Code in einen Versuch stecken, aber das vereitelt den Zweck der Fehlererkennung ...
Re: JSL und EinstellungenDies wird ein wenig invasiv, aber für ein massiv bereitgestelltes Add-In für kreative JMP-Anwender könnte dies eine Option sein.
Am Anfang Ihres Skripts können Sie die Einstellungen abrufen und speichern.
Verwenden Sie dann Set-Einstellungen, um alle Einstellungen als Standard zu erzwingen, oder was Sie möchten.
Führen Sie Ihr Skript aus und verwenden Sie am Ende die festgelegten Einstellungen, um die Einstellungen wiederherzustellen, die Sie am Anfang erfasst haben.
Wenn Sie die Vorlieben einer Person auslöschen, wird sie ein wenig gereizt, also achten Sie darauf, sie zurückzusetzen, wenn Sie sich dafür entscheiden.
