I have three modules (standard module, not class module) in my Excel VBA project. One of those was added by right-clicking the VBAProject and insert a module. Two of them were added by executing "modules.add"; I guess modules means module sheets, right? So, my questions are:
1. What does a module mean in VBA?
2. How can I know which module is created while adding a modulesheet?
3. Why when I add a worksheet,there isn't a module appear?
A module is simply a place to put your code. You can just see it as a sheet of paper where you can write something.
In Excel you can put your code in a module, or "behind" a worksheet (what you call a modulesheet). A module is always added manually BY YOU. The "modulesheet" is part of a sheet and thus added or deleted BY EXCEL automatically whenever you create or remove a sheet
When you put some code and variables in a module, its instantly available from all worksheets within your workbook, dependinv on how you declare your variables, subs and functions (private/public)
Usually when one put code behind a worksheet, its because this code is only meant to be called from that particular worksheet and only perform operations on it. I personnaly never work on worksheet level for several reasons:
if you delete your sheet, you lose all code that was behind it.
if you export a sheet, you export the code as well.
if you duplicate a sheet, you duplicate the code as well.
if you want to run the code behind a particular worksheet from another place, you have to fully qualify your calls and variables, which is a horrid solution and also plain boring
My advice is: IN EXCEL, never work on sheet level, uses modules, and if you reach a decent amount of code, organise it in logical groups using multiple modules
RE 1: A module is like a singleton class which has already been initialized, so to speak. In other words a module's code (public properties/variables, public methods, etc) is always available, one does not have to inherit an instance before tries to use it, however, all the data in a module's properties/variables are common "application-wide"
RE 2: It is "sheet module", not "module sheet". This means nothing but the newly added sheet has a module with it when you add it. There's no difference between having this, or adding a module to the sheet later. You can open the code editor window and see modules, classes, etc by pressing ALT+F11
RE 3: By default no VBA code is added to any new sheet because of security reasons. If a Workbook has macro (VBA code) in it, extra attention is required so by default a workbook is not a VBA(macro) workbook.Last but not least, please note that there's no difference between one module or another. The way you create a module does not affect the way modules behave, and there's only one "type of module" (as well as one "type of class module") in Office applications (Excel, Word, etc)
for number 2:
Sub moduleAdd()
Modules.Add
'Modules.Add
qq = Modules.Count
MsgBox "total added module by code = " & qq
For ii = 1 To qq
Set modu = Modules(ii)
If ii = qq Then MsgBox "Newly added module = " & modu.Name
Next
End Sub
Related
I have created an Excel Workbook with a lot of VBA code for a customer. The customer will provide me with data. I will import that data into the VBA laden template, Save it as an xlsm, and deliver it to the customer. I get paid by the Workbook so I need to prevent them from trying to copy new data into the existing workbook and reusing it.
How can I somehow prevent the customer from reusing a workbook by just entering in new data on the main Worksheet, then saving as a new Workbook, and getting the use of the VBA code for free. (Alternately they could copy the file in windows then enter new data on the copied version.) I need to detect a significant change in data from the initial imported data.
The data on the main sheet is fairly static (perhaps even totally static on many known columns). I'm thinking about randomly sampling some of the cell data on import (perhaps 10 random cells, or number of rows, etc.), and storing that data somewhere. If, say, 50% of the cells change data, I could just disable (or short-circuit) the public entry points in the code...or something else?
I'd like to allow for some flexibility on the part of the customer, but prevent abuse.
Is there a better way than my general idea, above?
Where could I store that data (it should be part of the sheet, but not changeable by the customer). Perhaps a hidden sheet with password locked cells?
Is there some accepted way of doing this that I'm unaware of?
Perhaps Time-expire the functionality in your code
So thank you for this question. Thank you for setting a bounty. It is a very interesting question given your desire to monetise the VBA code, as a VBA programmer I generally resign myself to not being able to monetise VBA code. It is good that you insist and I will contribute an attempt at an answer.
Firstly, let me join the chorus of answers that say VBA is easily hacked. The password protection can be broken. I would join the chorus of respondents who say you should pick a compiled language as the vessel for your code. Why not try C# or VB.NET housed in a Visual Studio Tools For Office (VSTO) .NET assembly?
VSTO will associate a compiled assembly with a workbook. This mechanism is worth knowing because if you insist on VBA we can use the same mechanism (see later). Each workbook has a CustomDocumentProperties collection where one can set custom properties (it says Document not Spreadsheet because the same can be found in Word so Document is the generalised case).
Excel will look at the workbook's CustomDocumentProperties collection and search for "_AssemblyName" and "_AssemblyLocation"; if _AssemblyName is an asterisk then it knows it needs to load a .NET/VSTO assembly, the _AssemblyLocation provides a lookup to the file to load (you'll have to dig in on this, I forget the details). Reference
Anyway, I'm reminded of VSTO CustomDocumentProperties mechanism because if you insist on using VBA then I suggest storing a value in the CustomDocumentProperties collection that helps you time expire the functionality of your code. Note do not use the BuiltInDocumentProperties("Creation Date") because it is easily identifiable; instead use a codeword, say "BlackHawk". Here is some sample code.
Sub WriteProperty()
ThisWorkbook.BuiltinDocumentProperties("Creation Date") = CDate("13/10/2016 19:15:22")
If IsEmpty(CustomDocumentPropertiesItemOERN(ThisWorkbook, "BlackHawk")) Then
Call ThisWorkbook.CustomDocumentProperties.Add("BlackHawk", False, MsoDocProperties.msoPropertyTypeDate, Now())
End If
End Sub
Function CustomDocumentPropertiesItemOERN(ByVal wb As Excel.Workbook, ByVal vKey As Variant)
On Error Resume Next
CustomDocumentPropertiesItemOERN = wb.CustomDocumentProperties.Item(vKey)
End Function
Sub ReadProperty()
Debug.Print "ThisWorkbook.BuiltinDocumentProperties(""Creation Date""):=" & ThisWorkbook.BuiltinDocumentProperties("Creation Date")
Debug.Print "CustomDocumentPropertiesItemOERN(ThisWorkbook, ""BlackHawk""):=" & CustomDocumentPropertiesItemOERN(ThisWorkbook, "BlackHawk")
End Sub
So you could set CustomDocumentProperty "BlackHawk" to the workbook's initial creation time and then allow the client to use the code for 24 hours, or even 48 hours (careful with weekends, create Friday work through to Tuesday) and then afterwards the code can refuse to operate and instead throw a message saying pay LimaNightHawk more money!
P.S. Good luck with your revenue model.
P.P.S. I read your profile, thanks for your military service.
Whatever you do it will be feasible to crack it (VBA code is easy to crack). However:
there is the contract so... that's not legal for them to do it
you can put part of the code on a FTP server and control physically what is being executed
Very nices ideas here though
Compile Excel file to EXE. Google for that.
Concern 1 seems to be basic re-use of the file. You could create a sub in the ThisWorkbook module to destroy code located in other modules in the event that save-as is selected.
Concern 2 seems to be someone hacking your password protection. A similar tactic could be employed such as using "opening the developer window" as your event instead of save as.
I have experimented with save events to log user entries with great success using the ThisWorkbook module. I am not certain how/if one could detect if the developer tab is opened.
Here's what I've done. Perhaps there is a entirely better approach, or there are tweeks to the below that will make it better:
From the VBA Tools menu > VBAProject Properties > Protection (tab), I Locked the project for viewing with a password.
I created a new "License" sheet.
This sheet is hidden from the user. If you hide the sheet via code like this:
Me.Visible = xlSheetVeryHidden
then then sheet cannot be un-hidden by the user (it requires running vba code to unhide).
On initial import I sample:
Number of imported rows
x number of randomly selected cells *from the columns I know won't/shouldn't change. (There are columns they are allowed to change freely.)
I store these on the "License" sheet in Address / Value pairs.
When the workbook is opened, the Workbook_Open event fires and then does a quick comparison of the current number of rows, and the current values for the addresses stored on the "License" sheet. I then do a percentage calculation: If the rows are more than x% different, or the number of changed values is more that y% then I
Sheets(1).Protect LOCKOUT_PASSWORD
Application.Calculation = xlCalculationManual
Application.EnableEvents = False
There is also a method for unlocking the sheets if necessary.
This might be too simple of an answer, but sometimes we fail to think of the simplest solutions:
Why don't you simply provide the customer with only a copy of the output? You could run their data through your macro-enabled workbook, copy the output sheet into a new workbook, and then break all links so that there's no formulas, updating, or ties to your workbook.
I would create another workbook that contains the code and then reference the customers wb from that one.
I have an Excel workbook that I would like to export the code for every time the workbook is closed but I would like to do so selectively so that each module will only get exported if it has been modified since the workbook was opened. I would like to be able to use the exported files to run a diff on the code and I'm assuming that re-exporting every time will cause the files to always be flagged as different. Here's an attempt at some pseudo-code to show what I mean:
for each module in Workbook
if module.isModified() then
module.export
end if
next module
VBComponent has a readonly property. Add reference to VBE and you should be able to access "changed" VBComponents
bool Saved
Saved Property - (Excel 2003 VBA Programmer's Reference Google Books)
I was just being lazy about it and hoping someone already new a method that I hadn't found. Sorry about that.
I found that I can use the following.
for each module in Workbook
if not module.saved then
module.export
end if
next module
Then, I'll just run the export function every time the workbook is saved.
CONTEXT: I have created an Excel Add-In in which there is a worksheet named "Mother". When the user clicks a button from any workbook in which the Add-In is installed, I would like the worksheet "Mother" to be copied inside its same workbook and being renamed. In code:
ThisWorkbook.Sheets("Mother").Copy After:=ThisWorkbook.Sheets(ThisWorkbook.Sheets.Count)
WHAT I EXPECT: being the line of code above placed into the .xlam code, I know that ThisWorkbook refers to the Add-In and this is observable through a watcher as well:
So, I expect that a copy of "Mother" will be added to the workbook, at the end.
WHAT HAPPENS: the method simply fails, returning the error Copy Method of Worksheet class failed.
WHAT I HAVE TRIED: By simply looking for the name of the error online I have figured out that, apparently, I cannot copy a hidden worksheet and that's why the method fails. So I have tried:
1) To change the visibility with ThisWorkbook.Sheets("Mother").Visible = True... No success;
2) To activate the workbook before/after to change the visibility, so ThisWorkbook.Activate... No success.
I'm not being able to find much documentation online about this, so I'm almost wondering if it's actually possible to edit/show the workbook.xlam, something that I would really need to do for my project.
A BIT MORE OF CONTEXT: The reason why I need to both add the worksheet and show it to the user is that the Add-In, which basically consists in a custom function =myFunction(), needs to be fed by user-inputs for make its calculus.
In particular, neither I can write the data in the sheet before to distribute the Add-In (because I don't know the user inputs in advance), nor I can prepare a user-form where to insert the data and show it at running-time (because the user-inputs are usually a big amount of data that can be copied-pasted easily into an Excel spreadsheet, but not inserted manually into a form nor in the function parameters themselves). So:
MY QUESTION: Is it possible to copy (duplicate) a worksheet within a .xlma workbook and activate it after to allow the user data insertion? If yes, where am I being wrong on the above?
Looks like this link would help: http://forums.techguy.org/business-applications/1120165-add-extra-sheet-xlam-file.html.
The operation cannot be performed on add-in workbook, hence you just need to set it as "not add in":
ThisWorkbook.IsAddIn = False
'your copy operation
This Workbook.IsAddIn = True
Hello and thank you in advance for your assistance.
I have some code that I admittedly borrowed from a site. It changes the sheet that is being displayed every X seconds. In my case 3 seconds. When I run it it will change to the next sheet one time and then error out after the 3 seconds.
The error I receive is "Cannot run the macro "C:\users\BenjaminSmith\Desktop\Book1.xlsm'!displaysheets'. The Macro may not be available in this workbook or all macros may be disabled."
Here is the code for my Macro
Sub displaysheets()
ShtNum = ActiveSheet.Index
ShtNum = ShtNum + 1
If ShtNum > Sheets.Count Then
ShtNum = 1
End If
Sheets(ShtNum).Activate
Application.OnTime Now + TimeValue("00:00:03"), "displaysheets"
End Sub
If I remove the line
Application.OnTime Now + TimeValue("00:00:03"), "displaysheets"
I can run the macro over and over and there are no issues. Other than the fact it doesn't continue on its own...
The spreadsheet is an XLSM.
MS VBA is 7.0.
Excel is 2010.
I am thinking maybe the issue is because the code is recursive?
Thanks for your suggestions.
Further from the comments...
The code didn't work because you didn't paste the code in a module. This is a very common mistake among new programmers. In such a case, Excel is unable to find the code as it searches the module.
#Siddharth Rout I had the code in 'ThisWorkbook' I inserted a module 'Module1' and moved the code there and everything works as expected. What is the difference with these two places?
I would recommend going through Chip Pearson's link HERE
Extract from the link if the link ever rots.
Standard Code Modules, also called simply Code Modules or just
Modules, are where you put most of your VBA code. Your basic macros
and your custom function (User Defined Functions) should be in these
modules. For the novice programmer, all your code will be in standard
modules. In addition to your basic procedures, the code modules
should contain any Declare statements to external functions (Windows
APIs or other DLLs), and custom Data Structures defined with the Type
statement.
Your workbook's VBA Project can contain as many standard code modules
as you want. This makes it easy to split your procedure into
different modules for organization and ease of maintenance. For
example, you could put all your database procedures in a module named
DataBase, and all your mathematical procedures in another module
called Math. As long as a procedure isn't declared with the Private
keyword, or the module isn't marked as private, you can call any
procedure in any module from any other module without doing anything
special.
Workbook And Sheet Modules are special modules tied directly to the
Workbook object and to each Sheet object. The module for the
workbook is called ThisWorkbook, and each Sheet module has the same
name as the sheet that it is part of. These modules should contain
the event procedures for the object, and that's all. If you put the
event procedures in a standard code module, Excel won't find them, so
they won't be executed. And if you put ordinary procedures in a
workbook or sheet module, you won't be able to call them without fully
qualifying the reference.
User Form Modules are part of the UserForm object, and contain the
event procedures for the controls on that form. For example, the
Click event for a command button on a UserForm is stored in that
UserForm's code module. Like workbook and sheet modules, you should
put only event procedures for the UserForm controls in this module.
Class Modules are used to create new objects. Class modules aren't
discussed here, except to say that a class module is used to handle
Application Event Procedures.
Try : (i use this code)
With Application
.EnableEvents = True 'needed
.OnTime EarliestTime:=Now + TimeSerial(0, 0, 3), Procedure:="displaysheets", Schedule:=True
End With
Try to put your timer in a global variable and add it each time you run the function, also configure OnTime to be schedulable
Global tmrTimer1
Sub displaysheets()
tmrTimer1 = Now + TimeValue("00:00:03")
'Enable the schedule
Application.OnTime tmrTimer1 , "displaysheets", , True
End Sub
We receive Excel files daily from our field offices which I have to clean and re-format (about 110 columns and 500 rows-worth) using VBA.
I need to save my VBA as a macro so we can use it to clean up all the workbook we receive by running the macro and saving the edited sheet as a new worksheet by getting the name from UserForm Combobox items.
Where exactly should I store the VBA snippets? I mean when I open the Visual Basic panel, I have these three options:
Running The Code From Microsoft Excel Object :Sheets1(Sheet1)
Running the Code From An Inserted Module
Running the Code From User Form
If I am supposed to use options 1 or 2, how can I call the UserForm for saving the sheet?
I Recomend you to use modules (Option B)
Option C goes with option B, ill explain, you can create a sub in a module in option B, then you can do:
UserForm1.show
In Option B I would writte this code, but before trying this i recomend you to understand a bit more of vba
sub ClearWBs()
'opening workbook
Workbooks.Open Filename:="c:\book1.xls"
'your code
'your code
'below code for saving and closing the workbook
Workbooks("book1.xls").Activate
ActiveWorkbook.Save
ActiveWorkbook.Close
end sub
Use Module:
If your VBA code focusses on data summarization and manipulation I suggest you use a Module.(example is what you have described in your question).
Use Form:
If what you wan't to do requires a GUI(Graphical User Interface) then you'll have to resort to Form where you can design your GUI. (example is if you have many fields that the user needs to fill-up with distinct values in which you provide the choices)
Use Excel Object:
If what you wan't to do has something to do with events happening on Worksheet and/or Workbook, like for example whenever you add sheet the macro runs, or when you open or close the workbook the macro runs then you will have to write the macro in the Excel Object.
This is basically what i have in mind, hope this helps.
If you receive files that do not contain VBA and you need to apply the same code on those files all the time then I propose that you either save that code in your personal workbook.
You can see how to do that here: http://office.microsoft.com/en-ca/excel-help/copy-your-macros-to-a-personal-macro-workbook-HA102174076.aspx
This is nice because you can also tie it to keyboard shortcut or just have it always ready for you to use.
The disadvantage is that it will only be set up per user session per computer. What you can do is have that code all set up in a module and then import it into your personal workbook if you change session or if someone else has to do it.
Once it's done, you will not have to include the module in your files your receive again.