A quick one for noob like me!
So usually I pass in some range of data from worksheet into function like that:
public function foo (someRange as range)
dim someData as double
if IsNumeric(someRange.value), do some crap
end function
The problem occur when I try to code some function that uses this function foo. Instead of range i would like to pass in a double(). So if I were to fix this, i can either:
a. I have seen some other site uses "someRange as Variant" instead (which then avoid problem like i face). However, is it "good coding practice"?
b. use a wrapper function foo_wrap instead
You could use a Variant and then TypeName to find out what kind of argument was supplied:
?TypeName(range("A1"))
Range
?TypeName(45.66)
Double
?TypeName(array(34.5,56.7))
Variant()
Personally, I would just create two separate Functions. Using one function would just be messy to me. For a single function NOT to just duplicate code, it would have to extract all the Range values into a Double array. This just tells us that it should be two functions.
Creating a wrapper-function is an option, but I'll leave you to decide whether this is a good solution for you.
If you did want to pursue a multi-purpose function then you could investigate ParamArray:
Used only as the last argument in arglist to indicate that the final
argument is an Optional array of Variant elements.
This would allow you to create a Function that behaves similarly to the built-in functions (SUM, etc.) which can accept a variable number of arguments, which can be Ranges and/or values. However, particularly as you are a noob, I would ignore this possibility for a while. The KISS principle.
Related
I am working on a large window that has an extremely large function call(~2.5k lines). I am curious as how would be the most efficient way to handle the need to add ~5 variables that is to be used throughout the function, but also passed between many different functions within the same large function.
Do I update all the function calls within the large function and add a ByVal of the new variables with all the functions that use these new variables or take the easy way out and make global variables for all of them? I was told that too many global variables harm overall performance, not to mention it gets harder and harder to read the more you add.
I could create a new class, create a public List, Dictionary, Array to hold all of the variables I will be using, but I'm just not sure what the best way to handle this scenario is, or if it even matters as long as it works.
Well, what I like to do when handling large amounts of repetitive Code is using the "Search and Replace" Feature. This is very useful and Time saving, especially when you have to insert the same piece of code over and over again.
Example
Lets say, you have a few hundred Functions that look something like this:
Public Function Foo(bar As String) As String
....
End Function
Public Function SomeFunction(SomeVariable As String) As String
....
End Function
To use this Feature in Visual Studio 2013; (Probably older Versions too ;D)
"Ctrl + F"
Insert As String) in the "Search" Tab
Insert As String, ByVal FooBar As Integer) i the "Replace" Section
Replace
Now, obviously this has some downsides, you have to cheack that only the code sections you wanted to edit are selected, otherwise it will get really, really nasty.
In C/C++, when I have a bunch of functions (pointers), I can store them in an array or a vector and call some of them together in a certain order. Can something similar be done in VBA?
Thanks!
Yes, but I don't recommend it. VBA isn't really built for it. You've tagged this question with Excel, so I will describe how it is done for that Office Product. The general concept applies to most of the Office Suite, but each different product has a different syntax for the Application.Run method.
First, it's important to understand the two different methods of dynamically calling a procedure (sub/function) and when to use each.
Application.Run
Application.Run will either run a subroutine or call a function that is stored in a standard *.bas module.
The first parameter is the name of the procedure (passed in as a string). After that, you can pass up to 30 arguments. (If your procedure requires more than that, refactor for the love of code.)
There are two other important things to note about Application.Run.
You cannot use named arguments. Args must be passed by position.
Objects passed as arguments are converted to values. This means you could experience unexpected issues if you try to run a procedure that requires objects that have default properties as arguments.
Public Sub Test1()
Application.Run "VBAProject.Module1.SomeFunction"
End Sub
The takeaway:
Use Application.Run when you're working with a standard module.
VBA.Interaction.CallByName
CallByName executes a method of an object, or sets/gets a property of an object.
It takes in the instance of the object you want to call the method on as an argument, as well as the method name (again as a string).
Public Sub Test2()
Dim anObj As SomeObject
Dim result As Boolean
result = CallByName(anObj, "IsValid")
End Sub
The takeaway:
Use CallByName when you want to call a method of a class.
No pointers.
As you can see, neither of these methods use actual pointers (at least not externally). They take in strings that they then use to find the pointer to the procedure that you want to execute. So, you'll need to know the exact name of the procedure you want to execute. You'll also need to know which method you need to use. CallByName having the extra burden of requiring an instance of the object you want to invoke. Either way, you can stores these names as strings inside of an array or collection. (Heck, even a dictionary could make sense.)
So, you can either hard code these as strings, or attempt to extract the appropriate procedure names at runtime. In order to extract the procedure names, you'll need to interface with the VBIDE itself via the Microsoft Visual Basic for Applications Extensibility library. Explaining all of that here would require far too much code and effort, but I can point you to some good resources.
Articles & SE Questions:
Chip Pearson's Programming The VBA Editor
Extending the VBA Extensibility Library
Ugly workaround to get the vbext_ProcKind is breaking encapsulation
Automagic testing framework for VBA
How to get the procedure or function name at runtime
Import Lines of Code
Meta Programming in VBA: The VBIDE and Why Documentation is Important
The code from some of my Qs & As:
vbeCodeModule
vbeProcedure
vbeProcedures
A workaround is to enumerate and use a switch statement. You can store enumerated types (longs) in an array. E.g.:
Enum FType
func1
func2
func3
End Enum
Sub CallEnumFunc(f As FType, arg As String)
Select Case f
Case func1: MyFunction1(arg)
Case func2: MyFunction2(arg)
Case func3: MyFunction3(arg)
End Select
End Sub
Dim fArray(1) As FType
fArray(0) = func1
fArray(1) = func2
CallEnumFunc fArray(1), "blah"
I'm trying to set up a sub to be called upon and use the value of its result in the main sub. So far I've been using Function to carry over the value. However, I was wondering if there are any alternative ways of doing the same thing? I figured ByVal/ByRef is another way to do it by using a Sub instead of Function. My current codes are as follow:
Sub Main()
Dim i as Long
i = lr("A")
'some other calculations using i
End Sub
Function lr(Tar As String) As Long
Dim twb As Workbook
Set twb = ThisWorkbook
lr = ThisWorkbook.Sheets(1).Range(Tar & Rows.Count).End(xlUp).Row
End Function
My question is, How would I write this if I were to use a Sub instead of Function? Thanks!
So far I've been using Function to carry over the value.
Great, that's what functions are for! When you only need to return a single value, the best way is always going to be a function.
Things get fuzzier when you start needing to return two or more values. You could:
Use ByRef parameters and use them as "out" values.
This is "ok" for procedures (Sub), and confusing for functions - what determines which parameter gets to be the function's return value, and which parameters get to be passed ByRef? How does the calling code know whether or not to pass an initialized value to those ByRef parameters?
A naming convention can help here:
Public Sub Foo(ByVal foo1 As String, ByRef outBar1 As String, ByRef outBar2 As String)
An "out" prefix can tell the calling code that the parameter is an out value.
Scope the variables at a level that is accessible by both the caller and the callee.
This is a bad practice that can easily lead to spaghetti code. Avoid it - variables should have the smallest necessary scope possible, and be passed between methods/functions/procedures/modules, not just globally scoped and accessed by anyone at any given time!
Create a class to encapsulate all the values the function should return.
Definitely more object-oriented, results in much cleaner, readable code. The only downside is that VBA doesn't really encourage you to do this, and consistently doing that will result in a myriad of classes that you can't quite organize.
I have a list of objects that are "keys" into a table - the keys are simply the items in the first column. They can be Integers or Strings, depending on what DB table we read it from. Since we use them a lot, we cache that column in an ArrayList called "Keys".
We wrote cover methods to return Row, one that uses strings and the other integers. If you call the integer version it simply returns that row by index. If you call the string, it looks down Keys for a match, and uses that index to pull out the row.
Ok, so now I pass Keys to Excel, pull out one of them in a loop, and ask it what it is...
TypeName(DB.Keys(i))
And the object returns...
Long
Great, the keys must have been integers! So now I'll try to get the row for that key, by calling the accessor method, Row...
DB.Row(DB.Keys(i))
And it calls into the version that takes a String.
Whoa!
Can anyone think of a reason that VBA calling back into our VB.net DLL ends up calling the wrong accessor?
ADDED CODE: I can't figure out how to put the code in as a reply, so I'm editing this. Here is the code in the VB.net class:
Public Function Row(ByVal K As String) As DataRow
Dim R As DtaRow = DB.Tables(0).Rows(K)
Return New DataRow(R)
End Function
Public Function Accounts(ByVal K As Integer) As DataRow
Dim R As DtaRow = DB.Tables(0).Rows(K)
Return New DataRow(R)
End Function
If you're wondering, there's two versions of Rows, which take strings or ints.
This code works perfectly from VB.net. You can ask for a row by key string or by the row number, that invokes the proper Row, which calls the proper Rows, and out comes the proper answer.
But in VBA, it always calls the method with the string input. If I rename it to RowIHATEYOUALL then I can call the Integer version just fine. But when there are two of them, differing only in signature, no such luck.
And the A and i (see comments) was my typo.
The interop layer does not support overloaded methods. Whenever you call Row, the first declared method with that name is used. The .NET overload resolution algorithm does not apply here.
Other overloads are exposed to VBA as Row_2, Row_3, etc. Thus, the following code should do what you expect:
DB.Row_2(DB.Keys(i))
This implicit dependency on the order of declaration has a high potential for error. Thus, I would suggest to either
give the methods unique names if they are called from VBA,
or, if you want to retain the "nice" overloaded version for .NET, add compatibility methods for VBA:
<Obsolete("Compatibility method for VBA, use Row instead.")>
Public Function RowByKeyVBA(ByVal K As String) As DataRow
Return Row(K)
End Function
<Obsolete("Compatibility method for VBA, use Row instead.")>
Public Function RowByNumberVBA(ByVal K As Integer) As DataRow
Return Row(K)
End Function
Further information can be found in the following question:
COM->.NET - can't access overloaded method
Following Heinzi's notes (above) I fixed this by making three method signatures for each call, one takes an Object and then attempts to figure out what it is, the others take the String and Integers. Within VB/C#/etc the proper String or Integer methods get called as expected, from VBA the Object version is called, as Heinzi noted
This causes the very minor issue that a user may have a "number like value" that is actually a String. For instance, the array keys might be "User3232" or "3232", both of which are String objects in the table. So you have to be careful, simply asking if the Object can be converted to an Int32 is not enough. This is unlikely to be something that effects most users.
I've got a private procedure in a VBA script for MS Access:
Private Sub drawLineDiagram(chartSpace As Variant, title As String, caption As String, x_val() As Variant, y_val() As Variant, Optional y_val2() As Variant = ????)
As you see, I want to have an optional last parameter for an array of values.
What kind of default parameter must I assign? If I do it with an optional integer value and assign it e.g. 0 it's all fine.
If I do it with an array as shown above and assign an array, the line is marked red => as an error (and it won't compile).
If you need an optional array in VBA, declare it as Variant without array specificator, but access it as an array anyway. This way you get a Variant (single variable) that holds an array of Variants, as opposed to just array of Variants. No default value is required:
Private Sub drawLineDiagram(chartSpace As Variant, title As String, caption As String, x_val As Variant, y_val As Variant, Optional y_val2 As Variant)
For consistency, also declare as plain Variants the other two parameters.
If you hate the IDE, do not use it.
Use notepad. Then paste written code.
Perhaps you want a Parameter Array:
In the procedure declaration, define
the parameter list in the normal way.
All parameters except the last one
must be required (not Optional (Visual
Basic)).
Precede the last parameter name with
the keywords ByVal ParamArray. This
parameter is automatically optional.
Do not include the Optional keyword.
-- How to: Overload a Procedure that Takes an Indefinite Number of Parameters (Visual Basic)
Reference for VBA: Understanding parameter arrays
There is a simpler but not necessarily better answer to this question. Sebastian said, "If I do it with an array as shown above and assign an array, the line is marked red => as an error (and it won't compile)."
Your code includes "Optional y_val2() As Variant = ????". You don't need the "()" there for it to take a Variant array as a parameter. So if you really want to do it that way, you can, for instance with something like "Optional y_val2 = FALSE".
When passing the argument initially, if you want to pass an array, then just make sure that that is a Variant array.
I do think that it's more elegant not to use a default there, so I agree with GSerg's answer in general (and upvoted both that and the original question).
However to GSerg and spinjector, yes, you can check the optional parameter with "If IsArray(YourOptionalVariantParameter) Then", but if you're using a Variant,
"IsMissing(YourOptionalVariantParameter)" is handy and elegant, may be a smidge faster, and can be used when (and only when) a Variant is passed as an argument, to check to see whether or not it exists.
If you do "IsArray(YourOptionalVariantParameter)" and no such parameter exists, then all we're doing is checking whether a nonexistent variable is an array. If you use a default parameter value like FALSE (as in my first example), then it does make sense to first check whether the variable is an array or not.
By the way, I don't agree that you need to declare all the parameters as Variants for consistency. Variants are less efficient than other types, and so should be used only when necessary, I think.
The IDE might not be of great use, but the help (for once) contains the answer:
ParamArray
Optional. Used only as the last argument in arglist to indicate that the final argument is an Optional array of Variant elements. The ParamArray keyword allows you to provide an arbitrary number of arguments. ParamArray can't be used with ByVal, ByRef, or Optional.