How to close a CSV file if it is already opened.

[rolfk]

Look you could kill Excel and that would make sure the file is closed, but I assure you that your user is going to swear at you for killing his application behind his back. It's simply stupid programming!

If the user opens that file in Excel to view it, edit it or whatever else he might be doing, Excel locks the file for any other application to open, even for reading only. That's the way Excel works in order to be always able to access the file in a consistent state. If the user then goes and wants to open that same file in your application, he has to make sure to close the file. You could get sneaky and open an ActiveX connection to Excel, try to enumerate every document currently open, see if the document you want to open is part of that list, then open that document reference over ActiveX and close it behind the back of your user, who will then be dumbfounded that his Excel application seems to flicker every time he uses your application, and the file he had open before, sometimes simply disappears from his open Excel. And you also have to properly close the Excel ActiveX reference to make sure you don't close Excel itself. If the user has changes made to the file, he will get anyways a dialog if he wants to save them to the file!!!

All in all it would probably be easier to simply load the Spreadsheet file in LabVIEW directly, display it to the user in a table to view, similar to what he would see in Excel, may detect if he made changes and save them back to the file, and in that way get rid of Excel altogether, than trying to be sneaky with a users application. 

[billko]

IMHO, even if you did somehow succeed in closing the file without any pop-ups or anything, you'll risk scrambling or deleting your data.  (Not to mention wasting the user's time closing a file that obviously he/she wanted open in the first place.)  To me, a pop-up is the ONLY solution that fits here.

Everything I can think of - temporarily storing data until the file is available, etc, etc - are just variations on this same theme.

[Ben]

Another approach...

IF

The open attempt gives you an error because the file is open by Excel...

THEN

Copy the file to a new temporary name and work from the temp file.

But even that approach should still have a pop-up saying "File is open in Excel, any change not saved to disk will not be applied".

Ben

[StevenD]

---

@rolfk wrote:

Look you could kill Excel and that would make sure the file is closed, but I assure you that your user is going to swear at you for killing his application behind his back. It's simply stupid programming!

If the user opens that file in Excel to view it, edit it or whatever else he might be doing, Excel locks the file for any other application to open, even for reading only. That's the way Excel works in order to be always able to access the file in a consistent state. If the user then goes and wants to open that same file in your application, he has to make sure to close the file. You could get sneaky and open an ActiveX connection to Excel, try to enumerate every document currently open, see if the document you want to open is part of that list, then open that document reference over ActiveX and close it behind the back of your user, who will then be dumbfounded that his Excel application seems to flicker every time he uses your application, and the file he had open before, sometimes simply disappears from his open Excel. And you also have to properly close the Excel ActiveX reference to make sure you don't close Excel itself. If the user has changes made to the file, he will get anyways a dialog if he wants to save them to the file!!!

All in all it would probably be easier to simply load the Spreadsheet file in LabVIEW directly, display it to the user in a table to view, similar to what he would see in Excel, may detect if he made changes and save them back to the file, and in that way get rid of Excel altogether, than trying to be sneaky with a users application. 

---

You can do even better than that. If you Use the report generation toolkit you can open the file in excel as an unsaved workbook. I had to give this option to a program I was writing where it was temping for the user to check on a test by opening the file in excel. Same problem there, if they opened it in excel, the next time I went to write the file was locked. So I added a big button on the front panel that lets them open it in excel, but not from the file. If they want they can save the new Excel workbook to something that I am not writing to.

[RTSLVU]

---

---

You can do even better than that. If you Use the report generation toolkit you can open the file in excel as an unsaved workbook. I had to give this option to a program I was writing where it was temping for the user to check on a test by opening the file in excel. Same problem there, if they opened it in excel, the next time I went to write the file was locked. So I added a big button on the front panel that lets them open it in excel, but not from the file. If they want they can save the new Excel workbook to something that I am not writing to.

---

You are doing it wrong!

If you use the file primitives that pass a FILE REFERENCE instead of a path the file will be locked by LabVIEW.

Now when the user tries to open it in Excel they will get a message that the file is locked and Excel will offer to open it read only or open a copy and LabVIEW will still be able to write to the file.

[StevenD]

---

@RTSLVU wrote:

---

---

You can do even better than that. If you Use the report generation toolkit you can open the file in excel as an unsaved workbook. I had to give this option to a program I was writing where it was temping for the user to check on a test by opening the file in excel. Same problem there, if they opened it in excel, the next time I went to write the file was locked. So I added a big button on the front panel that lets them open it in excel, but not from the file. If they want they can save the new Excel workbook to something that I am not writing to.

---

You are doing it wrong!

If you use the file primitives that pass a FILE REFERENCE instead of a path the file will be locked by LabVIEW.

Now when the user tries to open it in Excel they will get a message that the file is locked and Excel will offer to open it read only or open a copy and LabVIEW will still be able to write to the file.

---

I'm not passing a file reference, I am creating a new workbook and loading it with the already logged data. It lets people view the data in Excel without tampering with the file.

[RTSLVU]

---

@StevenD wrote:

---

---

I'm not passing a file reference, I am creating a new workbook and loading it with the already logged data. It lets people view the data in Excel without tampering with the file.

---

I understand that, what I was saying is if you passed a file reference to begin with you would not have to do any of that as using a reference locks the file and Excel basically does that for you when you select "Open a copy" instead of "Open Read Only".

[StevenD]

Ohh.. I see. I didn't know that keeping the reference locked the file.

[Ben]

---

@StevenD wrote:

Ohh.. I see. I didn't know that keeping the reference locked the file.

---

The default access mode is "Read/write" and any variation of "write" will block others from opening the file with write access. If the file is opened "read only" then that is a different game.

Spoiler

Sea Story

Many years ago the VMS operating system supported record level locking of fixed length records within a file. DOS and Windows has only support file level locking as far as I know.

Ben