Using Project Suite Variables

I have a scenario whereby I am using custom routines to set values is certain types of Developer Express controls.  I would like to place these routines in a class definition.  The idea being that I can use them in future scripts.

My Project Suite contains 5 or 6 projects, all of which use the same general control variables to store objects, for example, I always declare the variable frmCtrl to represent the name of the form I am working on and cboCtrl to represent  the a combo box control that I need to address.

These variables (I have 13 of them) are always declared as global variables at the beginning of each script so that each of the routines in that script has direct access to them.

Coming back to the class definition idea, I already have the class definition set up and it works well with the script for which it was originally designed.  However, because it was used for only one area of our application, the class definition also used its own global variables such as cboCtrl.  As an example, my script code might look something like this:

‘USEUNIT DevXCtrls

Dim cboCtrl

Sub Main

      …..

      Set cboCtrl = …….comboBoxControlItem

      Call DevXCtrls.clickItem(“my item”)

      …..

End Sub

Then in the DevXCtrls Class definition:

Dim cboCtrl

Set cboCtrl = …..

Sub clickItem(item)

      …..

      Call cboCtrl…..

      …..

End Sub

What I am trying to achieve now is the removal of any specific object assignment in the class definition routine, i.e. in the above example, the set cboCtrl… line would be absent, in this way, the routine will be truly global and can be used for other areas of the application.

I am looking at the possibility of using Project Suite variables but rather than always having to refer to these as ProjectSuite.Variables.<variable name> throughout all my scripts , I thought that I would keep assigning the control variables in the same way and, where necessary, call a routine that would update the Project Suite variables.  To keep things simple, the Project Suite variables have the same names, so if I have a global variable within a script called cboCtrl, I also have a Project Suite variable called cboCtrl.  The idea is that if I need to reference one of the Developer Express controls, I would assign the global variable to it, and make the Project Suit variable equal to the same variable:

In the class definition routines , I would assign its global variable cboCtrl to be that of the Project suite variable:

                 Set cboCtrl = ProjectSuite.Variables.cboCtrl

Using this method, all routines in any script I write and any routine added to the class definition can use the shorthand version (cboCtrl) rather than ProjectSuite.Variables.cboCtrl.

 I have already done all of the above, but I have come across an issue, for which I am not sure there is an elegant solution…

When assigning a control variable to an actual control on a form, I must work down through the hierarchy, for example: application.form.tab.page.panel.group.control.  This, as you can imagine, generates a lengthy string.  So to get round this, when working with several controls in the same area of a window, I can assign several control variables, for example:

                Set appCtrl = Aliases.application_name

                Set frmCtrl = appCtrl.form_name

                Set tabCtrl = frmCtrl.tab_name

                …

                Set cboCtrl = grpCtrl.comboBoxControlItem

This allows me to refer to any control in that area of the form simply by re-assigning the cboCtrl variable.

Now, when updating the Project Suite variables, I thought that all I had to do was to call a general routine that simply re-assigned values to each:

Sub setPSvars

    Set ProjectSuite.Variables.appCtrl = appCtrl

    Set ProjectSuite.Variables.frmCtrl = frmCtrl

   …

   Set ProjectSuite.Variables.cboCtrl = cboCtrl

End Sub

OK, it’s not the prettiest routine, but with only having 13 such variables, its simple and relatively short.

However, if I haven’t needed to use a particular control variable in my script, then,  whilst it has been declared, it isn’t set to any value or object, therefore, when trying to assign it to a ProjectSuite variable, the above routine generates an error.

Referring to the online help, I came across VariableByName.  This sounded like an ideal solution, so I re-wrote the above routine as follows:

Sub setPSvars(varList)

  Dim var

  For each var in varList

    set ProjectSuite.Variables.VariableByName(var) = var

  Next

End Sub

The idea behind this was to generate an array of variable names that I have assigned and pass it to the routine, which would loop through each item in the array and update the corresponding Project Suite variable. For example, If the array contained (“frmCtrl”, “grpCtrl”, “cboCtrl”) then the above routine would update the associated Project Suite variables.

As you can see, the Set ProjectSuite.Variables.VariableByName(var) = var line is the one that was supposed to do the assignment, hopefully generating each of the following lines based on the array above:

However, when I run the script, it errors out, stating “Variable is undefined: 'VariableByName'”

Is my understanding of the ‘VariableByName’ function wrong in this context, or is there a problem with the syntax?

The only solution that I think would work is to run a routine whereby I check for the assignment of each variable before attempting to update the ProjectSuite variable:

Sub setPSvars

   If appCtrl <> Nothing Then

      Set ProjectSuite.Variables.appCtrl = appCtrl

   End If

   If frmCtrl <> Nothing Then

      Set ProjectSuite.Variables.frmCtrl = frmCtrl

   End If

   ….

End Sub

It’s not a major issue, but with 13 such variables to check and assign, this routine isn’t elegant and certainly is far less elegant than my attempted solution using VariableByName, which is only 6 lines long.  This method would be 41 lines long, and would get longer if I had to add any other variables.

Being relatively new to TestComplete and VBScript, there is probably a much simpler way to approach this whole thing, if so, I would be very interested to hear other possible solutions.