A problem with VBScript is that it doesn’t allow you to have optional parameters in your procedures. This also means you can’t do function overloading. There are various ways to deal with this but many of them can lead to a maintenance problem and require you to change how your new (“extended”) procedures are called. Ideally, you don’t want to have to change how the function is called each time you extend it. So let’s look at a few ideas here.
One solution is to replace the parameters of a function with a single array parameter. This array can then hold as many values as are passed in. This way, whenever that function is extended, the number of parameters to pass to it doesn’t change (after all, there’s still only one). What does change is the internal data structure. That’s fine, of course, because that doesn’t affect the previously existing calls to that function. But consider the implementation:
|
1 2 3 4 5 |
Public Function LogThis(parameters) Print parameters(0) Print parameters(1) Print parameters(2) End Function |
Do you see the problem? First, with a ‘parameters’ array like this, you’re essentially just guessing everything from the number of parameters, to their expected value type, and even their order. That’s just in the function call itself. In the function logic, you’re essentially using arbitrary “unnamed” variable references. This is just not good coding practice.
You can solve the unnamed variable reference problem by using a different data structure than an array. One data structure which has a reference-by-name feature is a Scripting.Dictionary object. Let’s say I have a LogThis procedure that can take the text to log, a boolean for ‘headline’ (indicating the text should have a special set of characters that set it off), and a ‘break’ boolean (indicating whether the line should have a line break).
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
Dim oParamSet Set oParamSet = CreateObject("Scripting.Dictionary") oParamSet.Add "text", "" oParamSet.Add "headline", "false" oParamSet.Add "break", "false" Call LogThis(oParamSet) Public Function LogThis(parameters) Print parameters("text") Print parameters("headline") Print parameters("break") End Function |
The main problem there is obvious: building the parameter object before calling the function. There are varying solutions that you can use to get around that. One that seems effective is to use coded strings. In other words, use a string composed of data separated by special characters that are meant to indicate how the string is parsed.
What you do here is encapsulate the parameter object creation in a publically accessible function.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
Public Function ParamParser(thisData) Dim oParamSet Dim index Dim paramGroup Dim parameter Set oParamSet = CreateObject("Scripting.Dictionary") paramGroup = Split(thisData, "|") For index = 0 To UBound(paramGroup) parameter = Split(paramGroup(index), ">") oParamSet.Add parameter(0), parameter(1) Next Set ParamParser = oParamSet End Function |
Now my LogThis procedure starts like this:
|
1 2 3 4 5 6 7 8 9 |
Public Sub LogThis(parameters) Dim params Set params = ParamParser(parameters) .... Print parameters("text") Print parameters("headline") Print parameters("break") .... End Sub |
And here’s how it’s called:
|
1 |
LogThis "text>Log this text.|headline>true|break>true" |
One thing you might notice here is that the order of the parameters makes no difference. They are all going to be parsed as part of the coded string and it doesn’t matter where on that string they reside. You’ll note, however, that there is still no indication of how many parameters the procedure is expecting. That’s a problem but at the very least, this approach allows you to handle logic inside the procedure body based on what the name of the parameter is, rather than an “unnamed” variable reference.
There’s another interesting problem, of sorts. What if I want to do this:
|
1 |
LogThis "text>Log this text." |
I have no other parameters: just the text. Let’s say this is a common use of the LogThis procedure. In that case, I might just want to allow this call:
|
1 |
LogThis "Log this text." |
Notice how I have no parameter there? The problem is that this won’t be handled because the ParamParser function is expecting a coded string. I could modify the ParamParser like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
Public Function ParamParser(thisData) Dim oParamSet Dim index Dim paramGroup Dim parameter Set oParamSet = CreateObject("Scripting.Dictionary") paramGroup = Split(thisData, "|") For index = 0 To UBound(paramGroup) parameter = Split(paramGroup(index), ">") If (UBound(paramGroup) = 0) Then oParamSet.Add "text", parameter(0) Else oParamSet.Add parameter(0), parameter(1) End If Next Set ParamParser = oParamSet End Function |
Notice here I changed the ‘if’ logic. This will work in that it will assume if no parameters are found, then the default value is text. The problem is that this works for the LogThis function where ‘text’ as a default parameter makes sense. But ParamParser could be called by anyfunctions, not just LogThis. And those functions may not have a default value where ‘text’ makes sense.
This is a tricky element and at this point the ParamParser function would need a call chain of some sort so that it knew what procedure called it. Then, based on that, it could apply an appropriate default setting. That’s a bit more than I’m able to tackle right now but hopefully this gives QTP scripters a way to move forward on a particular shortcoming of QTP’s use of VBScript.
