Unable to run addins within Project

[#1]

We have organized many scripts into an addin for our company.  The addin responds but scripts will not run when invoked within 'Project'.  Is this something that can be remedied through the addin scripting or does the script itself have to be contained separately within the project?

[#2]

I am guessing your add-in relies on global variables that are defined when the add-in loads and are referenced later when the add-in functionality is invoked.  In projects, the global context is different than other projects and in the rest of JMP, and anything defined by the add-in is not accessible from within the project.  To combat this you can set all menu options to open files or run scripts that include a checks if the add-in is already loaded (ex: check if appropriate globals exist) and if it isn't loaded, to reload the addin. That way the add-in namespace and variables are loaded the first time the user invokes the add-in within a project.

If you aren't relying on global variables in your add-in, can you give more details about what functionality isn't working?

[#3]

I found this:

https://www.jmp.com/support/help/en/16.0/?os=win&source=application&utm_source=helpmenu&utm_medium=a...

"JMP can have several projects open at the same time, as well as items not open in any project. Each project has its own global scope, which prevents conflicts caused by identically named variables in different projects. In the rare case that you do want to share specific variables among all opened projects, use the ::: root operator."

I think if your add-in loads scripts that you want to use from a project, the ::: may be what you need. I've not tried it.

@aaron_andersen 

[#4]

Craige's idea is the first thing I'd look into also. (If that doesn't work, I'd need to see the adin-in, or at least know more about what it does, to make additional suggestions).

Aa

[#5]

Hi Craig,

I wrote the add-ins that Lynn is using in her question.  I created a namespace for each add-in to avoid variable collisions.  Do these namespaces only exist within the non-project global scope?  Is there a way that I could create namespaces within the ":::" global scope?

Many thanks,

John 

[#6]

I'm not sure; @aaron_andersen  will know the correct answer. My quick test suggests you'll need a global variable holding a namespace; the various namespace functions (and class functions) appear blind to the namespaces outside of the project. What I did that looks like it will work: from outside of the project, assign a global. I used ::: but I think that is only special in a project.

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

From within the project, :::myNameSpace appears to work.

I'm not sure when the project OnOpen script runs and what context it runs in, but it might be part of the solution. It could possibly run the add-in to re-create the functions within the project's scope. (I played with it earlier and it seemed like it might be useful for arranging windows when the project was opened. I didn't need that.)

I understand the reason to keep the JSL functions isolated in a namespace without creating a global variable. I hope there is a way to keep that working. (Of course the namespace names are another global space...and I suppose that is what the project may be fighting.)

[#7]

Each project in JMP has its own globals and namespace listing. This is also true for the non-project part of JMP. So if you create a global:a outside of a project, it won't be visible in any project. And if you create a global:b inside Project01, it won't be visible outside of that project or in any other project. In addition, if you create a namespace "A" outside a project, it won't be visible (by name, as in A:symbol) inside any project. And similar for creating a namespace in a project. This is done to keep projects isolated from each other and from non-projects. And it allows for running multiple copies of the same script across several projects without them colliding with each other even if they use globals.

If you need to communicate across projects or between non-projects and projects, the best way is to the root namespace (::: or As Root syntax). Symbols in this namespace are unique across the running JMP instance.

So, as Craig suggested, you could assign a namespace to a symbol in the root namespace. Then use that namespace by symbol, like As Root(myNsSym):x, instead of by name.

If you only need responses to menu items and buttons, then the suggestion above to delay initialization of the addin until each of these is a good option. Then, the addin will be initialized in each project when it is first used. And you can use a global to check for prior initialization. I've done this for several add-ins in the past. However, it means your start-up and exit scripts need to be pretty bare because you aren't doing much when JMP starts/exits. This also doesn't work if you need something beyond responses to menus or if you need to communicate across projects. In these cases, the root namespace would probably be best.

Finally, you could use the Project OnOpen script or the Workspace Startup script to initialize things as well. See https://www.jmp.com/support/help/en/16.0/index.shtml#page/jmp/write-a-project-on-open-script-2.shtml and https://www.jmp.com/support/help/en/16.0/index.shtml#page/jmp/run-startup-scripts-to-control-workspa... for more information on those. If you already don't do much in your start-up/exit scripts for your addin, you might even just attempt Try(Get Addin("...")<<Unload<<Load) with your addin in one of those scripts.

[#8]

Namespaces and Projects - unfortunately more complicated than discussed here ...

I thought it'd be a good idea to create the functions from the Recall Function Library  as custom functions and load them via an AddIn when JMP starts. This way the functionality is nicely documented via the scripting index - and no user has to bother to include the library in their AddIn or project - it's already there.

Then I realized that the original namespace was only created in the global namespace of JMP - and that I had to globalize the namespace via

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

to make it accessible from projects.

Unfortunately, I ran into additional issues which I documented here:
Namespaces and Projects 

[#9]

A cool trick, thanks @Jasean:

localize the root namespace to use it in Projects

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

Why was my issue not discussed in 2021?

Does somebody have a license which works with JMP16 and below - and could check if there WAS as issue in 2021?
or did you use @Jasean 's trick "by default" ...