cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Try the Materials Informatics Toolkit, which is designed to easily handle SMILES data. This and other helpful add-ins are available in the JMP® Marketplace
Choose Language Hide Translation Bar
MarkDayton
Level IV

Table Scripts and the Parent Data Table

I have a set of scripts that I copy to new data tables. To make sure that when I run the table script it acts on the data table it belongs to I have to edit all of the scripts to point to the right data table (dt = Data Table("this one")). Is there a generic way to reference the parent data table, similar to dt = Current Data Table(), but more like dt = Parent Data Table()?

table script.jpg

13 REPLIES 13
David_Burnham
Super User (Alumni)

Re: Table Scripts and the Parent Data Table

At the point when you run the table script, the table that it is associated with is the current data table so you should be able to use dt = CurrentDataTable().

-Dave
MarkDayton
Level IV

Re: Table Scripts and the Parent Data Table

If the script is open for editing, running the script from the editor will grab whichever data table is current using dt = Current Data Table(). The only way to guarantee that the script will point at the right table is by being explicit about the table the script should act on (which is what JMP teaches in the Intro to Scripting class as a best practice), so I'm looking for a way to do that generically so I don't have to constantly update the scripts everytime the data table name changes. 

 

In the attached photo, the table script belongs to Data Table("this one") and Data Table("that one") is the Current Data Table(). If "when you run the table script, the table that it is associated with is the current data table" then the result of the scipt should be "this one" not "that one"

table script_2.jpg

txnelson
Super User

Re: Table Scripts and the Parent Data Table

You should be able to create an "OnOpen" table script that when you open the table, it creates a globle variable that contains the current data table that you are working on.  Then in the subsequent scripts, you reference that global variable.  Just moving from one table to another would not change that global variable.  It would only change when another one of your taqbles that has an "OnOpen" table script that changes the global variable is opened.

Jim
MarkDayton
Level IV

Re: Table Scripts and the Parent Data Table

Thanks Jim. I could probably also handle it with a table variable. Can those be hidden? I already have quite a few, and I'd like to limit them.

txnelson
Super User

Re: Table Scripts and the Parent Data Table

not hidden, but you can group them, which takes all of the grouped scripts and places them in a expandable single label

Jim
MarkDayton
Level IV

Re: Table Scripts and the Parent Data Table

Table variables don't group
txnelson
Super User

Re: Table Scripts and the Parent Data Table

Just make it a table script that sets a global variable value

Jim
MarkDayton
Level IV

Re: Table Scripts and the Parent Data Table

Not sure the Global namespace is the place for this in my workflow. I always have multiple tables open at anyone time, hence wanting to make sure that the scripts always work on the right data (but thanks for the heads up on scripting an OnOpen event, didn't know JMP did that). I could just use Current Data Table and always run from the green triangle as David suggested, but I prefer to be explicit in all references when possible. I was hoping that there was a way to do this, but I guess the connection is only one way. Data Tables know what table scripts they have, but table scripts don't know what table they belong to.
txnelson
Super User

Re: Table Scripts and the Parent Data Table

There is another, more complex way to approach this.  Rather than doing a copy/paste for your table scripts, you could write a script that adds the various table scripts to the new table, and within that script, it could generate the code for each of the scripts that would point to the data table the scripts are in.

Jim