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!
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
I have a DOORS DXL script that (used to) export data to an Excel worksheet. It uses the filename specified/chosen through a GUI and tacks ".xlsx" on the end.
Well, the file is created and written to by the application. You cannot, however, open it with Excel, as the application complains
that "Excel cannot open the file 'Output.xlsx' because the file format or file extension is invalid." You can open it with Word 2016
and the text is totally readable. (??!!!)
This script was last used/modified in 2011. I believe the DOORS version was 9.1 on that project. Is that a contributing factor? (Using DOORS 9.6 on current project)
Anyone have any idea what debug steps I should take?
Thanks,
T Wilk
I tried exporting to .xls, and it worked, sort of... I had other problems to work through, so maybe if I went back and tried it again, now that those are solved, it would be fine.
Found out some interesting stuff today. I changed the 'file create' extension to .tsv, made my delimiter "\t", and the export worked beautifully. And .tsv files can easily be saved as .xlsx. Don't know what changed between DXL and Excel since the last time I used them together, but the straight export to .xlsx is not an option.
I also learned, since the last time I did this sort of thing, i.e., DOORS to Excel, that API's have been created so that you don't have to bother with setting up the
export in your code. Someone pointed me to some Mike Sunderland code (Galactic Solutions). I'm going to pick that apart tomorrow.
Got a lot to do, and I'm having fun!
Thanks for the time and interest.
Tara
So I have a solution that compiles and runs fine.
But the Error List window is always maxed out
(Last line in window: "Maximum number of errors has been exceeded.")
And they're totally crazy error messages like:
'End Function' must be preceded by a matching 'Function'
'Try' must end with a matching 'End Try'
'If' must end with a matching 'End If'
'Catch' cannot appear outside a 'Try' statement.
Statement cannot appear within a method body. End of method assumed
When I double click any of the errors, it just takes me to the first line of my class file.
I might not be the best developer in the world, but I'm not making mistakes like the Error List window says I am!
I copy/pasted the entire class file to notepad, save the text file, closed the text file, opened the text file and copy/pasted back into the class file...no more crazy Error List.
After I went through this process, I found out that you can choose "Save As" from VS, and there is a little arrow next to the Save button that lets you set the encoding.
So I'm guessing it was an encoding thing...the original class file has been in the project since Visual Studio 2003...no issues until VS2012...go figure!
Thanks everyone!
This started happening to me after reinstalling my system.
I think GoDogGo's solution of changing the file encoding is probably valid (I found I had a mixture of different encodings at work). Intellisense was showing errors that didn't match up to the right character positions in my source files.
I also had issues with types not being recognised, such as 'Data.DataTable'. I found I had included an un-encoded ampersand in the value of a web.config appSetting entry (it was part of a folder path). I think the compiler probably knew about it but didn't include it in the visible list of errors in the IDE's error list.
Once I had corrected the ampersand encoding and rebuilt, all the other errors disappeared.
I'm trying to localize a large MFC project where all the strings are hard-coded into the source code. (It was the easiest thing to do at the time, back before we had any idea we'd expand into other markets.) I've looked at localization tools, and invariably they say to put all the strings into the .rc file first, or just assume it has been done. Of the ones I've checked, appTranslator is the only one that even hints it may be a problem, and provides a couple of convenience functions to cut down on the wordiness of the resulting source code.
Does anybody have a better idea than going through hundreds of files manually, and making the occasional mistake along the way?
Is there some sort of product out there to help?
Does anybody have experience with doing this?
It is a tedious process to be sure. I participated in an effort like this many years ago. We did it manually. You can probably write some common code that makes the loading, checking, etc all pretty clean with minimal bloat.
I don't know of any products that will do it for you.
CStrings might be your friend - using the LoadString() member.
I would either derive from CString or write some other code that encapsulates default values (their current hard-coded values probably) and other error conditions and then use that in place of the hard-coded strings.
If you prefer not to use CString, then deriving from std::string and using the global LoadString() works fine too.
as for tools:
not sure they will work for your case:
http://www.modelmakertools.com/articles/hard-coded-strings.html
apparently this tool can find all the strings in your exe files:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
Then you can search for them and replace.
I think writing a tool would be fairly straightforward - look for " character and then create an entry in an rc file that corresponds to the .cpp or .h file it came from. You will have a lot of culling to do, but it is a start. You can do a replace of the text, or insert comments, etc. You can use the line number and file name for the resource id/name in a #include.
I know it's too late but just for the search engine.
There is a feature of CString to initialize it from a resource ID.
CString((LPCTSTR)IDS_RESOURCE_ID)