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:
Related
Based on knowledge gained through working with the OpenXML SDK, I have implemented an Excel generator in JS (using TypeScript with ReactJS and a custom JSX factory generating plain XML). The files generated open fine in Excel and one can also edit and save them fine in Excel, no errors.
However, if one tries to copy cells (even a single one) from such a generated Excel file to another worksheet in the same Excel instance, it fails with the error "The command cannot be used on multiple selections.". Just saving and reopening the file is enough to fix the problem. Copying to other applications (e.g. Notepad) works fine.
It seems that this particular error is shown by Excel in several edge cases where the data is not exactly meet the expected format, for instance I found reports of that happening when a sheet is hidden when manipulating it via VBA. However, in my case I'm not sure what could be causing the issue.
Just saving the file in Excel unfortunately significantly alters its parts, so that I couldn't get a meaningful diff out of it. I did not see what could be causing the problem. Maybe someone has some experience with the internals of Excel?
To get a sample file, copy the following into your browser address bar and save it as xlsx file:
data:application/vndopenxmlformats-officedocumentspreadsheetmlsheet;base64,UEsDBBQAAAgIAAAAAAA69A4d5wAAAGYBAAAPAAAAeGwvd29ya2Jvb2sueG1sjZA9T8MwEIZ3JP7DyTt1AAmhKEkXBOqCMgC7Y1+SU/0R3bktPx+3ocxM9/k+9+qa7XfwcEQWSrFV95tKAUabHMWpVZ8fr3fPCrbd7U1zSrwfUtpDEURp1ZzzUmstdsZgZJMWjGUyJg4ml5InLQujcTIj5uD1Q1U96WAoqpVQ838YaRzJ4kuyh4AxrxBGb3KxKzMtoro/Zz3rrrmck98Ikk3GVh1JaPCoIJpQyi/CE/SHwZNdQZBGeGOcEpOJoOAi3rnyDwVcU0l45x5Vwesr3+FIEd17AUrpW+Ntz3AOZ1112b0a634AUEsDBBQAAAgIAAAAAAD2SCbhNwEAAMYCAAANAAAAeGwvc3R5bGVzLnhtbJ1STWvDMAy9D/YfjO+rk8DGGEl6KAR22aUd7OokSmvwF7Zbkv36yXFK20EZ7GJJz++9KLLK9agkOYHzwuiK5quMEtCd6YXeV/Rz1zy9UrKuHx9KHyYJ2wNAICjRvqKHEOwbY747gOJ+ZSxovBmMUzxg6fbMWwe891GkJCuy7IUpLjStS31UjQqedOaoQ0UzyupyMPqCFDQBSOUKyInLim64FK0TkevF9wLmeaxZ4qazvQBz8HghpLz1RqAuLQ8BnG6wIEu+myxUVBsNyGJXhGg2hz+ke8envHi+p54DdtQa1+PYzz3l9Awh5VeC7A6k3MYX+BpuJONA0ijf+zhFEn/3nOJ3ljTZpCLO5toteV/ZFv+yJdxaOX0cVQuumVcgNcjG4b5dftduEbKlt7rsx+F2W9hlIesfUEsDBBQAAAgIAAAAAABh+IC4iAEAAGIDAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1shZNNT8MwDIbvSPyHKCc4sGzdxsfUFsEQEhJCSOPjnKXeFtEkVWLY4NfjtKUaaBqXyLXzPn7jpOnlxpTsA3zQzmZ80OtzBla5Qttlxp+fbk/OObvMDw/StfNvYQWAjBQ2ZHyFWE2ECGoFRoaeq8BSZeG8kUiffilC5UEWtciUIun3T4WR2vI8rXMvGtZhK2Yo5zMoQSEUZIWz2HLu3Fss3lGqT8pKWmCbWVVqjAn22Ya0HV11DwucQllm/CrhTCrUH/BIiozPHaIzsc5ZQImUWnj3BZYLslB3pQmw6u9mqorO4XZMzpUrm5UZbWsLRm4a57rAFUXD3tlglJyPu5Uz9R6I/dpuiPwOkLSApAOMkz+A8V7AsAUMtwFb3Wnd72DUAkYd4CLZJRDN0eth3EiUeerdmvn67IFmSM9jMBnRdamYvIrZ5ooyrm2pLczQU1UTA3MCADt6fpoepwKJHbNCtdrr/dqpK2CHarpf9SDNLtXNPz4hKK+r+E5+iwUd/udpNNMQ3d+SfwNQSwMEFAAACAgAAAAAAI86L6y8AAAAmQEAABoAAAB4bC9fcmVscy93b3JrYm9vay54bWwucmVsc7WQSwrCMBBA94J3CLO3qQoiYupGBLdSDxDSaRvaJiETP729KYJacOHG1TC/N4/Z7u5dy67oSVsjYJ6kwNAoW2hTCTjnh9ka2C6bTrYnbGWIQ1RrRyxuGRJQh+A2nJOqsZOUWIcmdkrrOxli6ivupGpkhXyRpivuPxmQjZgs7x3+QrRlqRXurbp0aMIXMKfQt0jAcukrDAKeeRI5wI6FAH8sFsD/dv5mfUM1YngbvEpRbgjzkcxykOGjB2cPUEsDBBQAAAgIAAAAAABja/EoqQAAABkBAAALAAAAX3JlbHMvLnJlbHONz7EKwjAQBuBd8B3C7Tatg4g07SJCV6kPENNrGtrmQhK1vr0ZVRwcf+6/D/6yXuaJ3dEHQ1ZAkeXA0CrqjNUCLu1pswdWV+tVecZJxlQKg3GBpS8bBAwxugPnQQ04y5CRQ5suPflZxhS95k6qUWrk2zzfcf9uQPVhsvbp8B+R+t4oPJK6zWjjD/irAayVXmMUsEz8QX68Eo1ZQoE1nQDfdAXwquQfA6sXUEsDBBQAAAgIAAAAAAAUVUFPBQEAAJkCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbK2Sv07DMBDGdyTewfJaxU4ZEEJJOkA7AkN5AONcEiv+J59b0rfHcQsDKmXpdLLv+77fneVqNRlN9hBQOVvTJSspAStdq2xf0/ftpnigZNXc3lTbgwckSW2xpkOM/pFzlAMYgcx5sKnTuWBETMfQcy/kKHrgd2V5z6WzEWws4pxBm+oZOrHTkayndH0kB9BIydNROLNqKrzXSoqY+nxv21+U4kRgyZk1OCiPiySg/Cxh7vwNOPle01ME1QJ5EyG+CJNUfNL804Xxw7mRXQ45M6XrOiWhdXJnkoWhDyBaHACi0SxXZoSyi8t8jAcNeG16Dv2HPG+eDchzWV55iJ/87zl4/mjNF1BLAQIUABQAAAgIAAAAAAA69A4d5wAAAGYBAAAPAAAAAAAAAAAAAAAAAAAAAAB4bC93b3JrYm9vay54bWxQSwECFAAUAAAICAAAAAAA9kgm4TcBAADGAgAADQAAAAAAAAAAAAAAAAAUAQAAeGwvc3R5bGVzLnhtbFBLAQIUABQAAAgIAAAAAABh+IC4iAEAAGIDAAAYAAAAAAAAAAAAAAAAAHYCAAB4bC93b3Jrc2hlZXRzL3NoZWV0MS54bWxQSwECFAAUAAAICAAAAAAAjzovrLwAAACZAQAAGgAAAAAAAAAAAAAAAAA0BAAAeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJlbHNQSwECFAAUAAAICAAAAAAAY2vxKKkAAAAZAQAACwAAAAAAAAAAAAAAAAAoBQAAX3JlbHMvLnJlbHNQSwECFAAUAAAICAAAAAAAFFVBTwUBAACZAgAAEwAAAAAAAAAAAAAAAAD6BQAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLBQYAAAAABgAGAIABAAAwBwAAAAA=
Well, I don't know the particulars of how you are generating the xml file, but I can tell you how to edit the underlying xml files so that it will work, and then perhaps you can figure out how to use your implementation to change the property that's gunking things up.
First, an xlsx is a set of xml files. I'm sure you know that, but I'm just starting at the beginning. You can change the extension to zip and then extract the files, and then rezip them and change the extension back to xlsx.
So do this:
take the generated xlsx
change the extension to .zip
extract the files
find xl\worksheets\sheet1.xml
open it and find this property: worksheet>sheetViews>sheetView:tabSelected
set it to 0
save the file
go back to the unzipped folder
select all files and send to zip
change the extension on the new zip file to .xlsx
You should now be able to open the newly created xlsx, add a new sheet, and copy freely.
If this works for you, then you have diagnosed the problem, one property set to true when it shouldn't be, and it should be relatively simple for you to modify your export procedure.
I've had this issue multiple times in the past.
The way I solved it was by filling out (populating) a template (file, previously created in Office) with the exported data rather than generating a file from scratch. Office unfortunately does not fully comply with OpenXML, and for more complex exports you might even be unable to open the file.
I would also recommend Beyond Compare (now Scooter Software) for comparing the two files instead of just doing a diff.
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.
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!
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