Executable will not WRITE to spreadsheet

[Murph]

LV2016.

Application reads from XL spreadsheet, finds a field based on searching row label, pulls and manipulates data, then updates one field of the spreadsheet.

Works like a charm in development mode. I've also ran the exe on the pc running LabVIEW.

Transported to target PC, installed runtime libraries. Nothing errors.

Calls spreeadsheet, pulls data as expected but will NOT write back to it!

[Gregory]

Are you getting any errors out of your write function? (assuming you are handling your errors).

My first guess would be that the file to be written was installed as "read only", and you don't have permissions to write to it.

Any further guesses would require a look at your code.

[aeastet]

Depending on what operating system and where you are storing the file, you may not have permission to write to the file. You need to be careful where you place files now in Windows. It does not allow you to edit files in certain locations on your computer without having to do extra work to make it allow access.

[altenbach]

---

@Murph wrote:

LV2016.

Transported to target PC, installed runtime libraries. Nothing errors.

Calls spreeadsheet, pulls data as expected but will NOT write back to it!

I don't know what "transported" means. Did you create an installer and install the exe on the target system? What is the actual full path of the file?

[Murph]

I believe it has something to do with that.

My dev station is Windows7, the target machine is Windows10

I am doing file exchange with a folder called  C:\LN Files

[altenbach]

Yes, newer windows versions discourage the use of the root folder. Does it work if you run the exe as administrator (right-click...run as administrator). Even if you have admin privileges, the exe might not.

[Gregory]

I would create an installer, then select the file you want the user to be able to write to (here it is config.ini) and check the "unlock" button.

[Bob_Schor]

@gregoryj:

     Thanks for the picture.  I've built a number of executables, but have not (yet) had to "drill down" to such detail to even realize that all those settings were available.

     My tendency has been to keep "rarely-changed" data, such as Configuration files, in "User-space", either in a defined Public Folder (which is where I tend to install the Executables, e.g. <Public>\LabVIEW Builds\<Project>\<Executable>\<Files go here>) or in a defined Data Folder accessable to the User.  So far, this has worked well and has required little variation in going from Windows XP -> Windows 7 -> Windows 8.x -> Windows 10.  But next week, Microsoft could change the rules yet again ...

Bob Schor

[Steffen01]

default seems to be c:\users\name\Documents, best chance to have write permissions in there.

Other thing could be the document is not closed i.e. held open by something. Plus firewall/virus scanner paranoia towards your compiled version. Seems Windows 10 blocks more things than WIndows 7.

[Murph]

Frustrating!

I went back and added a bunch of error traps, LV does not generate the error. It appears to be something with Excel itself.