686348_fr-FR

liliconcom

Utilisez-vous les préférences ?

Via Fichier/Préférences, vous pouvez modifier les paramètres standard de Jmp.

Très cool d'ajuster Jmp à vos besoins:)

Mais j'ai trouvé un problème subtil - en combinaison avec la fonctionnalité permettant de générer automatiquement du code JSL (enregistrement dans un script, journal avancé, tableaux de bord, journal, Workflow Builder...)

Le code ci-dessous modifie les préférences, alors réfléchissez-y à deux fois si vous voulez l'essayer.

L'histoire:

Un utilisateur ajuste certains paramètres (paramètre de conservation de l'axe du commutateur conditionnel et de colonne) via Fichier/Préférences
- puis génère un rapport avec le paramètre par défaut (il doit le faire manuellement, aucune possibilité de générer le code via un journal amélioré) :

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

Ensuite, il ajuste le rapport de manière interactive via l'interface graphique et enregistre le script (en utilisant la fonctionnalité de journal améliorée de JMP).

Le script généré ressemblera à ceci :

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

Veuillez noter:
Conditionnel (0) -> supprimé automatiquement !

Retain Axis Settings( 0 ) -> removed automatically!

The finding:
Default settings are automatically removed from the code - "car ils n'auront aucun effet pour un système standard".

La même chose se produit si l'utilisateur utilise le rapport dans un tableau de bord (!) - les paramètres par défaut ne seront pas ajoutés.

Maintenant, l'utilisateur exécute à nouveau le code - imaginez à quoi ressemblera le rapport...

Je peux comprendre pourquoi c'est comme ça - ce n'est pas un bug, c'est une fonctionnalité intéressante qui permet à Jmp de nettoyer automatiquement le code pour supprimer les lignes inutiles.

Mais en combinaison avec un utilisateur qui ose modifier les paramètres dans les préférences, cela agit définitivement comme un bug – un bug grave !

Ma solution de contournement actuelle : modifiez simplement les préférences lorsque vous êtes sûr de ne JAMAIS (!!!) utiliser le paramètre par défaut.
Cette règle fait mal - surtout dans les cas où j'utilise le paramètre ajusté dans 99% des cas - et 1% le paramètre par défaut.
Ensuite, la règle ne me permet pas d'ajuster les préférences. Je suis obligé de vivre avec le paramètre par défaut et je dois ajuster manuellement le paramètre dans 99% des cas.

Existe-t-il une meilleure solution : comment résolvez-VOUS ce problème dans la vie professionnelle quotidienne ?

Automatisation et scriptsRe : Utilisez-vous les préférences ?

Selon le support Jmp (TS-00061254) :

cela fonctionne comme prévu.

 

Donc:
Avec des paramètres MODIFIÉS dans les préférences, un utilisateur perd la possibilité d'utiliser Dashboard Builder pour générer des tableaux de bord qui ouvrent des plates-formes sur son système avec des paramètres STANDARD 

 

Solution de contournement:

Ouvrez le script source du tableau de bord et ajoutez manuellement le code pour le paramètre standard.

Re : Utilisez-vous les préférences ?

Le support Jmp a suggéré d'écrire un article pour la liste de souhaits.

C'est ici:
Paramètres modifiés dans les préférences -> résoudre le problème

Re : Utilisez-vous les préférences ?

@hogi , j'ai essayé ton code et j'ai vu ce que tu veux dire. après avoir modifié la préférence pour le filtre et le sélecteur de colonnes, puis en utilisant des choix qui correspondent aux préférences par défaut (et non à la préférence actuelle), vous créez un rapport. Ensuite, l'enregistrement du script ne prend pas la peine d'inclure les paramètres qui correspondent aux valeurs par défaut, de sorte que le script ne reproduit pas votre rapport. Et vous interprétez cela (et le support a affirmé ?) que cela est intentionnel pour nettoyer tout ce qui ne serait pas nécessaire si vous aviez laissé votre système avec les préférences par défaut ? c'est à dire. Conditionnel (0) non inclus car il ne serait pas nécessaire si vous aviez la préférence par défaut même si elle est actuellement pertinente ?

Mais ce n'est pas ce que je vois pour les préférences de Graph Builder lui-même. Si je modifie ma préférence pour le générateur de graphiques pour ne pas afficher le titre, par exemple, puis que je crée un générateur de graphiques et que je demande (soit en JSL, soit manuellement après coup) d'afficher le titre, j'obtiens un script avec showtitle (1) inclus. . Le type de paramètre redondant que conditional(0) pourrait être considéré comme un paramètre dont vous n'avez pas besoin si vous avez des préférences par défaut. Je pense que ce que je vois en général, c'est qu'il n'inclut pas les paramètres qui ne sont pas nécessaires avec les préférences que j'ai actuellement. Maintenant que j'ai désactivé l'affichage du titre dans mes préférences, si je demande showtitle(0), cela ne prend pas la peine de le mentionner dans le script.

Cela ressemble donc à 2 problèmes : (1) on pourrait vouloir capturer toutes les options, qu'elles correspondent ou non à vos préférences et (2) les options de type "get script" me semblent traiter le filtre et le sélecteur de couleurs différemment de ils traitent le reste de la plateforme. il ne parvient pas à vous fournir un script qui fonctionne avec vos préférences actuelles comme il le fait pour les préférences de la plate-forme. Je peux comprendre que la suppression des clauses inutiles est intentionnelle, mais pas que la définition de ce qui est inutile soit différente pour filter que pour settitle().?

2. cela me semble être un bug car il élimine des éléments non pas parce qu'ils sont identiques aux préférences actuelles, mais parce qu'ils sont identiques aux valeurs par défaut.

1. il semble que cela soit en effet similaire à l'élément de ma liste de souhaits concernant l'utilisation du séparateur de milliers ( interroger Utiliser le séparateur de milliers à l'aide de JSL - Communauté d'utilisateurs JMP ), où peut-être qu'une solution pourrait être une option pour qu'un script plus verbeux soit renvoyé, celui qui ne le fait pas. Il ne faut pas éliminer quoi que ce soit d'autre que « identique aux préférences ».

Super, maintenant mes préférences sont toutes foutues...

Re : Utilisez-vous les préférences ?

100% d'accord

en particulier le
- Je peux comprendre que la suppression des clauses inutiles est intentionnelle

- mais pas que la définition de inutile soit différente pour filter que pour settitle().?

il existe de nombreux autres paramètres qui se comportent comme le sélecteur de colonnes et le filtre de données - même les paramètres qui affectent directement Graph Builder :

Si vous modifiez les paramètres par défaut pour les statistiques récapitulatives, l'espacement des graphiques, etc. dans les préférences, tout votre code JSL généré automatiquement aura une section avec :
Statistique récapitulative( "Médiane" ),
Espacement des graphiques ( 4 )

... jusqu'à ce que vous essayiez de rétablir les valeurs par défaut. Si vous appuyez sur le paramètre par défaut, les paramètres n'apparaîtront pas dans le script JSL généré - avec un problème similaire à celui du Conditionnel : aucune chance de générer automatiquement un code JSL avec les paramètres par défaut.

Re : Utilisez-vous les préférences ?

Comme il y a tellement d'espace entre
- supprimer les clauses "inutiles"

- écrire tous les paramètres de telle sorte que le résultat soit le même sur TOUS les systèmes - indépendamment des paramètres actuels.

Alors, que diriez-vous d'un verbeux(0), verbeux(0.3), verbeux (0.5), verbeux(0.7), verbeux(1)

- 0 : supprime tout le code "inutile" comme maintenant - mode de compatibilité
- 0.3 : générer tout le code JSL nécessaire pour générer le même résultat sur ce système. [résout le problème avec le conditionnel]
- 0.5 : générer tout le code JSL nécessaire pour générer le même résultat sur un système par défaut . [corrige le problème avec le paramètre de dégradé défini par l'utilisateur]

- 0,7 : sur la base des graphiques/rapports générés des 6 derniers mois, inclut tous les paramètres modifiés >=3 fois. Générez un code robuste à tous les paramètres.

- 1 : code JSL robuste à tous les paramètres des préférences.

0.7 : super utile - mon préféré !
- peu importe 5 lignes de code supplémentaires - si elles génèrent un résultat plus robuste sur n'importe quel système de vos collègues.
- à quelle fréquence avez-vous généré une concaténation et vous êtes-vous interrogé plus tard sur le libellé exact de l'ajout à la table principale (1) ?

Re: Utilisez-vous les préférences ?

Un collègue a trouvé un bon exemple qui illustre un bug similaire causé par un conflit de paramètres différents dans Graph Builder :
Un utilisateur n'est pas autorisé à définir un paramètre comme STANDARD si, à un niveau supérieur, un paramètre non standard est appliqué.

Dans Graph Builder, il existe une commande pour les paramètres des axes, et dans les paramètres des axes, il existe une commande pour les lignes de référence.
Les lignes de référence semblent hériter des paramètres de police des paramètres d'axe.
Et le seul moyen de « supprimer » un paramètre hérité est d'appliquer un paramètre non standard et ainsi d'écraser le paramètre hérité.
Difficile à expliquer, mais facile à « vivre » :
Le texte de l'étiquette « standard » doit être « standard », et non en gras. Exécutez le code et tentez votre chance :

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

Un problème similaire se pose avec les préférences et les paramètres personnalisés. Dès qu'un paramètre des préférences diffère du paramètre standard, l'utilisateur est contraint d'utiliser ce dernier. Il est quasiment impossible de forcer un rapport à utiliser les paramètres standard, surtout après sa modification et l'enregistrement du script. C'est à ce moment-là que l'option « Rétablir les paramètres par défaut » devient inutile.

Pire encore avec les lignes de référence : aucune possibilité de réinitialiser le paramètre ?

Re: Utilisez-vous les préférences ?

Un conflit similaire existe pour les paramètres de marqueurs et de couleurs dans le générateur de graphiques :

Il existe différentes manières de régler les paramètres des marqueurs :

1. état des lignes pour chaque ligne
2. Paramètres des marqueurs via le menu légende dans Graph Builder
3. paramètres globaux des marqueurs dans le menu des préférences

[Dans JMP 19, il n'est pas possible de contrôler les paramètres des marqueurs via une propriété de colonne : « Marqueurs de valeur » -> veuillez suivre le lien et voter !]

Les problèmes :

Les paramètres définis via le menu de la légende remplacent les paramètres des états de ligne .
L'exception concerne le marqueur par défaut . Si le marqueur standard est sélectionné dans le menu de la légende, JMP considère que l'utilisateur souhaite réinitialiser les paramètres ; la commande est donc ignorée et le paramètre de marqueur issu des états de ligne est rétabli. La seule façon de contourner les états de ligne est d'attribuer un marqueur spécifique . Il est impossible de remplacer les états de ligne par le marqueur par défaut.

Similarly, settings via the legend menu override the settings in the préférences.
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 marqueur non standard 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!!

Il en va de même pour les couleurs :
Il n'est pas possible de remplacer la couleur d'état d'une ligne par du noir (la couleur par défaut).

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