Call using USEUNIT in vbscript does not work

[mcastellanos]

I have function1(param1) defined in script Unit1 and I want to call function1(param1) from script Unit2. Thus, I have done the following according to documentation:

'In Unit2 script, did

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

'USEUNIT Unit1

function1(param1) 'Method 1

Unit1.function1(param1) 'Method 2

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

None of the above methods worked. Am I missing something?

Any input will be greatly appreciated.

[mcastellanos]

Correction needs to be made.

Method 2 works; however, Method 1 does not.

[NisHera]

don't know how it's working in VB since I'm into jScripting

But it's a great thing that method 1 not working
imagine a case you are calling UNIT X and UNIT Y and both have function1(param1)

[AlexKaras]

Hi,

At the first glance it should work... Could you elaborate what does 'does not work' mean? Any message/warning/error in the log? If you insert some Log.Message() call into the function1 in Unit1, is this message present in the log? What happens if you put a breakpoint in Unit2 and then Step Into ?

Also, what is the actual code of Unit2?

If you provided complete code, than I would treat the observed behavior as the expected one:

-- script code is executed by the VBScript runtime;

-- VBScript runtime treats 'USEUNIT clause as a regular comment and thus has no idea about Unit1;

-- function1() in this case might be treated as an unknown function and just skipped.

[Colin_McCrae · Accepted solution]

There is something about naming conventions for USEUNIT calls which I can't quite recall?

Hang on ....

Got it.

https://support.smartbear.com/viewarticle/73884/#Calling

(The second bullet point)

If the function name and unit name are the same, the call will only work if prefixed with the unit name. Sounds like whats happening to you.

[mcastellanos]

Thank you all for responding.

Colin,

You are right on target. That was the issue.

function name was SelectRow(row) which resided in script name or unit by the same name SelectRow

Therefore statement below was throwing an exception.

SelectRow(row) 'This throws exception

SelectRow.SelectRow(row) 'This does not throw exception

I am new to TC so I am sampling the application and its potential. I realize a sound structuring of artifacts and good naming convention is as important. To this end, the case above could have been avoided by carefully naming your items.

Thanks again and sorry for the trouble.

[AlexKaras]

Hi,

Great to hear that the problem was solved. Kudos to Colin 😉

Though... Don't get me wrong, but

> I realize a sound structuring of artifacts and good naming convention is as important.

> To this end, the case above could have been avoided by carefully naming your items.

Not only this, but the detailed and precise description of the actual problem when it happens is extremely important as well. I hope that you will agree that your last description of the problem is significantly different from the initial one. The probably only thing that it lacks is the actual text of the error posted to the log. But the absence of these details made people to guess and you to wait longer for the solution (with the chance not to get it at all because your initial example was quite OK).

[Colin_McCrae]

Heh.

Yeah. I got it from the description of the behaviour rather than the example code, so Alex has a fair point.

But thats because I came from VBScript with QTPro so did a fair bit of experimenting with the VBScript behaviour when I first started using TC. The behaviour outlined rang a bell as soon as I read it.

Also using C# Script now (at the request of the test team who will be using it) but I still do my framework/script extensions (same thing for me) in VBScript. It has it's shortfalls, but it also has it's advantages. Just like any language really ....