686348_de-DE

liliconcom

Nutzt du die Voreinstellungen?

Über Datei/Einstellungen können Sie die Standardeinstellungen von Jmp ändern.

Sehr cool, Jmp an deine Bedürfnisse anzupassen:)

Aber ich habe ein subtiles Problem gefunden – in Kombination mit der Funktion zum automatischen Generieren von JSL-Code (In Skript speichern, erweitertes Protokoll, Dashboards, Protokoll, Workflow Builder …)

Der folgende Code ändert die Einstellungen. Überlegen Sie es sich also bitte zweimal, ob Sie ihn ausprobieren möchten.

Die Geschichte:

Ein Benutzer passt einige Einstellungen (Bedingter & Spaltenumschalter behält Achseneinstellung bei) über Datei/Einstellungen an
- und generiert dann einen Bericht mit der Standardeinstellung (er muss dies manuell tun, keine Möglichkeit, den Code über das erweiterte Protokoll zu generieren):

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

Anschließend passt er den Report interaktiv über die GUI an und speichert das Skript (unter Verwendung der erweiterten Protokollfunktionalität von JMP).

Das generierte Skript sieht folgendermaßen aus:

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

Bitte beachten Sie:
Conditional(0) -> automatisch entfernt!

Retain Axis Settings( 0 ) -> removed automatically!

The finding:
Default settings are automatically removed from the code - "da sie für ein Standardsystem keine Auswirkungen haben".

Dasselbe passiert, wenn der Benutzer den Bericht in einem Dashboard (!) verwendet – Standardeinstellungen werden nicht hinzugefügt.

Jetzt führt der Benutzer den Code erneut aus – stellen Sie sich vor, wie der Bericht aussehen wird …

Ich kann verstehen, warum das so ist – es ist kein Fehler, sondern eine coole Funktion, mit der Jmp Code automatisch bereinigt, um unnötige Zeilen zu entfernen.

Aber in Kombination mit einem Benutzer, der es wagt, Einstellungen in den Voreinstellungen zu ändern, verhält es sich definitiv wie ein Fehler – ein schwerwiegender Fehler!

Mein aktueller Workaround: Ändern Sie einfach die Voreinstellungen, bei denen Sie sicher sind, dass Sie NIEMALS (!!!) die Standardeinstellung verwenden werden.
Diese Regel schmerzt – insbesondere in Fällen, in denen ich in 99% der Fälle die angepasste Einstellung verwende – und in 1% die Standardeinstellung.
Dann erlaubt mir die Regel nicht, die Einstellungen anzupassen. Ich bin gezwungen, mit der Standardeinstellung zu leben und muss die Einstellungen in 99% der Fälle manuell anpassen.

Gibt es eine bessere Lösung – wie lösen SIE dieses Problem im Arbeitsalltag?

Automatisierung und SkriptingBetreff: Verwenden Sie die Einstellungen?

Laut Jmp-Unterstützung (TS-00061254):

das funktioniert wie vorgesehen.

 

Also:
Mit GEÄNDERTEN Einstellungen in den Einstellungen verliert ein Benutzer die Möglichkeit, Dashboard Builder zum Generieren von Dashboards zu verwenden, die Plattformen auf seinem System mit STANDARD-Einstellungen öffnen

 

Problemumgehung:

Öffnen Sie das Quellskript des Dashboards und fügen Sie den Code für die Standardeinstellung manuell hinzu.

Betreff: Verwenden Sie die Einstellungen?

Der Jmp-Support hat vorgeschlagen, einen Beitrag für die Wunschliste zu schreiben.

Hier ist es:
Geänderte Einstellungen in den Einstellungen -> Problem beheben

Betreff: Verwenden Sie die Einstellungen?

@hogi , ich habe deinen Code ausprobiert und sehe, was du meinst. Nachdem Sie die Voreinstellungen für den Filter und den Spaltenumschalter geändert und dann Auswahlmöglichkeiten verwendet haben, die den Voreinstellungen (nicht der aktuellen Voreinstellung) entsprechen, erstellen Sie einen Bericht. Dann macht sich das Speichern des Skripts nicht die Mühe, die Einstellungen einzuschließen, die den Standardeinstellungen entsprechen, sodass das Skript Ihren Bericht nicht reproduziert. Und Sie interpretieren das (und der Support behauptet?), dass dies beabsichtigt ist, um alles zu entfernen, was nicht benötigt würde , wenn Sie Ihr System auf den Standardeinstellungen belassen hätten ? dh. Conditional(0) nicht enthalten, da es nicht benötigt würde, wenn Sie die Standardeinstellung hätten, obwohl es derzeit relevant ist?

Aber das ist nicht das, was ich bei den Einstellungen für Graph Builder selbst sehe. Wenn ich zum Beispiel meine Einstellung für Graph Builder so ändere, dass der Titel nicht angezeigt wird, und dann einen Graph Builder erstelle und (entweder in JSL oder manuell nachträglich) frage, ob der Titel angezeigt werden soll, erhalte ich ein Skript mit showtitle(1). . Die Art von redundanter Einstellung, die „conditional(0)“ darstellen könnte, ist eine, die Sie nicht benötigen, wenn Sie Standardeinstellungen haben. Ich denke, was ich im Allgemeinen sehe, ist, dass es keine Einstellungen enthält, die mit den Einstellungen, die ich derzeit habe, nicht benötigt werden. Da ich nun die Titelanzeige in meinen Einstellungen deaktiviert habe, macht es mir nichts aus, dies im Skript zu erwähnen, wenn ich nach showtitle(0) frage.

Scheint also zwei Probleme zu haben: (1) Man möchte vielleicht alle Optionen erfassen, unabhängig davon, ob sie Ihren Vorlieben entsprechen oder nicht, und (2) die Optionen vom Typ „Skript abrufen“ scheinen mir den Filter und den Spaltenumschalter anders zu behandeln als Sie behandeln den Rest der Plattform. Es wird Ihnen kein Skript bereitgestellt, das mit Ihren aktuellen Einstellungen funktioniert, wie es bei Plattformeinstellungen der Fall ist. Ich kann verstehen, dass das Entfernen unnötiger Klauseln beabsichtigt ist, aber nicht, dass die Definition von unnötig für filter anders ist als für settitle().?

2. Es scheint mir ein Fehler zu sein, dass Dinge nicht deshalb entfernt werden, weil sie mit den aktuellen Einstellungen übereinstimmen, sondern weil sie mit den Standardeinstellungen übereinstimmen.

1. Scheint, als ob es tatsächlich meinem Wunschlisteneintrag über „Use Thousands Separator“ ( Befragung „Use Thousands Separator using JSL – JMP User Community“ ) ähnelt, wo vielleicht eine Lösung eine Option für die Rückgabe eines ausführlicheren Skripts sein könnte, eine, die dies tut Beseitigen Sie nichts als „das Gleiche wie Präferenzen“.

Großartig, jetzt sind meine Vorlieben völlig durcheinander...

Betreff: Verwenden Sie die Einstellungen?

100% Zustimmung

insbesondere das
– Ich kann verstehen, dass das Entfernen unnötiger Klauseln beabsichtigt ist

- aber nicht, dass die Definition von unnötig für Filter eine andere ist als für settitle().?

Es gibt viele weitere Einstellungen, die sich wie der Spaltenumschalter und der Datenfilter verhalten – sogar Einstellungen, die sich direkt auf Graph Builder auswirken:

Wenn Sie die Standardeinstellungen für Zusammenfassungsstatistiken, Diagrammabstände usw. in den Einstellungen ändern, enthält Ihr gesamter automatisch generierter JSL-Code einen Abschnitt mit:
Zusammenfassungsstatistik („Median“),
Diagrammabstand( 4 )

... bis Sie versuchen, es auf die Standardwerte zurückzusetzen. Wenn Sie die Standardeinstellung wählen, werden die Einstellungen nicht im generierten JSL-Skript angezeigt – mit einem ähnlichen Problem wie „Bedingt: Keine Möglichkeit, automatisch einen JSL-Code mit den Standardeinstellungen zu generieren“.

Betreff: Nutzt du die Voreinstellungen?

Da so viel Platz ist zwischen
- Streichung „unnötiger“ Klauseln

- Schreiben aller Einstellungen, sodass das Ergebnis auf JEDEM System das gleiche ist – unabhängig von den aktuellen Einstellungen.

Wie wäre es also mit verbose(0), verbose(0.3), verbose (0.5), verbose(0.7), verbose(1)?

- 0: Entfernen Sie den gesamten „unnötigen“ Code wie jetzt - Kompatibilitätsmodus
- 0.3: Generieren Sie den gesamten JSL-Code, der erforderlich ist, um auf diesem System dasselbe Ergebnis zu erzielen. [behebt das Problem mit Conditional]
- 0.5: Generieren Sie den gesamten JSL-Code, der erforderlich ist, um auf einem Standardsystem dasselbe Ergebnis zu erzielen. [behebt das Problem mit der benutzerdefinierten Gradienteneinstellung]

- 0,7: basierend auf den generierten Diagrammen/Berichten der letzten 6 Monate, alle Einstellungen einschließen, die >=3 Mal geändert wurden. Einen Code generieren, der gegenüber allen Einstellungen robust ist.

- 1: JSL-Code robust gegenüber allen Einstellungen in den Voreinstellungen.

0.7: super nützlich – mein Favorit!
– wen interessieren schon 5 zusätzliche Codezeilen, wenn sie auf einem beliebigen System Ihrer Kollegen ein robusteres Ergebnis erzeugen.
- wie oft haben Sie eine Verkettung erzeugt und sich später über den genauen Wortlaut von „An Haupttabelle anhängen (1)“ gewundert?

Betreff: Nutzen Sie die Einstellungen?

Ein Kollege hat ein gutes Beispiel gefunden, das einen ähnlichen Fehler zeigt, der durch einen Konflikt unterschiedlicher Einstellungen im Graph Builder verursacht wird:
Ein Benutzer darf eine Einstellung nicht als STANDARD definieren, wenn auf einer höheren Ebene eine nicht standardmäßige Einstellung angewendet wird.

Im Graph Builder gibt es ein Steuerelement für die Achseneinstellungen – und innerhalb der Achseneinstellungen gibt es ein Steuerelement für die Referenzlinien.
Die Referenzlinien scheinen die Schrifteinstellungen von den Achseneinstellungen zu übernehmen.
Die einzige Möglichkeit, eine geerbte Einstellung zu "löschen", besteht darin, eine nicht standardmäßige Einstellung anzuwenden und dadurch die geerbte Einstellung zu überschreiben.
Schwer zu erklären, aber leicht zu „erleben“:
Der Text des Labels „standard“ sollte „standard“ lauten, nicht fett – führen Sie den Code aus und versuchen Sie Ihr Glück:

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

Ein ähnliches Problem tritt bei Voreinstellungen und benutzerdefinierten Einstellungen auf. Sobald eine Einstellung in den Voreinstellungen von der Standardeinstellung abweicht, ist der Benutzer gezwungen, diese Einstellung zu verwenden. Es gibt kaum eine Möglichkeit, einen Bericht zur Verwendung der Standardeinstellungen zu zwingen, insbesondere nachdem der Bericht geändert und das Skript gespeichert wurde. In diesem Fall ist die Option „Auf Standard zurücksetzen“ nicht mehr verfügbar.

Noch schlimmer bei Referenzlinien: Gibt es überhaupt keine Möglichkeit, die Einstellung zurückzusetzen ?

Betreff: Nutzen Sie die Einstellungen?

Ein ähnlicher Konflikt besteht für die Marker- und Farbeinstellungen im Graph Builder:

Es gibt verschiedene Möglichkeiten, die Einstellungen für Marker anzupassen:

1. Zeilenstatus für einzelne Zeilen
2. Markereinstellungen über das Legendenmenü im Graph Builder
3. Globale Marker-Einstellungen im Einstellungsmenü

[Was in JMP 19 nicht möglich ist, ist die Steuerung der Marker-Einstellungen über eine Spalteneigenschaft: "Wertmarker " -> Bitte folgen Sie dem Link und stimmen Sie ab! ]

Die Probleme:

Die über das Legendenmenü vorgenommenen Einstellungen überschreiben die Einstellungen aus den Zeilenstatus .
Eine Ausnahme bildet die Standardmarkierung . Wird diese im Legendenmenü ausgewählt, geht JMP davon aus, dass der Benutzer die Einstellungen zurücksetzen möchte. Der Befehl wird daher ignoriert, und die Markierungseinstellung der Zeilenzustände wird wieder aktiviert. Die einzige Möglichkeit, die Zeilenzustände zu umgehen, besteht darin, eine spezielle Markierung zuzuweisen. Es ist nicht möglich, die Zeilenzustände mit der Standardmarkierung zu überschreiben.

Similarly, settings via the legend menu override the settings in the Präferenzen.
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 nicht standardmäßige Markierung 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!!

Das Gleiche gilt für Farben :
Es ist nicht möglich, die Zeilenstatusfarbe mit Schwarz (der Standardfarbe) zu überschreiben.

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