Add-In Manager

19 Kudos

Description

Add-In Manager enables you to easily build and re-build Add-In files, manage versions of an add-in over time, directly access source files, and have extra customizations for your add-in. Now with version 2.0 of Add-In Manager, you can control your entire JSL application development life-cycle now that you can deploy your add-ins out to your users directly from Add-In Manager!

Quickly Build Add-Ins

The fundamental feature of Add-In Manager is the ability to build a JMP add-in file directly from source files. This feature was initially included in my Custom Add-In Builder add-in and Add-In Manager has taken the basics of that add-in and improved upon it.

Add-In Manager.PNG

Deploy an Add-In to Users

With version 2.0 of Add-In Manager, you can now deploy (or push) add-ins out to your users directly from Add-In Manager. You can deploy to a TEST location for your users to test out your add-in and you can also deploy to a PROD location.

When deploying to PROD, a JSL script with an Associative Array is automatically updated with the latest publish date/time. This Associative Array can be used by an auto-generated 'updateCheck.jsl' script that can compare the build date of the user's add-in to the build date according to the Associative Array. If a newer version of the add-in is available, the user will see the following window, where they can choose to update to the latest version. This concept using an Associative Array to check for updates was adapted from @brady_brady's method of using a table with publish dates. This method is described in @Jeff_Perkinson's post How to write self-updating JMP add-ins.

Update Available.PNG

Manage Versions of an Add-In

Add-In Manager has the ability to automatically keep a version history of an add-in file each time a new one is built. It allows you to install, restore, or delete a previous version of an add-in. You can optionally include a comment for each build so you can keep track of what changes went into each version.

Making Extra Add-In Customizations

Add-In Manager allows you to make a few customizations to your add-in that previously required manual changes to XML. Below are the extra customizations available in Add-In Manager.

Max JMP Version
Built-in JMP Icons for menu items
Insert before position for specifying a position for a menu item
Custom menu bar – create your own menu or use an existing menu other than “Add-Ins”
New in Add-In Manager 2.0: Multiple main menu's within a single add-in

Menu Items.png

Accessing Source Files Directly from JMP

On the Files tab within Add-In Manager, you can open files in your source folder directly from JMP by double-clicking on the desired file in the table.

Automatic Management of Custom Metadata

With Add-In Manager version 2.0, you can create your own custom metadata in addition to the metadata automatically included and managed by Add-In Manager.

Custom Metadata.png

Managing Previously Installed Add-Ins

From the Installed tab, you can enable, disable, or register installed add-ins as well register add-ins that are not installed.

System Requirements

This add-in is supported on Windows and Mac operating systems with JMP 13 or higher.

Blog Series

Add-In Manager, Part 1: Defining and building a JMP add-In

Add-In Manager, Part 2: Deploying auto-updating add-ins to users

Add-In Manager, Part 3: Advanced customization

Changelog

Version 1.1-1.3 (October 16, 2017)

Fixed a few cases that caused the add-in to throw an error
Added new preferences for controlling whether menus and toolbars are shown

Version 2.0 (November 22, 2017)

Added support for deploying add-ins to TEST and PROD locations.
Added support for custom metadata via an Associative Array that can be included in your scripts.
Added ability to have multiple main menus in a single add-in.
Added ability to copy and paste menu items in the Menu Item Tree.
Added support for establishing a source folder from an existing 'jmpaddin' file.
Added ability to check for a new version, pulled directly from the JMP Community.
Added preference to automatically install add-ins after being built.
Removed support for building multiple add-ins at a time, for various reasons.
Squashed other various bugs.

Version 2.1 (February 26, 2018)

Added preference to exclude invisible files and folders (i.e. files/folders that start with a period). This is useful if you're using a version control system, like Git.
The customMetadata.jsl file is now ignored when determining if you have the latest version installed.

Version 2.2 (March 8, 2018)

Fixed an issue when adding more than two top-level main menus.
Added new icons to selection screen. Removed icons only available on one OS.

Version 2.3 (April 6, 2018)

Fixed error on Mac caused when a source folder was renamed or deleted
Preferences window now works even if you don't have the Consolas font installed on your computer.

Version 2.4 (January 9, 2020)

Allow inserting menu items either before or after other items, instead of only allowing inserting after.
Add 15 and 16 as min/max JMP version numbers.

Version 2.5 (February 5, 2020)

Improve readability when using macOS Dark Mode and Windows High Contrast mode in JMP 15.
Fix alert shown when opening preferences on Mac.

Version 2.6 (June 4, 2020)

Fixed bug with parsing add-ins with custom menus.
Added diagnostic info for parsing errors to help with future issues.

Version 2.7 (June 10, 2020)

Add workaround for temporary bug in JMP 16 EA

Version 2.8 (September 24, 2020)

Fixed issue unzipping add-ins with subfolders
Added option to automatically create a folder when using an add-in template (on by default).

Version 2.9 (February 4, 2021)

Changed some date formatting to Locale formats
Fixed the check for update feature

Version 3.0 (January 18, 2022)

XML special characters (such as '&') should no longer break addin.jmpcust files.

Version 3.1 (March 4, 2022)

Fixed date format warning for some locales when archiving add-ins.

Version 3.2 (September 25, 2023)

Fixed custom top-level menus in JMP 17+

Let me know if you find any issues!

Current Version=3.2

Justin_Chilton · ‎05-17-2021

@tsl, what does the file structure look like for the add-in when you zip it up manually?

I imagine since your code includes relative paths to the CommonFiles directory that your add-in looks something like this? Is the Release folder not included in the addin file?

Addin_1.jmpaddin
  |_Addin
    |_Source
      |_Code.jsl
    |_Release
      |_Something?
  |_CommonFiles

In the above structure, the 'Addin' folder only exists to keep the folder structure the same for your relative paths. Is this the case for you?

I think I can add a new optional directory path that can be copied into the add-in file as part of the build process. However, we still need to solve the directory issue. To solve that, the idea I have is to add a small snippet to set the location of the CommonFiles directory, and use that for all of your common file includes. Alternatively, you could create a 'IncludeCommonFile()' function that tried to include from production location and failover to the dev location

commonFilesDir = Directory Exists("../CommonFiles/", 
    "../CommonFiles/",  // production location
    "../../CommonFiles/" // development location
);

//or

IncludeCommonFile = Function({file},
    Try(Include("../CommonFiles/" || file), Include("../../CommonFiles/" || file));
);

This would give you the following structure, and I *think* would work if I were to add a shared folder feature. The one hiccup I can think of this would be that if you have additional folders within Source, then the Include function would not work, or you would need additional '../' in your includes using the directory variable.

Addin_1.jmpaddin
  |_Source
    |_Code.jsl
  |_CommonFiles

nathan-clark · ‎05-17-2021

@tsl
I do something similar with subversion, and I use the addin manager post any Repo activities. Once all code is committed, I export to a location which becomes the "source" for the addin (a local or network folder). Personally, I manage my .jmpcust files and .def files in my repo so those get exported as well, but you could just export code and make the .def and .jmpcust files with Addin Manager (it will create the files in the source folder, and in my case, exporting new stuff from the repo will only overwrite files being exported).

Then I use his tool to handle all of the packaging, archiving and distributing to my production folders (this is always what took the most time to do manually, anyways). To make things easier on myself, since I also had many addins being managed pre-Addin Manager, I also manually edited the jmp file which stores all of the information (addin, name, source folders, etc) so I had all my addins ready to go when I started the addin rather than adding them through that interface manually).

In addition to the addin itself, there are also some functions included which I have updated to allow my users to get notified and automatically update addins as new releases are put into production.

tsl · ‎05-18-2021

@Justin_Chilton , yes, you are describing something very close to what I do. Let me elaborate a little, showing what happens if I use the Addin Manager. ( And I'm still exploring and learning how it works, so forgive me if I'm miss-representing what it can do ! )

After building the Add-in, where I let the Source Folder be Addin_1\Source, I have a file we'll call Addin_1.jmpaddin sitting in the Addin_1\Release folder.

I rename that to a .zip extension, open it and take a look. I find it looks like this :

(There are also a couple of XML files I use for managing some things, but we can skip those for simplicity )

I then manually change the zip by making a new folder within the .zip and dragging all the Source_1, etc files into that new sub-folder. I leave the addin.jmpcust and add.def in the root level, because otherwise the add-in won't install. I also leave CustomMetaData.jsl in the root level because I'm guessing that's where it needs to be.

I then drag into the .zip the CommonFiles folder that I also need. My final Zip structure looks like this :

I then have one more thing to do : the <jm:action type="path"> lines in the .jmpcust file need to be edited now. Whereas it says

$ADDIN_HOME(com.x.y.z)\Source_1\Code_1.jsl

I need to change it to read

$ADDIN_HOME(com.x.y.z)\Addin_1\Source_1\Code_1.jsl

Which I can do with a Search / Replace in a text editor.

With all these steps done I can then deploy and install the Add-in and it all works.

To your last comment, because this add-in is a suite of tools, each one has it's own "Source" subfolder within Addin_1, so in order to reference the CommonFiles, my Include() statements in Code_1.jsl etc does have an extra "..\" to go up one extra level to correctly find the include files.

Justin_Chilton · ‎05-18-2021

Thanks for the clarification @tsl. It looks like to me that it could work with a few changes to your process.

Don't change the $ADDIN_HOME folder, and instead use relative paths and Get Default Directory(). This also makes it easier to develop the add-in as well because any references to that would be for the installed version.
Use a variable to determine the relative path location of CommonFiles and use that in your includes, since the location varies between a production add-in and the development repo.

Alternatively, you can scrap the idea all together of copying CommonFiles into each add-in. You can create a separate add-in entry for CommonFiles (it would have no command items), and require that the user to install that in addition to the add-in. This would mean that there is only one copy of the CommonFiles for the user (this may be a good thing or a bad thing depending on how often you test all add-ins after updating CommonFiles. With this, you could include the files using the $Addin_Home path variable, but you would still have to figure out how to include them from development. This might be similar to what @nathan-clark is doing, but I am not sure.

Yet another alternative is that instead of me implementing the copy for you (someone restrictive), I can just implement a very flexible post-processing script that you can define. Say, you define a function that takes a reference to the ZipArchive, and you can manipulate it how you see fit. This solution probably requires the least change by you and me.

Sorry for all of the rambling, but hopefully one of these suggestions puts us in the right direction!

nathan-clark · ‎05-18-2021

@Justin_Chilton
I use a combination of the $ADDIN_HOME and Get Default Directory() depending on where/how I need to include things. And for many of my includes, I do have a set of libraries which are common to many of my tools and I do treat them as a separate addin altogether. Then any tool I do make simply includes the file from $ADDIN_HOME and all of the library functions are available to me or anyone else who may want to use them.

I am unsure why @tsl has to add that extra layer to the zip. From my perspective, leaving it much like the organization in the his first hierarchy would make things more simple overall, but not knowing all the specifics of that infrastructure, there may be something I'm missing.
Typically, the only update I need to make to a .jmpcust file, once the original stuff is set, is to update the display name for a version update (which I do in my repo, but could be done in addin manager).

mringqui · ‎06-21-2021

Hi, great work! I'm hoping to create an add-in that uses a .jmpappsource file as the "Run JSL in this file" Action for the menu item. Is this something that could easily be added? Right now, being forced to use a .jsl file is limiting my ability to use the Add-In manager in a convenient way. Thanks!

Justin_Chilton · ‎07-16-2021

@mringqui, Thanks for reaching out. I was thinking that this would require some changes to the Add-in manager add-in, but @MikeD_Anderson showed me how to do this with how add-in manager already works.

Instead of setting a file to be run, use a script that runs the JMP app source file. You would just paste this into the text box for "Run this JSL."

Include("$ADDIN_HOME(com.example.me.myaddin)/MyApp.jmpappsource");

MikeD_Anderson · ‎07-16-2021

@mringqui & @Justin_Chilton - just a little color commentary on the method Justin mentions. You need to first compile the jmp app source file into a .jmpapp file. This can be done under File > Export when you're in application builder. You then include the .jmpapp file in the add-in package and open the .jmpapp file:

open("$ADDIN_HOME(com.example.me.myaddin)/MyApp.jmpapp");

This is what it looks like the JMP default Addin wizard.

Note that this has some nice knock-on effects over just imbedding the JSL directly. The biggest is that, for really big apps it will stop JMP being slow at start up. All the code needs to be parsed on start up - so if your script is really big or you have a ton of them, it can slow things down - a problem I had with the STK. Imbedding as an app means JMP just has to parse one line of code at start-up. There are some others, but that's the most important one IMO.

mringqui · ‎07-20-2021

@Justin_Chilton @MikeD_Anderson
Thanks a lot for the response! I actually just stumbled upon the ability to do that the other day, but you beat me to posting it on here.
@MikeD_Anderson- the info about the fast JMP startup is really good to know, the app scripts were definitely starting to get pretty huge, so this helps a lot.

Part of what I was hoping to accomplish with the Add-In Manager was skipping the step of having to export the .jmpappsource to a .jsl or .jmpapp every time I wanted to test something, so what I ended up with was the code below. I'm not quite sure how it works, but when using OpenFile(), the .jmpappsource doesn't launch the app builder, and the app can be run directly. Exactly what I needed!

app = JMPApp();
app << OpenFile("$ADDIN_HOME(com.example.addin)\MyApp.jmpappsource");
app << Run;

pauldeen · ‎09-14-2021

@Justin_Chilton JMP17EA2 displays empty menu structures again, no errors in the log. Thanks for this addin, it should be integrated in JMP directly!

Djtjhin · ‎10-01-2021

Hey @Justin_Chilton, I'm trying to use the add-in manager to deploy user-defined custom function which ideally runs on startup. Could you recommend the best way to do this using the add-in manager ?

pauldeen · ‎10-05-2021

@Djtjhin You can either deploy an empty addin to all computers with a addinLoad.jsl that includes your custom functions

Or

You could use your IT department to role out a jmpStartAdmin.jsl file which contains your custom functions as described here, no addin needed.

Djtjhin · ‎10-06-2021

Thanks @pauldeen! Didn't know the addinLoad.jsl functionality is available (hidden in the guide). That solution works for my problem!

vohwinkelh0 · ‎10-07-2021

@Justin_Chilton do you know if there is a way to implement the auto update function as well on TEST? I frequently stumble upon the fact that I hand out the TEST to users to test a feature, however once PROD updates they are not getting that update deployed since the TEST Addin does not automatically check wheter there is a new PROD version ?

pauldeen · ‎01-13-2022

@Justin_Chilton entering a & in the tooltip field causes a malfunction on write to addin.jmpcust which causes it to no longer be parseable. (JMP 16.1 Windows 10).

Justin_Chilton · ‎01-18-2022

@vohwinkelh0, that sounds like a great idea for a feature in Add-in Manager. It sounds like you would need some sort of separate TEST (or beta) versioning? Unfortunately, I currently don't have the bandwidth to implement something like that, but I am sure it could be done by adding some custom metadata fields and using those in your code to know if it is a TEST build.

Justin_Chilton · ‎01-18-2022

@pauldeen, thanks for reporting that! It should be fixed in v3.0.

nathan-clark · ‎01-27-2022

@vohwinkelh0 I harvested Justin's auto update code, and it would be pretty easy - I believe - to make a few updates to allow what you are talking about.

Depending how you have it integrated, you may be able to play with your local code to make those updates. As it stands, the code has a step that basically sees if the installed version is PROD and t hen checks for a newer build. I believe you could do the process if the installed version is PROD OR TEST ... and check the deployment area metadata to see if there is a newer PROD build.

It may be something you could look into to cover your needs until bandwidth opens up

Gido_vanderStar · ‎02-28-2022

Hi @Justin_Chilton ,

Thanks for this plugin. Just wanted to report one annoyance. When installing or deploying an add-in, I get the following message about 50 times in the Log:

Unknown format: m/d/y h:m

Using latest (v3.0) version of the add-in, in JMP 16.0.0, Windows10.

john_madden · ‎03-03-2022

Hi Justin,

When I try to install my add-in (which AIM builds just fine), I get an error "The DEV/TEST/PROD add-in does not exist". What could I be doing wrong?

John

AIM 3.0, JMP Pro EA 17.0b6, OS X 12.2.1

nathan-clark · ‎03-03-2022

@john_madden Did you click the build button first? That's the button next to the save icon. That will build the addin and place it in the development folder.

Then you can install DEV .... Or you can deploy a TEST or PROD build of the addin. (you need to deploy a TEST or PROD addin before you can install the TEST or PROD addin.

Justin_Chilton · ‎03-04-2022

@Gido_vanderStar ,

It looks like you are probably using a different locale than I am, which is causing the unknown format error. I just updated the add-in (v3.1) which makes the date format used during the archiving process respect the date format for your locale.

john_madden · ‎03-04-2022

Hi Nathan,

Yes, I did build it first and I didn't get any errors. But I get the deploy message anyway.

John

Djtjhin · ‎04-04-2022

Hi @Justin_Chilton, I recently came got this error in deploying a new Prod version.

Error Message:
{"argument should be character"(1, 2, "Concat", Bad Argument(currentAddinInfo["Name"]), "You have not saved your updated information for the " || /*###*/currentAddinInfo["Name"] || /*###*/" add-in." /*###*/)}
Error: argument should be character
1 time(s).
Type: Error
Function Name: Concat
Bad Argument: currentAddinInfo["Name"]
Function being executed: "You have not saved your updated information for the " || /*###*/currentAddinInfo["Name"] || /*###*/" add-in." /*###*/

Call Stack:
saveButtonCheck
refreshAddinTableBox
deploySelected

steveylin · ‎07-12-2022

I'm a novice trying to get addin working. I got it to work referencing a directory, but it defaults to "text" and I have to manually change to "path"

<jm:action type="path">$ADDIN_HOME(com.cirrus.pejmpscriptsMac)\pe-jmp-scripts\Check_Duplicate_Measurements.jsl</jm:action>

The problem I have is I'm able to modify .jmpcust to get it to work on my computer, but I can't export it. Is there an easy way to take the addin.def/addin.jmpcust and compress it myself? I'm hoping it's something easy and I don't have to use add-in manager.

I tried using zip and renaming but that didn't work.

Regards,

Steve

Justin_Chilton · ‎07-13-2022

@steveylin, simply zipping the add-in contents and renaming to xxx.jmpaddin should work, you just have to ensure that the jmpcust and def files are at the root of the jmpaddin zip file.

Alternatively, I would suggest adding your path as an include() for "Run thi JSL" instead of using the script directly using a path. This would avoid the need to manually edit the jmpcust file. I am not sure why path would not be working for you, but this is the setup I actually use for my add-ins.

I like to use <<New Context in my Includes for add-ins, so that multiple instances of the add-in do not overwrite each other's symbols.

steveylin · ‎07-13-2022

@Justin_Chilton thank you for the suggestion. You are correct that what I wanted can be handled by include(). Thanks for the tip on <<New Context.

Not sure why my zip didn't work, but I was doing it on a Mac, and all the entries disappeared after my manual attempt. Now that I got include working there's no need for manual edits anyway.

Djtjhin · ‎09-06-2022

HI @Justin_Chilton, I ran into this error below when I was deploying to a TEST folder. Appreciate the add-in otherwise! This should have been a standard feature in JMP

Error Message:
{"argument should be character"(1, 2, "Concat", Bad Argument(currentAddinInfo["Name"]), "You have not saved your updated information for the " || /*###*/currentAddinInfo["Name"] || /*###*/" add-in." /*###*/)}
Error: argument should be character
1 time(s).
Type: Error
Function Name: Concat
Bad Argument: currentAddinInfo["Name"]
Function being executed: "You have not saved your updated information for the " || /*###*/currentAddinInfo["Name"] || /*###*/" add-in." /*###*/

Call Stack:
saveButtonCheck
refreshAddinTableBox
deploySelected

TaeJunRyu · ‎09-18-2022

Hi @Justin_Chilton

I am receiving a lot of help building using Add-In Manager.

I was using it well up to v2.9, but the following error occurs when reinstalling.

This error occurs in both v2.9 and the latest version of v3.1.

When I run the installation file, the error occurs immediately and does not proceed.

Can you tell me how to take action for the error?

Many Thanks.

Dave_Ryu.

TaeJunRyu · ‎09-19-2022

Hi @Justin_Chilton

While trying various things after posting the question, I suspected that the file was damaged by the internal industry security system.
When I received the file from the outside and proceeded with the reinstallation, it was installed normally.

I will keep the questions and answers for the same case.
Thank you always, Justin

Dave_Ryu.

vohwinkelh0 · ‎10-17-2022

@Justin_Chilton, @nathan-clark I am finally coming back to my TEST Addin Auto Update function. I think I did get it running OK with the exception that the Add In manager is not writing out the Metadata Folder for the TEST setup.

Any chance to enable this ? otherwise one needs to manually update these files every time which is rather error prone.

Henning

pauldeen · ‎10-24-2022

@Justin_Chilton JMP17 is displaying empty menu structures for my add-ins where JMP16 is showing menu items. It is the same for all three addins. See my earlier message on Sep 14th 2021.

hogi · ‎11-09-2022

@Justin_Chilton : wonderful tool, thanks a lot!

- "insert_after" for commands.
In the .jmpcust file there is a placeholder for the "entry before" (in the example below: Graph Builder), which can be entered manually to get the new command placed at the correct position.

Is there a hidden function in the GUI to place a command at a specific position - like it's possible for menus?

- Can I use the tool as well do develop Add-In Toolbars?

nathan-clark · ‎11-28-2022

@vohwinkelh0 I'm not sure I understand what you are trying to do. In the addin manager, I would deploy TEST after I build the addin which creates the metadata file within the .jmpaddin

Depending how you utilize the function in the addin manager files, it may only check for updates if the version being used is PROD. Are you looking to do auto updates for TEST releases also?
I wonder if the issue is that the 'publishedaddins' file only gets updated on a PROD release, not a TEST release?

nathan-clark · ‎11-28-2022

@hogi If you click the Menu Items tab you should be able to click the hotspot next to Menu Item Tree and add a 'top level menu command' which should allow you to put the addin in an existing top menu OR create your own. In addition, you can manually update the .jmpcust file to create custom menu functions.

hogi · ‎11-28-2022

@nathan-clark could you specify to which of my two questions refers this answer?

nathan-clark · ‎11-28-2022

@hogi Oh, yes, sorry.... mostly the menu question. The first time I read, I considered them similar, but I see how toolbars are a bit if a different problem.

Since you can edit toolbars, I believe there would be a way to auto-create a custom toolbar (if I remember, the toolbar customizations just live in a file somewhere). Depending on your infrastructure, I could see this as a stand alone addin or perhaps something integrated into other addins utilizing addinload.jsl and addinunload.jsl files.

hogi · ‎11-28-2022

@nathan-clark

Sorry, I also don't understand your last post.

I can add a toolbar to the .jmpcust file, either in JMP or manually by editing the file.

But once I edit the respective Add-In in Add-In Manager (e.g. add another command to the Add-In menu), Add-In Manager will delete the Toolbar and all the entries within the Toolbar from the .jmpcust file.

This is a quite unexpected behavior, right?

In addition: I don't understand why I have to add the Toolbar settings manually - why not via Add-In Manager?

Concerning the other question:

Could you please indicate what I have to do in Add-In Manager to place an add-In e.g. exactly below GraphBuilder in the Graph menu?
(corresponding to the manual code sniplet in https://community.jmp.com/t5/JMP-Add-Ins/Add-In-Manager/tac-p/567196/highlight/true#M1646)

nathan-clark · ‎11-28-2022

@hogi Ok, I see where we are missing each other, at least in part.

Toolbars and Menus are different things. The menus are the text options to navigate and click and always start in that "File" "Edit"... etc The Toolbars are the bars of shortcut images you can add/remove.

I can't speak specifically to what you are seeing. Though. I've never had any issues with editing the .jmpcust files, unless I make a mistake. I haven't used Addin Manager to do much editing of the .jmpcust file so I can't say what should be expected in your scenario.

The vast majority of .jmpcust editing I do manually in text editors, and if there is an error in that file, JMP won't properly display the menu items.

@Justin_Chilton have you seen anything like the above?

vohwinkelh0 · ‎11-29-2022

@nathan-clark yes that is exactly the file. I need to manually update the publishedAddins.jsl file every time I push a new version to Test. Having that automated would be huge help

nathan-clark · ‎11-29-2022

@vohwinkelh0 ahh... that is a tougher problem to fix. from my understanding, that file is more to track the most up-to-date production releases so someone doesn't mix up production and test releases.

I'm not sure how much tracing of the code would be necessary, but I would find where the published addins file is created and basically copy it as a new method. I would essentially make an additional file that would have all the testpublishedaddins. Then I'd run this new method when TEST deployments are done.

And in your update code it can be set up so that for a PROD addin, it would check for updates in the publishedaddin file... if it's a TEST addin, it would check in the testpublishedaddin file.

I'm not sure the actual amount of code work that would be necessary for that, but that's the direction I'd head.

vohwinkelh0 · ‎11-29-2022

The way I handle it right now is that the file names are actually the same, as well as the folder structure. In the updateCheck.jsl I added:

		If( customMetadata_aa["state"] == "TEST",
						addinLoc = "\\xxx\JMP_Addin\TEST\xxx_META\";
		);

so basically dependent no the State of the Addin it will look in either folder. I was hoping it would be as easy as passing a different location to the function that writes out the publishedAddins.jsl.

Hoping this may sparks an idea ...

nathan-clark · ‎11-29-2022

I believe the location is passed via the table set up for each addin. So a given addin will have it's publishedaddin location in a given spot regardless of "state". And I'm not sure how that location is passed or when in the progression of code. If a TEST deployment I don't think the code for writing the file is called so you'd need to update that as well.

hogi · ‎11-30-2022

@nathan-clark wrote:
I can't speak specifically to what you are seeing. Though. I've never had any issues with editing the .jmpcust files, unless I make a mistake.

Hm, strange. On my system it's much worse - actually like this:
After importing the code into Add-In Manager, everything looks fine.

But as soon as I add a command to the Add-In via the Add-In Manager functionality, the whole toolbar settings will be deleted from the .jmpcust file (menu stettings will still be there).

I am quite surprised that this behavior is just observable on my PC - what's wrong?

Here is anexample .jmpcust code for testing on your PCs.
Once you add a command via Add-In Manager, the Toolbar with the show/hide legend button will be gone

<!-- JMP Add-In Builder created --><jm:menu_and_toolbar_customizations xmlns:jm="http://www.jmp.com/ns/menu" version="3">
  <jm:insert_in_main_menu>
    <jm:insert_in_menu>
      <jm:name>ADD-INS</jm:name>
      <jm:insert_after>
        <jm:name></jm:name>
        <jm:command>
          <jm:name>TEST</jm:name>
          <jm:caption>test</jm:caption>
          <jm:action type="text">print(1);</jm:action>
          <jm:icon type="none"></jm:icon>
        </jm:command>
      </jm:insert_after>
    </jm:insert_in_menu>
  </jm:insert_in_main_menu>
  <jm:toolbar>
    <jm:name>TEST.TEST: ADD-IN TOOLBAR</jm:name>
    <jm:caption>test.test: Add-In Toolbar</jm:caption>
    <jm:command>
      <jm:name>SHOW/HIDE LEGEND</jm:name>
      <jm:caption>show/hide legend</jm:caption>
      <jm:action type="text">local({first_gb},
	Try(
		first_gb = (Current Report() &lt;&lt; XPath( "//OutlineBox[@helpKey = 'Graph Builder']" ))[1] &lt;&lt; Get Scriptable Object;
		first_gb &lt;&lt; show legend (!(Report(first_gb)[LegendBox( 1 )] &lt;&lt; get width));
	)
);</jm:action>
      <jm:icon type="none"></jm:icon>
    </jm:command>
  </jm:toolbar>
</jm:menu_and_toolbar_customizations>

nathan-clark · ‎11-30-2022

thanks! @hogi

Can you send a screen shot of what things should look like? I've never seen or used the toolbar key before.

hogi · ‎11-30-2022

This is how you add a toolbar:

a general description of what toolbars are and how they work can be found here:
https://community.jmp.com/t5/JMP-Add-Ins/Add-In-Manager/tac-p/574113/highlight/true#M1661

nathan-clark · ‎11-30-2022

@hogi ok... i think i'm seeing what is going on. although i'm not sure i have a great answer. looking at the addin manager, it doesn't have any toolbar options (in Menu Items tab, the hotspot menu) which leads me to believe it may not be integrated with the recreation of the .jmpcust text to include toolbars which is why your text gets lost.

I have no real work around other than manually editing your .jmpcust files. I keep my code in repositories and manually edit my addin.def and addin.jmpcust files using addin manager primarily for a deployment system, so I haven't run into issues like you are seeing here.

StarfruitBob · ‎02-09-2023

Hello,

I’ve just started to build an add-in and before it’s deployed to my fellow co-workers, I’d like to learn how to manage it and deploy add-ins with this utility add-in. I’m encountering some difficulty setting up add-ins in such a way that they auto update.

The “Include Update Check Script” option in preference is checked.
The code snippet to check for updates is included.
- The “my.jmp.addin” is modified for each of the addin version attempts I try. “Add-In ID”

Creating and installing an add-in is easy with this utility. Steps on pgs 5-8 of the Add-In Manager User’s Guide are followed. This is the base version add-in I’ll use to “upgrade”.
1. Add-in Installed in PROD
A new add-in is created using the same methods as step 1, but the code snippet is updated for the new “Add-In ID”, the version in the General Info > Definition is also updated. This version of the “updated” script has its own folder tree.
1. Add-in deployed in PROD
2. Run add-in from step 1
  1. No window pops up asking to update add-in. Verified by making a small change in the text of a textbox

I don’t think I’m understanding the link of how the scripts from step 1 & 2 will compare their versions if everything is in their own separate folders. All of the meta data and other files in the source folder are being created successfully. Any guidance would be appreciated!

StarfruitBob · ‎02-22-2023

@Justin_Chilton or anyone else, any guidance on my post above?

Edit: I'm unable to set the same add-in ID for an update. It appears that the add-in manager requires identical add-in IDs for the date function to work. Each test of the add-in update has its own folder prior to me attempting to assign it an add-in ID.

nathan-clark · ‎02-23-2023

@StarfruitBob

I'm not sure I fully understand what you are doing. But addin IDs need to be completely unique and no two addins can have the same addinID -- even if they are just different versions.

When I execute addin updates, I have version control in a folder which had the updated code. I then copy that code over my 'source' folder for addin manager. I can then package the addin with the same addinID and addin Name (or update the name to reflect the version).

Perhaps I'm confused as to what you are trying to do for an "update"?