nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

JMP 9 automation bug

unknown

I'm using JMP 9.0.3 64-bit under Windows 7 and automating it from Python using the win32com module. My automation code is based on the JMP 9 Automation Guide, the PDF of which seems now to have disappeared from the website: http://www.jmp.com/support/downloads/pdf/

Here's the bug: the Document automation object has properties Name, FullName, and Path which are supposed to reflect the table name or file name contained therein. However, in many cases these properties turn out to be blank, despite the fact that the table has a non-blank name within JMP, and despite the fact that the automation object for this table can in fact be retrieved using this name.

Here's some Python code that demonstrates the bug. It creates a table using JSL, saves the name of this table, and looks up the table's automation object by name. It then checks whether table.Document.Name in fact matches the known name of the table, and reports the cases where this doesn't hold. It does this 100 times and typically the name starts coming back blank after the first 2-4 iterations:

from win32com.client import gencache
mod = gencache.GetModuleForProgID("JMP.Application")
app = mod.Application()

okay_table = [False]*100

for ii in range(len(okay_table)):
    # Create a table in JMP
    app.RunCommand("::dt=New Table(); ::retval=dt<<Get Name()")

    # Retrieve the name of that just-created table from the JSL variable
    retval = app.GetJSLValue("retval")

    # Retrieve the automation object for that table, by name
    table = app.GetTableHandleFromName(retval)

    # Now, table.Document.Name **SHOULD** match retval, but
    # it may be blank due to the bug.

    if table.Document.Name=="" and table.Document.Path=="" and table.Document.FullName=="":
        print "table %d: got blank table.Document.Name; Path=%s, FullName=%s" % (ii,
            table.Document.Path, table.Document.FullName)
        app.RunCommand("close(DataTable(::retval), nosave)")
        okay_table[ii]=False
    else:
        print "table %d: looks okay; Name=%s, FullName=%s, Path=%s" % (ii,
            table.Document.Name, table.Document.FullName, table.Document.Path)
        app.RunCommand('close(DataTable("%s"), nosave)' % table.Document.Name)
        okay_table[ii]=True


print "Number of bad tables: %d" % okay_table.count(False)

Typical output:

$ python JMP_automation_bug.py
table 0: looks okay; Name=Untitled 304, FullName=Untitled 304.jmp, Path=Untitled 304.jmp
table 1: looks okay; Name=Untitled 305, FullName=Untitled 305.jmp, Path=Untitled 305.jmp
table 2: got blank table.Document.Name; Path=, FullName=
table 3: got blank table.Document.Name; Path=, FullName=
table 4: got blank table.Document.Name; Path=, FullName=
...
table 98: got blank table.Document.Name; Path=, FullName=
table 99: got blank table.Document.Name; Path=, FullName=
Number of bad tables: 98

This bug is becoming quite a show-stopper for me. I quite frequently need to manipulate tables in automation code and then exchange the table names with JSL code, and this bug makes it impossible to do so reliably.

Has anyone else encountered it? Any known fixes or workarounds?

Accepted answers

All comments

briancorcoran

The documentation should also be installed at c:\program files\sas\jmp\9\Support Files English\Documentation\Automation Reference.pdf.

You might have a timing issue. You might try a different approach, using the NewDataTable method on the Application object:

myJMP = CreateObject("JMP.Application")

Call Sleep(1000)

myJMP.Visible = True

Dim names As String

names = ""

For i As Integer = 1 To 30

Dim dt As JMP.DataTable

Dim tableName As String

dt = myJMP.NewDataTable("")

Sleep(100)

tableName = dt.Document.Name

names = names + tableName

names = names & vbCrLf

MessageBox.Show(names, "Tables Created", MessageBoxButtons.OK)

unknown

Brian,

Yes, the Automation Reference is installed locally. I was just pointing out that it seems no longer to be available online.

This is not, as far as I can tell, a timing issue. I tried an approach similar to yours of introducing a delay prior to checking dt.Document.Name, but this makes no difference. Using automation code (app.NewDataTable) to create tables, instead of creating them with JSL, does not fix the problem in all cases, nor can I rely on it in general.

I've discovered a workaround, but it's an excruciatingly awkward one. In order to get the name of an automation table, I now do this:

Get names of all JMP tables in a JSL list
Use app.GetJSLValue to get this list into the automating application.
Loop through the list of names one-by-one, looking up automation table objects by name using app.GetTableHandleFromName
I compare the OLE object identity of each table to the OLE object identity of my target table. If they match, I return the name which I used to look it up.

Code for my horrible ugly workaround:

    def GetTableName(app, table):
        if table.Document.Name:
            return table.Document.Name
        else:
            # Get names of all JMP tables
            app.RunCommand("""
                NamesDefaultToHere(1);
                ::_retval={};
                for(ii=1, ii<=NTable(), ii++,
                    InsertInto(::_retval, DataTable(ii)<<GetName())
                )""")
            tns = app.GetJSLValue("_retval")

            # Compare object identity based on obj address shown in repr(table._oleobj_):
            #    <PyIDispatch at 0x00000000041997B0 with obj at 0x0000000000381458>
            table_ole_obj = int(repr(table._oleobj_).split()[-1][:-1], 0)
            for tn in tns:
                tn_ole_obj = int(repr(app.GetTableHandleFromName(tn)._oleobj_).split()[-1][:-1], 0)
                if table_ole_obj==tn_ole_obj:
                    return tn
            else:
                raise Exception

unknown

Brian, I should mention that this issue is definitely not Python-specific. I can easily get the same incorrect behavior from VBScript automation code, even if I include lengthy delays:

JMP_automation_bug.vbs:

Set myJMP = CreateObject("JMP.Application")
myJMP.Visible = True
WScript.Sleep 1000

tns = ""
For i = 1 To 30
   myJMP.RunCommand "::dt=New Table(); ::retval=dt<<Get Name()"
   WScript.Sleep 1000
   retval = myJMP.GetJSLValue("retval")
   Set dt = myJMP.GetTableHandleFromName(retval)
   WScript.Sleep 1000
   tableName = dt.Document.Name
   If tableName="" Then
     WScript.Echo "blank tableName"
   Else
     WScript.Echo "non-blank tableName: ", tableName
   End If
   tns = tns + tableName
   tns = tns & vbCrLf
   myJMP.RunCommand "close(DataTable(::retval), nosave)"
Next

WScript.Echo tns

unknown

I've also confirmed that the bug also exists in JMP 11 and can be reproduced with the same JMP_automation_bug.vbs example as with JMP 9.

briancorcoran

I'm curious why you don't want to use NewDataTable off of the application object? That is the recommended way of creating a new table via automation.

Brian