An Extended Parameters Mechanism for Procedures in QTP

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:

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).

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.

Now my LogThis procedure starts like this:

And here’s how it’s called:

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:

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:

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:

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.


This article was written by Jeff Nyman

Anything I put here is an approximation of the truth. You're getting a particular view of myself ... and it's the view I'm choosing to present to you. If you've never met me before in person, please realize I'm not the same in person as I am in writing. That's because I can only put part of myself down into words. If you have met me before in person then I'd ask you to consider that the view you've formed that way and the view you come to by reading what I say here may, in fact, both be true. I'd advise that you not automatically discard either viewpoint when they conflict or accept either as truth when they agree.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.