I'm not really sure how to phase it any other way.
The thing is, i'm trying to merge functions with the same name in vbs. Sometimes, the function appears in different forms in other parts of the system. If they are too different, I regretfully leave them as they are. However, if the differences are minor (like having one of the functions only having one variable more than the others, which i can then check for in-function), I'd like to add a variable that would be a stand in.
I already know that Optional variables are not possible in vbs, and I've already had experience with passing an array of variants (works like a charm), but I believe this case is a bit different.
Dim is not correct here. You can do for example:
Public Function MagicFunction(intData1, ByRef intData2, ByVal intData3)
' some code
End Function
and to call it:
MagicFunction 3, iCount, ""
to have "optional arguments", you can only use an array an parse it (for example using UBound(aTab) to select the correct case
Public Function MagicFunction(ByVal aTab)
Select Case UBound(aTab)
Case 1: MagicFunction1 aTab(1)
Case 2: MagicFunction2 aTab(1), aTab(2)
Case Else: MsgBox "function called with more than 2 args" '<-- Should never go there
End Select
End Function
With different version of your function depending on the number of argument, MagicFunction1, MagicFunction2... It's ugly but do the trick!
Another possibility is to use empty strings as argument, and define how your function ignore a part when the string is empty (or to be more accurate, call with a specific key, like "IGNORE_KEY")
I hope I'm answering your question!
Related
I have a function that does the same operation for all of my scripts, but only the variable in which the Pass-Fail value is stored, would change.
For example, in one script -> the status is stored in Envrionment.Value("Current_Status")
in another script -> the status is stored in DataTable.Value("Status",1)
in another script -> the status is stored in objRS("AddCriteria_Status").Value
So i am trying to make a function in which i pass on these parameters as strings and then later use them as variable names. Here is the sample code:
Envrionment.Value("Current_Status") = "none"
Environment.Value("Fail_text") = "none"
Call AddCriteria("Environment.Value(""Current_Status"")","Environment.Value(""Fail_text"")")
Pubic Function AddCriteria(varStatus,varActual)
varTemp = ""
Execute(varStatus+ "=InProgress") 'change status to InProgress by the time execution is done
Execute(varActual + "=not_defined") 'this will have the reason the case failed
....code
If varTemp = "FAIL" Then
Execute(varStatus+ "=PASS")
Execute(varActual + "=PASS")
Else
Execute(varStatus+ "=FAIL")
Execute(varActual + "=Criteria did not get added")
End If
End Function
On calling the sub-routine i want the value of Environment.Value("Current_Status") to change from "none" to "InProgress" and then to "PASS"
But after the "Execute" command is executed, the Environment variable become empty.
Since CVar is not supported in VBScript, i cannot use it.
I tried Eval, but it doesn't work in the other direction i.e.:
If you change the value of Environment.Value("Current_Status"), then the value Eval(varStatus) changes, but I could not find a way to change the value of Eval(varStatus) so that the value of Environment.Value("Current_Status") changes.
Please help out. I am stuck at this for a week.
!!!What I'm trying to accomplish!!!
In a .vbs file, pass on any string to a function as a parameter; and convert it into a variable name in that function. Simple example: pass a string "abc" as a parameter to a function -> and within that function, convert the string to a variable name to store value [say, abc = "PASS"]
!!!How I attempt to do it!!!
I tried using Execute command as that is a solution that I got from a previous post
[vbscript Eval a string to a Variable in a loop?
Using "CVar" is a way but that is not supported in VBScript. So I ran out of ideas
!!!Problems that I faced!!!
Honestly, I didn't understand the logic of using "Execute", but i tried it nevertheless. Sadly, it didn't work out. When using execute command (as mentioned in the code), the environment variables become empty.
Ideas:
Use ExecuteGlobal to execute the assignment you want to execute --
if that´s what you want. Eval and especially Execute have subtle limitations regarding the scope they live in.
The target variable (i.e. the variable that receives a value in the
assignment that is evaluated by ExecuteGlobal) must be a global
variable.
If the ExecuteGlobal call happens on an Action's global scope, the
target variable must be declared there, too. (I think.)
If the ExecuteGlobal call happens in a routine in a function
library, the target variable must be declared there, too. (I know that for sure. But read on.)
To further help you, I'd need an update on your question because it is not clear what you want to accomplish, and what problems you see. Because -- Eval does not change values, it just evaluates an expression supplied as a string, and returns its value. If the expression has side-effects, like setting a global variable, then you might be out of luck because...well...it depends on where that global variable is declared, and initialized (if at all), and where the ExecuteGlobal call happens. Actions and libraries do NOT share one global scope, even if it looks like they do, and that can create a lot of strange behavior.
But as I said, if you clarify what you are trying to accomplish (got 90% of that), how you attempt to do it (got 40% of it), and what problems you face (got 10% of it), I´m sure I can update this answer so it approaches a solution.
** Update **
I use this library code for all runtime expression evaluation, be it from within a library or Action:
' Interpret (execute) a piece of VSH source code consisting of statements -- success?
' Code: String containing VBS source code. Passed by reference for performance reasons only
Public Function ExecCode (ByRef Code)
Dim ErrNumber
Dim ErrDescription
On error resume next ' Avoid getting kicked out by errors in the code contained in Code
ExecuteGlobal Code
ErrNumber=Err.Number
ErrDescription=Err.Description
On error goto 0 ' Re-enable RTE handling
If ErrNumber <> 0 Then
ExecCode=false
Print "Code execution failed ('" & ErrDescription & "'), code:" & vbNewline & Code & "<eof>"
else
ExecCode=true
End If
End Function
Dim GlobalVar
' Interpret (execute) a piece of VSH source code consisting of a single expression -- success?
' Expr; String containing a VBS expression. Passed by reference for performance reasons only.
' Target: Variable receiving the value to which the expression evaluates
Public Function EvalCodeAndAssign (ByRef Expr, ByRef Target)
' In order to force "Option explicit", we don´t use Eval, but ExecCode (and thus ExecuteGlobal):
Dim Code: Code="Option Explicit: GlobalVar=(" & Expr & ")"
Dim Result: Result=ExecCode (Code)
If Result Then
Target=GlobalVar
End If
EvalCodeAndAssign=Result
End Function
Update 2: if the statement that you pass to ExecuteGlobal contains quotes (which I think are missing in your code), the must be quoted, I.e. you must use double-quotes, like in
ExecuteGlobal "x=""This is a string"""
Because what ExecuteGlobal/Execute/Eval do is: take a string and interpret it as VBScript code. The code you are trying to use is not valid due to missing quotes.
I am using QTP 11.5 for automating a web application.I am trying to call an action in qtp through driverscript as below:
RFSTestPath = "D:\vf74\D Drive\RFS Automation\"
LoadAndRunAction RFStestPath & LogInApplication,"Action1",oneIteration
Inside the LogInApplication(Action1) am calling a login function as:
Call fncLogInApplication(strURL,strUsesrName,strPasssword)
Definition of fncLogInApplication is written in fncLogInApplication.vbs
When I associate the fncLogInApplication.vbs file to driverscript, am able to execute my code without any errors. But when I de-associate .vbs file from driverscript and associate it to LogInApplication test am getting "Type mismatch: 'fncLogInApplication'"
Can anyone help me in the association please. I want fncLogInApplication to be executed when I associate to LogInApplication not to the main driverscript.
Please comment back if you require any more info
There is only one set of associated libraries that is active at any one time: That is always the outermost test's one.
This means if test A calls test B, test B will be executed with the libraries loaded based upon test A´s associated libraries list, not B's.
This also means that if B depends on a library, and B associated this library, but is called from test A (which does not associated this library), then B will fail to call (locate) the function since the associated libraries of B are never loaded (only those from A are). (As would A, naturally.).
If you are still interested: "Type mismatch" is QTPs (or VBScript´s) poor way of telling you: "The function called is not known, so I bet you instead meant an array variable dereference, and the variable you specified is equal to empty, so it is not an array, and thus cannot be dereferenced as an array variable, which is what I call a 'type mismatch'."
This reasoning is valid, considering the syntax tree of VB/VBScript: Function calls and array variable dereferences cannot be formally differentiated. Syntactically, they are very similar, or identical in most cases. So be prepared to handle "Type mismatch" like the "Unknown function referenced" message that VB/VBScript never display when creating VBScript code.
You can, however, load the library you want in test B´s code (for example, using LoadFunctionLibrary), but this still allows A to call functions from that library once B loaded it and returned from A´s call. This, and all the possible variations of this procedure, however, have side-effects to aspects like debugging, forward references and visibility of global variables, so I would recommend against it.
Additional notes:
There is no good reason to use CALL. Just call the sub or function.
If you call a function and use the result it returns, you must include the arguments in parantheses.
If you call a sub (or a function, and don´t use the result it returns), you must not include the arguments in parantheses. If the sub or function accepts only one argument, it might look like you are allowed to put it in parantheses, but this is not true. In this case, the argument is simply treated like a term in parantheses.
The argument "bracketing" aspects just listed can create very nasty bugs, especially if the argument is byRef, also due (but not limited) to the fact that VBScripts unfortunately allows you to pass values for a byRef argument (where a variable parameter is expected), so it is generally a good idea to put paranthesis only where it belongs (i.e. where absolutely needed).
I have one project which provides a service to the others, and the return value of the method that provides this service is String. Within that project, I use some named constants to represent special out of band values that are returned in lieu of expected or recoverable errors, otherwise the service returns an XML string.
Something like the following:
' modService.bas
const SERVICE_BADARG as String = "Unsupported argument."
const SERVICE_TOOMANY as String = "Too many Foos."
' cServiceProvider.cls
Private Function GetXMLString() as String
' generate and return XML string holding all sorts of generic stuff
End Function
Public Function PerformService(argument as String) as String
' do some stuff
If (some_condition = true) Then
PerformService = SERVICE_BADARG
Else If (some_other_condition = true) Then
PerformService = SERVICE_TOOMANY
Else
PerformService = GetXMLString()
I'd like to be able, from other projects, be able to get at these constants without redundantly defining them. If possible, I'd also like to avoid putting them in the class (where they will be duplicated unnecessarily) and to avoid making a property for each one.
They are all constants, none of them ever change.
Why not just define the constants in a CONSTANTS.BAS module, and then include that in each project? That way, to VB it would look like the definitions were duplicated, but from your perspective as a developer and a maintenance programmer, the definitions would all be collected in a single place?
Another option would be to create a DLL that defined the constants, but that would make using the values of those constants more costly in all of your code because rather than being compiled directly into the object code, they would have to be retrieved from a call to an external DLL. That seems like overkill for something that is truly constant.
Consider that a "constant" value is not necessarily the same thing as a "read-only" value. A constant value, like pi, will never change, so there is really not much to be lost by duplicating those values. You won't ever need to go back in and change them. Read-only values (like your error message strings) might change, so they're not really constants. It might make sense to place those into a DLL. Especially since performance isn't all that critical when all you're trying to do is shown an error message.
Unfortunately, VB gives you no mechanism of embedding constants into DLLs for compile-time use. You would have to return properties, as you said you didn't want to do.
I would definitely use the BAS route, unless there is a reason against it. An alternative to this would be to create a type library, and define the string constants in there. To do this, you will have to learn ODL, and use the MkTypeLib.exe program which comes with VB6. Or, if you somehow have access to "Advanced Visual Basic 6.0" by Matt Curland, there is a tool which allows you to create type libraries.
I know this is old, but in case anyone is still wondering...
try this pattern:
Public Function SERVICE_BADARG() As String
SERVICE_BADARG = "Unsupported argument."
End Function
Public Function SERVICE_TOOMANY() As String
SERVICE_TOOMANY = "Too many Foos."
End Function
Or more compactly with colons to put stuff on the same line:
Public Function SERVICE_BADARG() As String: SERVICE_BADARG = "Unsupported argument.": End Function
Public Function SERVICE_TOOMANY() As String: SERVICE_TOOMANY = "Too many Foos.": End Function
You could see a constant as a function without arguments. The advantage is that a function can be public, so you don't have to create a DLL. It also gets around only being able to declare them before other functions. VB6 allows you to hide the brackets:
x = "error: " & SERVICE_TOOMANY
Select Case y
Case SERVICE_BADARG
z = "error: y is a bad arg"
Case SERVICE_TOOMANY
z = "error: y is too many"
End Select
The disadvantage is a little overhead, but this is typically negligible
I have run into an annoying problem in QTP (Quick test pro) using VBScript.
I have defined this sub in VBScript (I have also tried defining it as a function with the same result):
Sub KillProcess()
KillprocessIE = "The process i want to kill"
Set ProcessList2 = GetObject("winmgmts://.").InstancesOf("win32_process")
For Each Process In ProcessList2
If Process.Name = KillProcessIE Then
Process.Terminate
Exit for
End If
Next
End Sub
But when I try to run it either by using
call KillProcess()
KillProcess()
KillProcess
I get an error saying "Typer stemmer ikke overens: 'KillProcess'" with translated from Danish means something like "Types does not match: 'KillProcess'. I am guessing it is a type mismatch error but due to translation I cant be sure.
What types is it talking about? I have no arguments in my function call and I am not assigning any values to anything?
It should also be said that if I run the exact same code directly without defining it as a function, it works without issue.
Whenever you call a sub or function that is not defined, you get a type mismatch error.
Even though this is a miracle per se (for which I could find a reasonable reasoning for only for functions, not for subs) it indicates that in your specific scenario, KillProcess was not known in the script in which you called it.
Possible causes:
The KillProcess declaration was in a function library which was not listed in the
associated function library settings dialog.
The KillProcess declaration was active, but your call(s) contained one or more typos,
like "KillProccess", or similar stuff.
As Motti indicated, the code snippet you posted looks fine, so there must be some other glitch.
Another hint regarding subs versus functions: Be aware that you usually never call a Sub with brackets for the arguments. If you do specify them, they are considered to be part of a term to be evaluated, and since
X term
is the same as
X (term)
this consequently does not yield an error message in this case.
However, for Subs with two or more arguments, specifying all actual arguments in one bracket pair, like in
Y (term1, term2)
yields an error, something like "cannot call a Sub with arguments in brackets", or so. This is hard to understand if you consider that one argument indeed can be specified in brackets.
(For a more complete overview about the paranthesis topic, see ByRef and ByVal in VBScript and linked questions).
General suggestion: Use
option explicit
at the top of all scripts (especially function libraries) all the time. RTFM this if needed. It might look like more work (because it forces you to declare all variables before you can use them), but it is useful to avoid subtle bugs.
I think you have run into the strange behavior QTP but though logic when you understand why.
The reason for why this occurs is probably because you "run from step" call KillProcess() and having the function defined above like:
Sub KillProcess()
.
.
.
End Sub
call KillProcess()
If you run the code from "Call KillProcess()" QTP will return the "Run Error" "Type Mismatch"
If instead let the function be defined below the executing statement like this
call KillProcess()
Sub KillProcess()
.
.
.
End Sub
Then QTP "knows" the function that you are calling and will execute the script like it should.
The reason for this is, that when using "Run from step" only reads the line of codes from the step and below and not what you have written above.
I have the following VB.NET code (but for each loops are in most languages, thus the language-agnostic tag):
Public Function VerifyServiceName(ByRef sMachineName As String, ByRef sServiceName As String) As Boolean
Dim asServices As System.ServiceProcess.ServiceController() = System.ServiceProcess.ServiceController.GetServices(sMachineName)
Dim bVerified As Boolean = False
For Each sService In asServices
If sService.DisplayName = sServiceName Then bVerified = True
Next
Return bVerified
End Function
If I have X number of services to loop through, and my service name is #3. Is it better to have multiple return statements or an exit for? Or is there a more efficient way of writing this function?
I know that the time difference between looping X times and looping through 3 times could be marginal for what I am doing, but I always have performance on the brain.
I personally believe having one return at the bottom is far more readable and easier to debug than if you have return statements everywhere, as you can never tell when the function is going to exit so you end up putting breakpoints on every return statement instead of just once at the end, for example.
I think it's all down to preference though, as there are valid arguments for both ways.
Found more discussion here about the subject. I guess I am not that proficient at searching.
I would never use a goto as the target of another goto, so if there's some additional processing at the end of the function, use "break / Exit For", otherwise just return early. Otherwise you end up with lines that mean "return" but say "break"... that doesn't help maintainability.