Choose Language Hide Translation Bar
Level III

Input on possible bug for "pick file"

Hi everyone,


I was trying to implement some functionality in a script to make my life easier and might have stumbled upon a bug regarding the path retrieval of saved/unsaved data tables. I would like to know whether this behaviour is known/has been seen by other users or if it might be caused by my piece of code (and if so, a solution would be highly appreciated of course :-) ).


I was aiming at saving a constructed dashboard and the respective data table via button scripts within the actual dashboard. Here is the relevant excerpt from the script:

//set root path to nothing	

rootpath = "";

// create link to the "parent data table"

	cw = current window ();
	ListBivar = (cw << xpath("//OutlineBox[@helpKey='FitGroup']"));
	script = ListBivar[1] << get scriptable object;
	dat = script << get data table;
	DashName = dat << get window title;
	show (dat);
// retrieve file path of "parent data table"
	rootpath = dat << get path;
	show (rootpath);
	Bool = Contains (rootpath, "discrete file path" );
	show (Bool);
	If (Bool == 1, startpath = rootpath,
		Bool == 0, startpath = "discrete file path",	
	path = Pick file ("choose directory to save...", startpath, {"JMP/HTML files|jmp;jsl;jrn;html", "All files|*"}, 1, 1, DashName);
	show (path);
	If ( path == "", Throw (1) ,
		If(Right(path, 4) != ".jmp",
		path = path||".jmp";
		dat << save (path),
		dat << save (path)

Under regular conditions, this does work quite well. I start getting into trouble when I try to choose an already existing file via this dialogue to replace it, but the old file is still opened. That - of course - throws an error message. If I now close the old file and try again to replace the file, I still get an error message, this time hinting towards my script. As it seems (cp. below), within the second run, the retrieval of the file path of the parent data table gives back a discrete file path, as if the data table had been saved - which is not the case. I also copied the respective excerpt from the log with a little obscuring and additional comments:


1st run:

dat = DataTable("XXX");

rootpath = "";     <-- name for unsaved data table!

Bool = 0;

path = discrete file path";

Unable to save file.


2nd run:

dat = DataTable("XXX");

rootpath = "discrete file path";        <-- discrete file path, as if the data table had been saved

Bool = 1;

Invalid argument in Pick File: Directory "discrete file path" not found in access or evaluation of 'Pick File' , Pick File/*###*/("choose directory to save...", startpath,

{"JMP/HTML files|jmp;jsl;jrn;html", "All files|*"}, 1, 1, DashName)   <-- error due to the fact, that the transferred "rootpath" does not exist.



Has anyone seen something like this or does anyone see a flaw in the code which might explain this behaviour?


Best regards,



Re: Input on possible bug for "pick file"

Not sure if this will resolve, but PATH is also a function in JMP. I would always try to avoid variable names being the same as built-in function names of any programming language. Use e.g. fPath for myPath and try again. As said, probably the reason lays somewhere else, but my advice is more from a general perspective :)
Super User

Re: Input on possible bug for "pick file"

Any chance you could make a script to show what you're saying, just use big class or something.  

From the looks of it, you're trying to use a path "discrete file path", which looks nothing like a path to me.  The second argument has to be a path.  

Vince Faller - Predictum
Level III

Re: Input on possible bug for "pick file"

Yes, you are definitely right. I actually used "discrete file path" as a placeholder for my actual file-path-string, as the information within wouldn't give any additional information and the string itself is -due to our somewhat excessive data structure - quite a long and messy one. So for readability I just shortened it to "discrete file path"...

I will try and put together an example based on big class (and see whether I can reproduce that error here as well, haven't tried that yet) as soon as I have some time left.
Article Labels

    There are no labels assigned to this post.