I try to open and excel reference in LabVIEW and then close it after sometime. But the LabVIEW keeps holding the reference and does not release it unless I close the VI. Why is this happening? Is there anyway to force it to release the Reference?
I am checking the error out for any errors. But it is not throwing up any errors.
What are you doing in Excel?
Typically, Labview will hold the reference open only until it is closed. However, this includes any references to any part of excel (excel.worksheet, excel.range, excel.workbook, etc). You need to close each reference explicitly.
It can be painstaking to debug, but you need to manually go through your entire excel-handling section and make sure that every reference is closed.
Are you checking the return value from the close file command? I've had this problem with LV in the past and have found this to be one possible root cause for this problem.
Check out the following example file to see if you are doing things the same way:
labview\examples\file\datalog.llb\Read Datalog File Example.vi
HTH
Related
I have this complex file which have no circular reference at all, but it keeps warning me about them. I have tried everything i know and still not able to find how to fix it.
I deleted every single formula, i deleted all the sheets, and still same error. I tried deleting macros, and everything.
I have uploaded the file here with macro
https://drive.google.com/file/d/1BB7-mKWFwNabiqT-bFXjW7TJHlY0d7Jd/view?usp=sharing
and in case you dont feel safe about macro, here is without the macro
https://docs.google.com/spreadsheets/d/1xX0Fa5mWBeNZ4n8SVz1YBvPooQhFKYj9/edit?usp=sharing&ouid=112399645615818920675&rtpof=true&sd=true
In the menu File, Options you can alter the behaviour in case of circular references. Once you have done this, you can open your file and search for the circular references without problem:
I'm sure that there are different ways to phrase this question, but that is the end result that I want to achieve.
So, I have a setup where code is written in C# and added as functions to Excel. It relies on having a specific .tlb file in the Tools->References that can be found in the VBA window.
While I was testing this, the .tlb file (and the rest of them) was on my local drive, but now that the project is working, I need to transfer it to a network drive. The problem is that I can't find any way to change the actual file (or filepath) that is being referenced - it's always looking at my local path.
I've tried a few things:
Followed the steps listed here https://support.microsoft.com/en-us/help/308340/how-to-check-and-remove-incorrect-project-references-in-the-visual-bas
Tried several VBA codes using the .References.Remove expression. This does not actually remove the reference from the list, it only unticks it.
I've tried to remove the file from my local drive (causing an Excel error that a reference has been moved, deleted or renamed - good) and then add a reference from the new location that I want. This resulted in one of two things:
1) If I try to add it manually - nothing happens, the existing reference remains unticked and nothing new is added (that I know of).
2) If I try to do it via .References.AddFromFile "filepath" expression it ticks the reference, if it was unticked (this does not make the external formulas work), or an error that a reference with such a name already exists, if it was ticked.
Recompile on the network drive with the following silly way.
Open the VBA editor
Go into each module
Insert a line (doesn't matter what you write)
Press ENTER
Remove the line that you've inserted
When finished, in the menu click Debug \ Compile
Source: by Andreas Killer
https://answers.microsoft.com/en-us/msoffice/forum/all/ms-excel-error-cannot-run-the-macro-the-macros-may/3f3106b2-ae60-4d21-ac94-67e54e605922
Is there a possibilty to prevent a user from sending an excel document while it is still opened?
I had to make my document clear certain cells (containing personal data/personally identifiable information). I succesfully did this by using a function that generates a prompt before saving and only saves (and clears the respective fields) when accepting and doesnt do anything when canceling).
However, users can still send the opened document that contains the critical data.
I know it's a stretch, but is there a possibility to prevent this?
Like, with some sort of checksum/encryption shenanigans that corrupts the document while opened, thus rendering a sent copy in this state useless/not accessible/broken. The document would only be "fixed" again when saving (thus erasing the critical data too).
I can only imagine something like this, because forbidding other programs to read an opened excel document seems crazy.
Any help is greatly appreciated. Thanks in advance!
And hello to everyone here! (first post) This place is a lifesaver.
EDIT: For clarification:
1. Users get the excel document.
2. They enter personal data of staff/applicants etc. into it and my document does fancy stuff.
3. An output is generated which needs to go into some other tool.
4. The excel document's purpose is fulfilled and it must clean itself from filthy personal data.
This is achieved as described before. Saving etc. is all sorted out.
The problem I have been told to deal with, is to make it impossible to send the document while it still contains personal data. Closing wipes it, but while open, it still does contain personal data and can be interacted with Outlook etc.
Is there a way to prevent this kind of interaction with the document while still open? Or make the document corrupt while open, so copying it in this state won't transmit any personal data?
and welcome.
Your question is a bit of a strange one and I am not sure what would be the perfect way, but let me try answer and give you some suggestions:
A: You could work with a codeword in a specified cell. When you save a file it will put the word in that cell. When the word is not there.....well, let's say you can create some macro in Workbook.Open event that will delete all cellvalues and saves the file on its current location. Obviously put password on vba coding!
B: A more solid way in my opinion is to work on the file in your personal workspace if possible and upon saving the file create a copy to the shared folder through vba.
Good luck with it.
A: Manipulating the checksum/temp encryption would be quite risky since if your code crashes or is halted and closed the file is either corrupt or encrypted for you aswell, so information might be lost.
B: You could make the file copy to a temp while editing.
C: You can maybe block the save/autosave function of excel so that your editing won't get saved half-way in. (Not really a good solution, but a solution, likely quite easy).
EDIT:
For option C:
Insert this to workbook, it runs as it's named, before save.
Private Sub Workbook_BeforeSave(ByVal SaveAsUI As Boolean, Cancel As Boolean)
//INSERT INSTRUCTION TO REMOVE PERSONAL DATA
End Sub
With this, data is removed before file is saved, so any saved state should be clean. Macro-deactivated workbooks however, cannot solve this problem, so you should maybe also add an event at workbook open that unlocks the sheets via VBA to avoid that flaw.
OK, so far I've uninstalled & re installed Office-2010 3 to 4 times, done hours of research for 3 days with no success. I started getting this error either from Vbscript or Excel VBA, performing the same command that has worked for months. I am not sure what I may have changed, I don't recall changing anything that could cause it but I nailed it down to the ReadOnly:=True parameter. I think something may be wrong with the registry... but re-installing should fix it right? It didn't...
Anyways, very simple command that I recorded on Excel 2010. This command WORKS FINE and the file opens:
Sub Macro1()
Workbooks.Open Filename:="C:\temp\file_9928_131101.xlsx"
End Sub
But when I add the ReadOnly:=True parameter, it does NOT WORK:
Sub Macro1()
Workbooks.Open Filename:="C:\temp\file_9928_131101.xlsx", ReadOnly:=True
End Sub
This is the returned error Run-time error '1004' Method 'Open' of object 'Workbooks' failed:
When I click Debug, the error is at the only line of code.
The file is corrupted. Resave it with another name and change the name in the function. Try that it works and after that rename the file as you want to call it.
It worked for me and I had a corrupted file. The read only shouldn't be a problem.
Putting an answer here for others like myself who have this issue and the normal solutions don't work.
Another potential cause of this is corrupted temporary files. I think it may only apply if the file you are trying to open is on a network drive or other remote host.
Anyway, try wiping your temp folder (as in the one you get to if you type %temp% into Windows Explorer) then restarting the computer.
I have had the same issue with an Access file stored in a local OneDrive folder, referencing an Excel file stored in the same local OneDrive folder. The solution was to move all files into a "static" (i.e., not synchronized, not OneDrive) folder.
Thought that this specific case/application might help someone.
I realise this is late but if you want to open & repair a corrupted workbook automatically use:
Set oWB = Workbooks.Open(Filename:="C:\my\file\path.xlsx", CorruptLoad:=XlCorruptLoad.xlRepairFile)
If you are downloading the file from some external source (eg- email), just open the file directly from the email and then save the file. Try opening the file in macro ...hope it works...it worked for me....:)
I had a rogue excel process that was running in the background. When I killed it from the task manager the code worked. I hope this helps.
I was too, going crazy with Workbook.Open function, getting the weird Open fail error for no obvious reason. My code also did some some copy-pasting after Open function, which seemed to trigger it.
Eventually I found out that turning ScreenUpdating OFF seemed to cause this - keeping ScreenUpdating ON, made things click for me (maybe someone finds this helpful in the future). I'm one of those who tends to switch ScreenUpdating off for all code whenever possible.
Application.ScreenUpdating = False
I know I'm answering late on this, but I resolved a similar issue (same error but running excel from a .Net app) by making sure VBA was installed correctly on the target machine.
Control Panel->Programs and Features->Uninstall a Program... find your Office install, Right-click and select "change" ->Add Remove Features->Office Shared Features->Visual Basic for Applications->Run From My Computer
This did it for me.
I am exporting .bas files from an .xls file as outlined here: Exporting A VBComponent Code Module To A Text File to check them in into an SVN repo.
I am encountering the following issue which causes a change in casing of variable names in the files that is actually not real (or at least not relevant).
Statements like these get reformatted/recased:
rngTenors.Cells(i, 1)
changes into
rngTenors.cells(i, 1)
(subtle but still different and it gets picked up by the diff tool that I use and hides the real changes on the file in the noise that this generates)
Any idea of ways to prevent this from happening would be appreciated.
I'm doing something similar but haven't seen what you are experiencing. I'm not using the same export routines but they look similar at first glance.
A couple of questions.
1) Are you using option explicit, and
do you have a variable named cell
anywhere?
2) If you Commit, then make a few changes, export the .bas file and Commit again, what does the diff look like?
3) Are you opening and diffing the .bas files in a code aware editor (eg: Ultraedit) that may be changing your capitalisation?
I'm just guessing... but VB editor capitalisation can be weird if you name variables the same as methods or properties. Also i don't see why your export would inconsistently export .Cell i'm guessing if it exports to .cell then it should always export to .cell and not be a problem.
These are just some ideas, good luck :)
The VBE keeps an internal cache of variable names, including the casing, so even though you found a variable called cell, and renamed it to be something else, VBA still thinks it is a valid name, and so it is preserving the casing across all usages of that text.
You can trick the VBE into resetting the variable casing (and this also works for casing problems on methods too) by temporarily declaring a variable with the correct casing:
Public Cell as String
And then deleting that variable. You should then find that all of the casings are fixed throughout your project (and any project that refers to it).
Indeed I found something in the code as was suggested above.
dim cell
I have now renamed this variable and no reformats have occurred since. I expect and hope that this has resolved the issue. Many thanks for help!