using "system exec.vi" to get file opened in excel

[longzoo]

NOTE: while typing this up i found my solution but decided to post anyway in case it may help someone else

 

I decided to quit beating my head off the keyboard and ask for help...I have a vi that will eventually be an .exe distributed across a variety of windows xp to windows 7 machines (32 and 64 bit). In this vi a bunch of data is saved to a .tsv file at C: i then need  to open the .tsv file in excel. After some searching i found System Exec.vi. it initially seemed to be my silver bullet because if i open command line in windows and type " excel.exe c:temp.tsv" Excel is opened (and this should work across different versions of Office). BUT with system exec.vi i get an error "Error 2 occurred at System Exec.vi Command was "excel.exe c:temp.tsv" Possible reason(s): LabVIEW: Memory is full." blah blah blah...

If i replace "excel.exe" with Notepad it opens the data no problem with notepad but i need it to be in Excel. i read about using "cmd /c" and attempted to no avail

 

Here's where i found my issue... it is "cmd /c" NOT "cmd c" ! so i used "cmd /c c:temp.tsv" and voila it opens with the default program for .tsv (which is obscure enough that i can make Excel a default on all of the computers in the building) for some reason cmd /c excel.exe does not work to open excel. i found this odd as excel.exe entered directly in the command line will open excel regardless of which version you have installed, but i believe i can live with this. 

[Mellroth]

Here's where i found my issue... it is "cmd /c" NOT "cmd c" ! so i used "cmd /c c:temp.tsv" and voila it opens with the default program for .tsv (which is obscure enough that i can make Excel a default on all of the computers in the building) for some reason cmd /c excel.exe does not work to open excel. i found this odd as excel.exe entered directly in the command line will open excel regardless of which version you have installed, but i believe i can live with this. 

 

Instead of using the command line, you can use the "Open URL in Default Browser" VI in LabVIEW.

You'll find this in the "Dialog and User interface"->"Help" palette (or in Quick drop).

 

This VI is polymorphic, and accepts a path or string as input. When given a path it opens the path using the default program for that file type. 

It even works with path to folders, allowing you to open a specific folder from your application.

 

/J

[JamesMc86]

Instead of using the command line, you can use the "Open URL in Default Browser" VI in LabVIEW.

You'll find this in the "Dialog and User interface"->"Help" palette (or in Quick drop).

 

My new thing learned for the day, theres always something else I didn't know!

 

I don't know the exact windows in's and out's but you need the cmd /c because the system exec is the equivalent of the command going into the run... dialog NOT the command line. cmd /c is what causes it to execute as if from the command line.

[hooovahh]

I don't know the exact windows in's and out's but you need the cmd /c because the system exec is the equivalent of the command going into the run... dialog NOT the command line. cmd /c is what causes it to execute as if from the command line.

According to the the help, the "/c" adds the following "Carries out the command specified by string and then terminates".  If I run cmd, then type in "Copy ab.txt cd.txt" it will perform the copy and the command prompt window will remain open.  By performing a "cmd /c" it will cause the "cmd.exe" to close after the operation is complete.

[Phillip Brooks]

.NET to the rescue...

 

http://msdn.microsoft.com/en-us/library/system.diagnostics.process.start.aspx

 

 

Launch Windows File.vi (LV 2012)

[longzoo]

Philip...that is AWESOME! It's much better and easier than my clunky workaround. 

many thanks!

Dave

[Chris]

Using the .Net solution worked really to OPEN a (PDF) file, but I also need to automatically CLOSE the file afterwards.

 

I used the Reference from the START method  and then tried the CLOSE, DISPOSE, and KILL methods, but none of them actually closed the file.

 

Can .Net come to the rescue again - what am I doing wrong?  If there is no method of Closing the file I guess we could Kill the application (in this case Adobe Reader), but it's not as elegant.

 

Chris

[Rolf Kalbermatter]

Using the .Net solution worked really to OPEN a (PDF) file, but I also need to automatically CLOSE the file afterwards.

 

I used the Reference from the START method  and then tried the CLOSE, DISPOSE, and KILL methods, but none of them actually closed the file.

 

Can .Net come to the rescue again - what am I doing wrong?  If there is no method of Closing the file I guess we could Kill the application (in this case Adobe Reader), but it's not as elegant.

 

Chris

 

There is no general agreed method to close a process from another process. If it is a GUI application, sending it a WM_CLOSE message might work but for some applications just as likely might prompt with a dialog if you really want to close. Command line apps expect a ctrl-C to terminate prematurely but might disable the ctrl-C console handler for whatever obscure reason. 

 

The only way that will (almost) always work is to try to kill the process. Almost, because if the process is stuck in some call to kernel mode code it may never receive the kill signal.