383815_de-DE

liliconcom

Add-Ins können in Project nicht ausgeführt werden

Wir haben viele Skripte in einem Add-in für unser Unternehmen organisiert.Das Add-in antwortet, aber Skripte werden nicht ausgeführt, wenn sie innerhalb von „Project“ aufgerufen werden.Kann dies durch das Add-in-Skripting behoben werden oder muss das Skript selbst separat im Projekt enthalten sein?

SkripterstellungBetreff: Add-Ins können in Project nicht ausgeführt werden

Jedes Projekt in JMP hat seine eigenen Globals und Namespace-Listen. Dies gilt auch für den Nicht-Projektteil von JMP. Wenn Sie also ein global:a außerhalb eines Projekts erstellen, ist es in keinem Projekt sichtbar. Und wenn Sie ein global:b innerhalb von Project01 erstellen, ist es außerhalb dieses Projekts oder in einem anderen Projekt nicht sichtbar. Wenn Sie einen Namensraum „A“ außerhalb eines Projekts erstellen, ist er außerdem in keinem Projekt sichtbar (nach Name, wie in A:symbol). Und ähnlich zum Erstellen eines Namensraums in einem Projekt. Dies geschieht, um Projekte voneinander und von Nicht-Projekten zu isolieren. Und es ermöglicht die Ausführung mehrerer Kopien desselben Skripts über mehrere Projekte hinweg, ohne dass sie miteinander kollidieren, selbst wenn sie globale verwenden.

 

Wenn Sie projektübergreifend oder zwischen Nicht-Projekten und Projekten kommunizieren müssen, führt der beste Weg zum Root-Namespace (::: oder As Root-Syntax). Symbole in diesem Namespace sind in der laufenden JMP-Instanz eindeutig.

 

Sie könnten also, wie Craig vorgeschlagen hat, einem Symbol im Root-Namensraum einen Namensraum zuweisen. Verwenden Sie dann diesen Namespace nach Symbol, wie As Root(myNsSym):x, anstatt nach Namen.

 

Wenn Sie nur Antworten auf Menüelemente und Schaltflächen benötigen, ist der obige Vorschlag, die Initialisierung des Add-Ins zu verzögern, bis jede dieser Optionen eine gute Option ist. Dann wird das Add-in bei der ersten Verwendung in jedem Projekt initialisiert. Und Sie können ein globales verwenden, um nach vorheriger Initialisierung zu suchen. Ich habe dies in der Vergangenheit für mehrere Add-Ins getan. Dies bedeutet jedoch, dass Ihre Start- und Exit-Skripte ziemlich leer sein müssen, da Sie nicht viel tun, wenn JMP gestartet/beendet wird. Dies funktioniert auch nicht, wenn Sie etwas anderes als Antworten auf Menüs benötigen oder wenn Sie projektübergreifend kommunizieren müssen. In diesen Fällen wäre der Root-Namespace wahrscheinlich am besten geeignet.

 

Schließlich könnten Sie auch das Project OnOpen-Skript oder das Workspace Startup-Skript verwenden, um Dinge zu initialisieren. Sehen https://www.jmp.com/support/help/en/16.0/index.shtml#page/jmp/write-a-project-on-open-script-2.shtml Und https://www.jmp.com/support/help/en/16.0/index.shtml#page/jmp/run-startup-scripts-to-control-workspaces.shtml#ww632187 für weitere Informationen zu diesen. Wenn Sie bereits nicht viel in Ihren Start-/Beendigungsskripten für Ihr Add-in tun, können Sie es sogar einfach mit Try(Get Add-in("...")<<

 

Betreff: Add-Ins können in Project nicht ausgeführt werden

Ich bin mir nicht sicher; @aaron_andersen wird die richtige Antwort wissen. Mein Schnelltest schlägt vor, dass Sie eine globale benötigen Variable Halten eines Namensraums; Die verschiedenen Namespace-Funktionen (und Klassenfunktionen) erscheinen blind für die Namespaces außerhalb des Projekts. Was ich getan habe, sieht so aus, als würde es funktionieren: Weisen Sie von außerhalb des Projekts eine globale. Ich habe ::: verwendet, aber ich denke, das ist nur in einem Projekt etwas Besonderes.

:::myNameSpace = namespace("myNameSpace"); // "globalize" a namespace

Innerhalb des Projekts scheint :::myNameSpace zu funktionieren.

 

Ich bin mir nicht sicher, wann das OnOpen-Skript des Projekts ausgeführt wird und in welchem Kontext es ausgeführt wird, aber es könnte Teil der Lösung sein. Es könnte möglicherweise das Add-In ausführen, um die Funktionen im Rahmen des Projekts neu zu erstellen. (Ich habe früher damit gespielt und es schien, als könnte es nützlich sein, um Fenster anzuordnen, wenn das Projekt geöffnet wurde. Das habe ich nicht gebraucht.)

 

Ich verstehe den Grund, die JSL-Funktionen in einem Namespace isoliert zu halten, ohne eine globale Variable zu erstellen. Ich hoffe, es gibt eine Möglichkeit, das am Laufen zu halten. (Natürlich sind die Namespace-Namen ein weiterer globaler Raum ... und ich nehme an, das ist es, was das Projekt bekämpft.)

 

Betreff: Add-Ins können in Project nicht ausgeführt werden

Hallo Craig,

 

Ich habe die Add-Ins geschrieben, die Lynn in ihrer Frage verwendet.Ich habe für jedes Add-In einen Namespace erstellt, um Variablenkollisionen zu vermeiden.Existieren diese Namespaces nur innerhalb des nicht projektbezogenen globalen Bereichs?Gibt es eine Möglichkeit, Namespaces innerhalb des globalen Bereichs ":::" zu erstellen?

 

Vielen Dank,

 

John

Betreff: Add-Ins können in Project nicht ausgeführt werden

Craiges Idee ist das erste, was ich mir auch ansehen würde. (Wenn das nicht funktioniert, müsste ich das Adin-In sehen oder zumindest mehr darüber wissen, was es tut, um zusätzliche Vorschläge zu machen).

 

Aa

Betreff: Add-Ins können in Project nicht ausgeführt werden

Ich habe das gefunden:

https://www.jmp.com/support/help/en/16.0/?os=win&source=application&utm_source=helpmenu&utm_medium=application#page/jmp/running-scripts-in-a-project.shtml

 

"JMP kann mehrere haben Projekt s gleichzeitig geöffnet, sowie Artikel, die in keinem geöffnet sind Projekt.Jede Projekt hat sein eigenes global Gültigkeitsbereich, der Konflikte verhindert, die durch gleichnamige Variablen in verschiedenen verursacht werden Projekt S. Für den seltenen Fall, dass Sie bestimmte Variablen unter allen geöffneten teilen möchten Projekt s, verwenden Sie die ::: Root-Operator."

 

Ich denke, wenn Ihr Add-In Skripte lädt, die Sie aus einem Projekt verwenden möchten, ist ::: möglicherweise das, was Sie brauchen. Ich habe es nicht versucht.

 

@aaron_andersen

 

Betreff: Add-Ins können in Project nicht ausgeführt werden

Ich vermute, Ihr Add-In stützt sich auf globale Variablen, die definiert werden, wenn das Add-In geladen wird, und auf die später verwiesen wird, wenn die Add-In-Funktionalität aufgerufen wird.In Projekten ist der globale Kontext anders als in anderen Projekten und im Rest von JMP, und alles, was durch das Add-in definiert wird, ist vom Projekt aus nicht zugänglich.Um dem entgegenzuwirken, können Sie alle Menüoptionen so einstellen, dass Dateien geöffnet oder Skripte ausgeführt werden, die eine Prüfung enthalten, ob das Add-In bereits geladen ist (z. B. prüfen, ob geeignete Globals vorhanden sind), und wenn es nicht geladen ist, das Add-In neu laden. Auf diese Weise werden der Add-In-Namespace und die Variablen geladen, wenn der Benutzer das Add-In zum ersten Mal in einem Projekt aufruft.

 

Wenn Sie sich in Ihrem Add-In nicht auf globale Variablen verlassen, können Sie weitere Details dazu angeben, welche Funktionen nicht funktionieren?

Betreff: Add-Ins können in Project nicht ausgeführt werden

Namespaces und Projekte – leider komplizierter als hier besprochen …

Ich dachte, es wäre eine gute Idee, die Funktionen aus der Recall Function Library als benutzerdefinierte Funktionen zu erstellen und sie beim Start von JMP über ein Add-In zu laden. Auf diese Weise wird die Funktionalität über den Skriptindex gut dokumentiert – und kein Benutzer muss sich die Mühe machen, die Bibliothek in sein Add-In oder Projekt einzubinden – sie ist bereits vorhanden.

Dann wurde mir klar, dass der ursprüngliche Namespace nur im globalen Namespace von JMP erstellt wurde - und dass ich den Namespace globalisieren musste über

:::myNameSpace = namespace("myNameSpace"); // "globalize" a namespace

Leider sind mir weitere Probleme begegnet, die ich hier dokumentiert habe:
Namespaces und Projekte

Betreff: Add-Ins können in Project nicht ausgeführt werden

Ein cooler Trick, danke @Jasean :

Lokalisieren Sie den Stammnamespace, um ihn in Projekten zu verwenden

myVar = :::myNs
myVar:x // success

Warum wurde mein Anliegen 2021 nicht besprochen?

Hat jemand eine Lizenz, die mit JMP16 und darunter funktioniert – und könnte prüfen, ob es im Jahr 2021 ein Problem gab?
oder hast du „standardmäßig“ den Trick von @Jasean verwendet …