I am about to submit my big VBA project in Excel, and have come across one last concern.
I have protected all my macros, but how can I set this Excel so that users cannot either A) Access the 'Developer' Tab, or B) Create new macros?
You can't.
I mean, you can try, and probably stop an accountant or sales analyst from looking at or editing the code, but you won't stop anyone that wants or needs to go in.
In other words "protecting" the VBA code will only annoy you, the maintainer. It will prevent a cat from accidentally accessing the code, but anyone with access to a hex editor (or not) will laugh at it.
Unless you're using some good 3rd-party tools to obfuscate/encrypt/protect (/corrupt) your VBA project (listing 3rd-party tools is beyond the scope of this site)...
VBA code is not secure, full stop.
Related
I have written some VBA for Excel which I'm sharing with colleagues by manually exporting the .BAS files from which they manually import.
Having just discovered I can use VBA to automate this process myself - see here at Ron de Bruin & and here at Chip Pearson - so it seems to me I can set up my colleagues machines to check for any changes when Excel opens and update the modules in their PERSONAL.XLSB file.
QUESTION: My questions is whether there are any pitfalls in doing this that I might not be aware? (Aside from the obviously need to keep the code-hub secure)
I've completed most of the development now (after 75 increments) and changes are only about once a month so the overhead of updates are bearable. However it may be possible to distribute code in a similar way.
BTW: I search the Stack Overflow for similar questions, the closest I got was - Replacement of old modules with updated ones in PERSONAL.XLSB
Thanks.
My overall setup is quite involved, so here is my attempt to pin-point the precise part that I'm stuck on.
For whatever it's worth, I will have much respect for whoever can figure this out. I think that the solution requires an esoteric understanding of Excel Add-Ins.
The Background:
Here is the relevant universe of files that I am dealing with:
Filepath_2\UI_2.xlsm
Filepath_1\CI_1.xlsm
Filepath_1\AI_1.xlam
Filepath_2\CI_2.xlsm
Filepath_2\AI_2.xlam
Filepath_2\UI_2.xlsm is the file that is running the VBA to accomplish the desired file operations on/in the other four aforementioned files.
Filepath_1\CI_1.xlsm contains a reference to Filepath_1\AI_1.xlam.
My goal is to...
Copy Filepath_1\AI_1.xlam to Filepath_2\AI_2.xlam
Copy Filepath_1\CI_1.xlsm to Filepath_2\CI_2.xlsm
Open Filepath_2\AI_2.xlam
Open Filepath_2\CI_2.xlsm
Remove, from Filepath_2\CI_2.xlsm, the reference to Filepath_1\AI_1.xlam
Set, in Filepath_2\CI_2.xlsm, a reference to Filepath_2\AI_2.xlam
... handle business in Filepath_2\CI_2.xlsm ...
Close and delete Filepath_2\CI_2.xlsm and Filepath_2\AI_2.xlam
... and, I am able to accomplish all of the above save for one minor snafu:
The VBA project for Filepath_1\AI_1.xlam is opened upon opening Filepath_2\CI_2.xlsm and I cannot figure out any way to close it.
The Question:
What is the required VBA code to close the VBA project for Filepath_1\AI_1.xlam?
It is worth mentioning that my current inability to close that VBA project is not adversely affecting anything for the time being, so this is really a matter of control and process cleanliness for the longer term. I simply do not want a stray VBA project remaining open.
I can be somewhat flexible about the order of file operations that I mentioned above, as long as it culminates in the last three steps of it:
Set, in Filepath_2\CI_2.xlsm, a reference to Filepath_2\AI_2.xlam
... handle business in Filepath_2\CI_2.xlsm ...
Close and delete Filepath_2\CI_2.xlsm and Filepath_2\AI_2.xlam
Just one pre-emptive note to save everyone's time: Please do not suggest changes to the current suite of filepaths as the desired solution cannot interfere with the rest of what needs to be done. This file setup is part of a much larger situation that handles business in secondary copies of master files, after which the secondary copies must be closed and deleted.
This is my first question on Stack Overflow. I've attempted to make it self-contained as well as be free of actual VBA code since I don't think that someone who knows the solution I've asked for needs my own code to provide the few lines of code that most likely comprises the solution.
If you think you can help me out but need more information or some actual code, please let me know. Thanks!
Edit:
Thanks for your comments so far. Allow me to clarify further, and I think that this really gets to the crux of the matter. I've also edited my original question to correct some minor inaccuracies.
I earlier misstated one of the steps above as:
Close Filepath_1\AI_1.xlam
I don't attempt to do this anywhere.
Once I open Filepath_2\CI_2.xlsm, it has a reference to and shows the VBA project for Filepath_1\AI_1.xlam; the problem is that Excel does not, at any point, recognize Filepath_1\AI_1.xlam as an open file.
In fact, even if I open Filepath_1\AI_1.xlam by its mere self (without opening up any files that reference it), Excel does not recognize it as an open file, although it opens up the VBA project for the file. By 'recognize', I mean that if I use a For Each loop to cycle through the open add-ins (or open workbooks), Filepath_1\AI_1.xlam never shows up.
What I'm trying to do seems like it should be quite doable, and yet I just cannot find any way of doing it that doesn't leave that stray VBA project open...
I'm working on an Excel VSTO add-in in VB.Net. I am trying to address the question of knowing which workbook my add-in should be effecting given that a user may open or close many workbooks before, after, or during use of my main form.
The main functions all center around editing a main template file, which the user presumably the saves with useful names, and might come back to for reference or further editing. The add-in opens a form and performs various functions like adding information from a database to a worksheet, or adding sheets to a workbook (and lots of stats). Much of what I'm doing relies on calling a particular workbook:
CurrentRun = Marshal.GetActiveObject("Excel.Application")
CurrentBook = CurrentRun.Workbooks(CurrentIndex)
Where CurrentIndex is the index from a combobox which is populated/updated with names of the currently open workbooks:
...
ControlCurrentWBComboBox.Items.Clear()
CurrentRun = Marshal.GetActiveObject("Excel.Application")
For n = 1 To CurrentRun.Workbooks.Count()
ControlCurrentWBComboBox.Items.Add(CurrentRun.Workbooks(n).Name)
Next
CurrentRun = Nothing
...
This requires the user to select the workbook (by name) that they want to be working with. This seemed like a good idea until I put it in front of 8 different users today. Most eventually got used to having select the workbook, but not without a lot of grumbling and throwing errors (which were well handled). 2 users never got it, and were continually accidentally editing the wrong workbook, and throwing errors an hour into use.
Is there a better way to handle this? I'm thinking of trying to make two versions: one with the above and one for people who need fewer options. Is there a way to force a sort of 1-to-1 relationship you can get by putting VBA code in the workbook itself?
Am I way of base by even trying to deal with this or referencing anything other than ActiveWorkbook?
[Note: I'm a little scared by the blue warning that's telling me this is a subjective question. I'm not meaning for it to be; perhaps I need help with the wording?]
If your Add-In does not "just work" with any open workbook, then you probably should not be using an Application Add-In; rather, you should be using a Document Add-In.
In this scenario, if the user has 3 workbooks open (that each have the Add-In), they will each operate in their own domain -- as If the others don't exist.
If this is an option in your environment, I would strongly recommend it as a Best Practice.
It could be cumbersome at times to maitain Excel Workbook's formatting/settings when heavy backend, front end work loads are done. At times (even frequently) workbooks were crashed. But I can't recall what the code or process was to avoid this happening due to the formatting. What I am clear is that before any data retrieval, processing took place in the workbook, I saved the Workbook's formatting/settings into an object. Once everything was completed, that object was called to restore. It was most probably one of the custom/user written classes.
That code was very handy when working with Workbooks to manage certain company standards/Logos/Colour Pallete/formatting/protection settings/code settings and so on.
So I just want to ask if anyone in the community have come across such process? I searched online and disappointing enough I am unable to find anything near - else I have really lost my wits on key-word search ;)
PS: This is not my home work or work. So please throw some light.
If you are talking about creating spreadsheets that conform to your branding standards, why don't you just create a template file:
http://office.microsoft.com/en-us/excel-help/save-a-workbook-or-worksheet-as-a-template-HA010218874.aspx
Just as the title says, I see a lot of editors touting macro recording as a feature but cannot find a way to take advantage of these functions myself. So what can you use it for? The type where you can record mouse movement and/or keystrokes? Is it really that helpful to people out there? Specifically, I deal with Eclipse which has a number of built in "fill in" functions, so I really don't see what the advantages could be.
I use them all the time. Say, for example, I want to go down a list, indenting by 4 and adding a "|* ". In EMACS, I hit C-x ( to start recording, do one example line to see that it's what I want, ending with C-n C-a to move to the next line, and end the macro with C-x ). Then C-x e repeats it line by line, and C-u number C-x e does it many times.
Depends on what you are doing and what language you are work with. As a simple example, right now I am working with a Visual Basic .NET application that has a number of queries in it. I generally do all of my work with queries in Toad, but Visual Basic .NET has an annoying syntax when it comes to long strings, namely:
Public Const SelectData As String = _
"SELECT * " & _
"FROM myTable " & _
"WHERE myField = :SOMETHING"
Since I really don't like editing the queries when I copy them out of the code or pasting them back in, I have some macros that will automatically format or strip the formatting from them.
Also, some of the macros can be used to automate common tasks that you need to do around the IDE while you are working. Any sequence of commands that you see yourself doing often is something that you can turn into a macro and do with just a single click.
Waaaay back I used a macro to make function header/comments. Other than that I have not used them.
Basically you can "automate" tedious things you do often that do not have built in ways to do the tasks you do frequently. It is a flexible way to give lots of power to people so they can work more efficiently.
I find it very useful in microsoft excel. Rather then having to look through documentation to find every object and function I need to call I can record a macro that does most of what I want, take that code and modify it to give me finer control.
In Visual Studio, I use macros for many different purposes. One of the most valuable comes when debugging Windows service. I can use the macro engine to start and then attach to the Windows service which just a click of a button.
Also, sometimes I use custom DEFINES that need to be exploded into code--sort of like C/C++ macros.
Colby Africa
I don't use them in Eclipse either.
Here's why:
Eclipse has many powerful built-in functions and refactorings. So with code, its not necessary.
Eclipse macros aren't that great. You can record them, but its hard to tweak them and do exactly what you want.
Macros become more useful in things like modifying files that aren't code. For that I tend to use something like vim. Also, you have to actually practice using macros to recognize when they will help.