I'm running JMP 8 from Windows, and am tantalizingly close to making the above work for me, but I can't quite get there. I have a folder on my C: drive called "mydir" which contains a Windows Metafile called "image.wmf", a small text file called "aaa.txt" and a DOS batch file called "filecopy.bat" which contains the one-line DOS command "copy aaa.txt bbb.txt" (without the quotes). I try running each of the following commands from JMP:
The first of the above commands works exactly as the above reply describes (i.e. it opens the default viewer externally of JMP and displays the image), so it's evidently looking in the right place for the file to open, but the second one simply generates the following error messages:
<< Unable to open file. Unknown or ambiguous data source. Tried to open: \mydir\filecopy.bat Cannot open table in access or evaluation of 'Open' , Open( "\mydir\filecopy.bat" ) Open *###* ("\mydir\filecopy.bat") >>
Can anybody see what I'm doing wrong here? The file definitely exists, but JMP is evidently having trouble deciding what to do with it. (DOS does know what to do with it, as if I run it from a DOS window it copies the aaa.txt file to bbb.txt as would be expected.)
Many thanks for any help - this would be phenomenally useful to me if I could get it working.
// clean up possible prior runs SaveTextFile( "C:\temp\deleteme.bat", "del C:\temp\deleteme.r" ); Open( "C:\temp\deleteme.bat" );
If one tires of the flashing DOS window, JMP 8 adds the terriffic "LoadDll" command and you are off to the races. http://support.sas.com/documentation/cdl/en/hostwin/61924/HTML/default/accdll.htm http://msdn.microsoft.com/en-us/library/aa363851(VS.85).aspx
// fire R GUI and bring to front result = kernel32 << WinExec("Rterm", 1); // result = kernel32 << WinExec("Rgui", 0); // Rgui does not hide // or, fire R term in background result = kernel32 << WinExec("Rterm", 0);
// this works fine result = kernel32 << WinExec("C:\temp\deleteme.bat", 0); // 1=show, 0=hide, result gt 31=success
Still no joy, I'm afraid: I've tried changing both the text of the BAT file as suggested and the actual DOS command to include the full paths of both files, but the problem's still there. The following script saves "deleteme.bat" as you'd expect, but then fails to run it:
This works for me: I have a directory called c:\mydir . In it I have a text file called a.txt which contains one line of text: Copy Me. In the same directory I have a batch file called test.bat which contains one line: copy c:\mydir\a.txt c:\mydir\acopy.txt.
I open JMP 8.0.2 and in a script window enter the line: open("c:\mydir\test.bat") and run it.
When I check mydir I find a copy of a.txt called acopy.txt which contains the line Copy Me.
No good - I'm still getting the same error message, i.e.
Unable to open file. Unknown or ambiguous data source.
Tried to open: /c:/mydir/test.bat
Cannot open table in access or evaluation of 'Open' , Open( "c:\mydir\test.bat" )
In the following script, error marked by /*###*/ Open/*###*/("c:\mydir\test.bat")
I've checked everything several times over, down to the case of the letters and creating the bat file both from a DOS window and via WordPad.
Many thanks for looking into this, but please don't spend any more time on it now as it has to be something I'm overlooking, though I can't imagine what. I'll repeat the exercise on another machine as soon as I can, and if I find out what's going on I'll report back on this thread.
The mystery has just been solved - and as was perhaps inevitable, it looks as though I inadvertantly created the problem myself.
When I originally tried this out, I first set up an association (via Windows Explorer | Folder Options | File Types) to enable me to edit BAT files from WordPad, to save myself the bother of opening a DOS window to do it. However, a side-effect of doing that was that JMP simply passed the file to WordPad - so I shrugged, deleted the association again and forgot about it.
Unfortunately it appears that simply deleting an association to a BAT file after it's been created doesn't restore the way that Windows deals with them to what it ought to be - and that caused several new problems, including the one I've reported here.
Internal Support here have just dealt with it by running a registry fix on this machine - and JMP now handles the BAT file exactly as has been described earlier on this thread.