Could someone explain what is the point of writing Application.Workbooks.Worksheets() ... instead of just Workbooks.Worksheets(), omitting Application?
What additional restrictions does it impose on the Workbooks object?
Short answer: none.
Long answer: it depends.
By fully qualifying Workbooks, you're making it absolutely completely unambiguous that Workbooks is referring to Excel.Application.Workbooks. If you had a class module called Workbooks (with a PredeclaredId=True attribute), then an unqualified Workbooks would be referring to that class module, and if that class module didn't have an Item default indexer property that returned a Workbook object, it would actually prevent this code from compiling:
Debug.Print Workbooks(1).Worksheets(1).Name
If you don't have a class module named Workbooks, then VBA resolves the above to Application.Workbooks.
So, in this case, it doesn't matter.
It's not always the case - take this code as an example:
Range("F12") = 42
That's referring to Application.ActiveSheet.Range, and it can bite you in the rear end. Unqualified Range functions are the source of unquantifiable bugs, because the programmer is assuming what sheet ActiveSheet is.
Cells(2, 2) = 42
Same here. Unqualified usages of Range and Cells, are implicit references to the active sheet, and they're a plague. Avoid them. Code that uses those, usually also feature Select and Activate - a recipe for disaster, that lots of beginner think is "the right way" because macro-recorded code uses it like it's candy.
Avoid implicit references to the active sheet, and avoid implicit references to the active workbook. Implicit references to the active application though, are probably fine. A tiny wee bit lazy, but fine.
Related
The Macro Recorder generated the following statement:
Cells.Select
Now I understand that without the object qualifier this will return all the cells as a Range object.
However, I am wondering what the fully qualified version of this statement is?
Is it:
Application.Cells.Select
Application.ActiveSheet.Cells
Application.ActiveWorkbook.ActiveSheet.Cells
In other words, which one of those fully qualified statements is actually executed by VBE when it runs Cells.Select?
What is the difference between all of these??? As all of these access the same object in the end - is it just personal preference as to which statement I would use if I wanted to explicitly qualify all the objects?
Thank you so much!
It's complicated :)
As all of these access the same object in the end
True. Keywords "in the end". The difference is how many steps it takes to get there...
Unqualified Cells (or Range, Rows, Columns, Names, etc.) aren't magic, they're member calls (Property Get) against a hidden, global-scope object cleverly named Global:
You can validate that this hidden object is involved, by blowing up in a standard module:
Sub GoesBoom()
'throws error 1004 "Method 'Range' of object '_Global' failed"
Debug.Print Range(Sheet2.Cells(1, 1), Sheet3.Cells(1, 1))
End Sub
_Global and Global are closely related - without diving deep into COM, you can consider Global the class, and _Global its interface (it's not really quite like that though - look into "COM coClasses" for more information).
But Cells is a property of the Range class:
I think it's reasonable to presume that Global calls are pretty much all redirected to Application, which exposes all members of Global, and then some.
Now as you noted, Application also have a Cells property - but Cells belong on a Worksheet, so no matter what we do, we need to end up with a Worksheet qualifier... and then any worksheet belongs in a Worksheets collection, which belongs in a Workbook object - so we can infer that an unqualified Cells call would be, in fully-explicit notation, equivalent to... (drumroll):
Application.ActiveWorkbook.ActiveSheet.Cells
But you don't need to be that explicit, because ActiveSheet has a Parent that is always going to be the ActiveWorkbook, so this is also explicit, without going overboard:
ActiveSheet.Cells
But that's all assuming global context. This answer explains everything about it - the gist of it, is that if you're in a worksheet's code-behind, then an unqualified Cells member call isn't Global.Cells, but Me.Cells.
Now, note that Cells returns a Range. Thus, whenever you invoke it against a Range without providing parameters, you're making a redundant member call:
ActiveSheet.Range("A1:B10").Cells ' parameterless Range.Cells is redundant
Let's take the post apart:
Cells.Select
Now I understand that without the object qualifier this will return
all the cells as a Range object.
That's actually somewhat incorrect. While it is true that .Cells returns a Range.Cells object which returns all the cells, Cells.Select is actually a method of the Range object which - as you may have guessed - Selects the range (in our case, all the cells)
The Select method, as per MSDN actually returns a Variant and not a Range object.
That it is a pretty important distinction to make, especially if you plan on passing that value to anything. So if we pretended to be a compiler
Cells -> ActiveWorkbook.ActiveSheet.Range.Cells returns Range of all the cells
Range.Cells.Select -> first we take our returned Range, we then select the cells in Worksheet and actually return a Variant (not Range)
As to the other part of the question. It depends where your module is placed. By default, Cells is shorthand for the following statement:
Application.ActiveWorkbook.ActiveSheet.Range.Cells
This however is subject to change depending on where your module is placed and if Application, workbook or sheet has been modified.
In general, it is a good coding practice to always specify at least a specific Worksheet object whenever you're referencing a Range, eg.
Sheets("Sheet1").Range.Cells
This is explicit and therefore less error prone and clearer to comprehend, be it for you or anyone working with your code.. You always know what exactly you're working with and not leave it to guesswork.
Obviously, the moment you start working with multiple workbooks, it's a good idea to incorporate Workbook objects statements before the Sheet. You get my point.
Last but not least, whatever you're trying to do, it's probably for the best you avoid using Select. It's generally not worth it and prone to unexpected behaviour.
Check this question here: How to avoid using Select in Excel VBA
If you just type Cells - in and of itself it does nothing. It is the same as Range.Cells. The only advantage of Cells is that it can accept numeric value for column (second argument). It's very handy when you do complex manipulations.
Range.Cells just returns Range object. When you have Range object, think of it as a small Excel worksheet. Say, you have range Range("F3:J10"). Then following ranges all refer to H3 cell:
Range("F3:J10").Cells(3)
Range("F3:J10")(3)
Range("F3:J10").Cells(1, 3)
Range("F3:J10")(1, 3)
Range("F3:J10").Cells(1, "C")
Range("F3:J10")(1, "C")
Range("F3:J10").Range("C1")
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 some User Defined Functions in an Excel book. I used them for a while but, after a while, I deleted the calls to these functions from the cells because I found a better way to accomplish the same task (I didn't delete the function definition itself in the VBA editor). So, these functions are no longer being called neither in the book nor from any VBA code, I checked it using a search to be 100% sure.
Now I'm doing some review on my code and I noticed something strange: in a Sub procedure in the same workbook (which has nothing to do with these functions) I call Application.CalculateFullRebuild. When this happens those UDF get called, I can see it by setting a break point inside the UDF.
I'd like to know why is it happening and what can be done to avoid it, as it is slowing that Sub unnecessarily.
Thanks!
Application.CalculateFullRebuild MSDN reference has this to say:
The CalculateFullRebuild method is similar to re-entering all formulas. ... [When run] a full calculation of the data in all open workbooks is performed and the dependencies are rebuilt.
Further MSDN reference states:
Causes Excel to rebuild the dependency tree and the calculation chain
This means that any UDFs in the module code or sheet code will be recalculated because Excel is rebuilding and testing functions for dependency and use in the calculation chain.
If you are looking for a way to simply manually calculate the existing formulas in the sheet via your Sub, you can use 'Application.Calculate' (MSDN):
Application.Calculate 'for all open Sheets
Sheets("Name of Sheet").Calculate 'Specific Sheet
Sheets("Name of Sheet").Range("Name of Range").Calculate 'Specific Range
The system is working as it should. Consider:
Function qwerty() As String
qwerty = "qwerty"
MsgBox "XX"
End Function
It is non-Volatile and has no arguments. It will be calculated at the time it is entered in a worksheet cell. Application.Calculate may cause it to be calculated once, however:
Sub ytrewq()
Application.CalculateFullRebuild
End Sub
will cause the UDF to be re-calculated each time ytrewq is run.
To the moment my approach has been commenting all the code inside the UDF with two objectives: increasing speed on one side and checking if any side effect happened on the other side. To the moment, I have not observed any side effect, so more to the point that they are not being used anywhere.
Right now the application I'm developing is working quite well, but I'll try the solutions you're proposing just out of curiosity. By bets are on either it's being used somewhere hidden and forgoten or simply that I have some rubbish inide the workbook structure that is not getting cleaned.
Thanks!
Update
Tried again the next day and those UDF are no longer being called. Thus, I'll have to assume that something odd was going on with Excel that went away when I restarted it.
Anyway, thanks a lot for the Application.Caller thing, which I didn't know about.
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
Basically what I'm trying to accomplish is to search the document for blank rows and delete them, if any. This works great if there are blank rows to delete; however, if there are no blank rows, the macro ends with an error. I'd be eternally grateful if someone could advise me how to make this into an "if blank rows then this, if none then that"
Sheets ("xml") .Select
Cells.Select
Selection.SpecialCells(x1CellTypeBlanks).Select
Selection.EntireRow.Delete
Enter my second macro (this part works fine)
Regards
Let me point you to the canonical:
How to avoid using Select/Activate in Excel VBA macros
So you can start to understand why your current code fails or performs undesired operation. What happens when there are no blank cells in your selection? You'll get an error. Why?
Because in that circumstance, Selection.SpecialCells(xlCellTypeBlanks) evaluates to Nothing. (You can verify this using some debug statements) And because Nothing does not have any properties or methods, you'll get an error, because you're really saying:
Nothing.Select
Which is a null program, does not grok, does not compute, etc.
So, you need to test for nothingness with something like this:
Sheets("xml").Select
Cells.Select
If Not Selection.SpecialCells(x1CellTypeBlanks) Is Nothing Then
Selection.SpecialCells(x1CellTypeBlanks).EntireRow.Delete
End If
I still suggest avoiding Select at all costs (it is superfluous about 99% of the time and makes for sloppy code which is difficult to debug and maintain).
So you could do something more complete following that line of thought:
Dim blankCells as Range '## Use a range variable.
'## Assign to your variable:
Set blankCells = Sheets("xml").Cells.SpecialCells(xlCellTypeBlanks)
'## check for nothingness, delete if needed:
If Not blankCells Is Nothing then blankCells.EntireRow.Delete
Follow-up from comments
So in VBA we are able to declare variables which represent objects or data/values, much like a maths variable in an equation.
A Range is a type of object part of the Excel object model, which consists of the Workbook/Worksheets/Cells/Ranges/etc. (far more than I could hope to convey to you, here)
http://msdn.microsoft.com/en-us/library/office/ff846392(v=office.14).aspx
A good example of why to use variables might be here if you scroll down to the "Why Use Variables" section.
http://www.ozgrid.com/VBA/variables.htm
This is of course very simple... but the reader's digest version is that variables allow us to repeatedly refer to the same object (or value for sipmle data types) without explicitly referring to it each time.
THen there is the handy side-effect that the code bcomes more easy to read, maintain and debug, when we use variables instead of absolute references:
Dim rng as Range
Set rng = Sheets(1).Range("A1:Q543").Resize(Application.WorksheetFunction.CountA(Sheets(1).Range("A:A"),))
Imagine that fairly (but not ridiculously) complicated range construct. If you needed to refer to that range more than once in your code, it would be silly not to assign it to a variable, if for no other reason than to save your own sanity from typing (and possibly mistyping a part of it). It is also easy to maintain, since you need only modify the one assignment statement and all subsequent references to rng would reflect that change.