Not using QTP myself, but trying to answer this question, I desperately need to know, whether this valid VBScript:
Class C
Function init(x, y)
Set init = Me
End Function
End Class
Dim o : Set o = New C.init(0, 1)
will cause a syntax error in QTP - or more generally: Does QTP implement its own dialect of VBScript?
This is valid in QTP too.
QTP uses VBScript as the engine for running tests, there are some extensions on the language that allow using test objects but most of these just look like global functions and objects. As far as I know nothing is removed from VBScript.
The limitations QTP has regarding class types are regarding intellisense and such not execution of the test/script.
Related
does anyone know a cause for random overflow errors in vb6?
I have to customize a legacy application written in VB6 and lately overflow errors have started to occur all over the place. Sometimes in functions which have not been touched in years!
The error always happens when trying to assign something to a variable of type Double.
The reason for those errors is probably not the code that throws the error but something else. But I dont know what to look for. The most confusing example of a function failing with an overflow error was the following code:
Dim test As Double
test = 0#
How can that possibly throw an overflow error?
I tried enabling some compiler optimizations, like not checking for floating point calculation errors, and some more. This has "solved" some of the problems, but others remain.
VB6 will run things in such a way where if something external signals a floating-point error flag, it'll not be reported until the next floating-point operation is performed within your own code.
Under most circumstances, this is likely caused by some DLL that is performing floating-point operation. If you have any control over these external DLLs, then my suggestion is to put this line at the end of the functions called by your application:
_clearfp();
This function is documented here: http://msdn.microsoft.com/en-us/library/49bs2z07.aspx
If you do not have much control, you can get around this by making your own function called from a DLL that calls that function. Or a simple hack with only using VB6 is:
Public Sub ClearFP()
On Error Resume Next
Dim d as Double
d = 0#
End Sub
Which you can call after any DLL calls that you believe is the culprit.
A trick to isolating which function did it originally, is simply look at the calls before the error appears. Alternatively, a more complicated solution, is to compile your application and run it through a debugger that can break on floating-point exceptions.
In VB6 the hash (#) symbol can mean many things:
Used in file names
used with dates ususlly when applied to DBs
To treat Numbers as Doubles
To compile constants or sections of code if a condition is true
I'm sure there are more.
It may depend on the compiler.
My suggestion would be to try:
Dim test As Double
test = CDbl(0)
to see if that resolves the issue.
Some inBuilt functions in Vba can be called with or without its class. Which one is better to use?
When calling a Sub/Function
vba.Format(date,"yy-MM-dd")
'or
Format(date,"yy-MM-dd")
Also when dimensioning a variable, the class might or might not be used. In this case, which would be better?
Dim xmlDoc As MSXML2.DOMDocument60
'or
Dim xmlDoc As DOMDocument60
I tend to use the class and name just in case someone has defined a function/Sub/type that could bring conflicts. But how about performance? When having a great amount of codes and procedures, could one or the other have an impact on performance/speed?
Is there any other aspect to take in account when deciding whether to use one form or the other?
If I am understanding you correctly, and if my understanding of VBA is correct, then it doesn't make much difference in terms of performance whether you qualify the property or method with the library prefix. I don't think it is necessary to qualify the objects referenced within the vba library (If you are indeed working in a vba environment, as opposed to say .net using interop), but when you set external references (such as MSXML2, or Scripting), it might be beneficial to fully qualify the function reference for clarity.
Using the fully qualified name can improve clarity (in some cases). A year down the road, when someone else goes to maintain your code, it can be helful for them to recognize that certain functions are defined in a referenced library (such as MSXML2). Also, in cases where the referenced library contains a function with the same name as either the vba library, or another library set as a reference, you will need to qualify the function name.
Fully qualifying function names from referenced libraries is probably good practice. While the vba library is ALSO set as a reference from within a vba application, my take would be that is the one library you DON'T need to qualify.
Note that using fully qualified names DOES mean some extra typing. Since you app is written in vba, using vba.Function would be semi-redundant. But for referenced libraries, you need to choose between clarity/maintainability, and ease of typing (I have subscribed to the school that says "write the code in a way that will benefit the next person who has to deal with it" before making it "easier" for myself to write.
I need to write some vbscripts in my new project. I was told by other people that vbscripting is easy, but seems to me, it is not. For example, in the following example (provided by microsoft), these functions: CreateObject, CreateShortcut, as well as these property names: TargetPath, WindowStyle, Hotkey, etc, are used, but I just cannot find the corresponding API documentation about how to use them. In other words, how do you know you need to call these functions in your vbscripts? Visual Studio 2008/2010 do not have templates for vbscript either. Could anybody tell me what I am missing, and what the best way is to do vbscripting?
set WshShell = WScript.CreateObject("WScript.Shell")
strDesktop = WshShell.SpecialFolders("Desktop")
set oShellLink = WshShell.CreateShortcut(strDesktop _
& "\MyExcel.lnk")
oShellLink.TargetPath = _
"C:\Program Files\Microsoft Office\OFFICE11\EXCEL.EXE"
oShellLink.WindowStyle = 1
oShellLink.Hotkey = "CTRL+SHIFT+F"
oShellLink.IconLocation = _
"C:\Program Files\Microsoft Office\OFFICE11\EXCEL.EXE, 0"
oShellLink.Description = "My Excel Shortcut"
oShellLink.WorkingDirectory = strDesktop
oShellLink.Save
Take a look here (MSDN).
The objects you are working with are documented there (of course, it's MSDN documentation so it's not ideal, but it's documented nevertheless).
Specifically the WshShortcut Object and the WshShell etc.
I don't think VBScript is a very easy language, especially if you need to write larger scripts.
If you don't specifically need to write a script but it would be ok with an executable I'd look at using VB.Net instead, where you have a good development environment that makes everything much easier since you have Intellisense and you can just press F1 for the documentation. And since it's a typed language with a large framework it gets easier to avoid mistakes and many operations you need you can just call a method in the framework rather than writing your own code.
However, if you do need to do it in VBScript, I'd suggest trying to find some kind of IDE for it. I haven't used any, but at least this one seems worth looking at.
The language of VBScript is relatively easy. It's a subset of Visual Basic and VBA and simplifies some things from those environments (eg you don't need to declare variable types).
What you are dealing with above is working with the methods and properties of a given object, WshShell. There are many many objects out there, each with their own set of methods and properties to know about, many with common usage conventions, and many more with "unique" (ie idiosyncratic) usage requirements. This is where the complexity comes in, but it's not part of VBScript itself. You will run into this with any other language (JScript, Python, Delphi) that works with the myriad objects and APIs that are out there for Windows system management.
The plus side is that once you get used to the language of VBScript and the process of looking up object API references and examples on MSDN and other sites, it does become very easy to put together complicated and powerful scripts.
Like I frequently tell users, computers often make things faster the second time you do something. The first time usually requires some learning.
A great set of resources for learning VBScript and how you need to approach things is the
TechNet Script Center, their Hey, Scripting Guy! series, and the Script Repository.
I'm expecting a ByRef Argument Type Mismatch at compile time but I'm not getting it. It's compiling without errors and failing at runtime with error 13, "Type mismatch".
It's a fairly simple to reproduce.
dim c as Car
Set c = New Car
Sail c
...
Public Sub Sail(ByRef b As Boat)
...
End Sub
Car does not inherit from Boat
Is there a setting (or plugin perhaps) that will force VB into a strict compilation mode?
Edit: it looks like there's no compiler option for this. Does anyone know of an addon that analyses the source for these casting issues during a compile?
Is it possible to set Option Strict True in VB6?
Edit: Apparently it is not possible in VB6 (seems to have been introduced with VB 7.0)
Does anyone know the reasoning behind having the option using:
Wscript.CreateObject("some.object")
and
CreateObject("some.object")
within VBScript? when I find documentation or examples that use Wscript.CreateObject, I usually rewrite using CreateObject, because it always seems to work, and then I can easily reuse the code within an HTA or ASP. But I've always wondered why this feature existed and if what difference it makes if you use one way or another within VBScript.
There's no difference between the two, when you call them with just one argument. The do exactly the same thing.
The difference between the two is only in evidence if you call with two parameters. The statements
Wscript.CreateObject("some.object", "AnotherParam")
and
CreateObject("some.object", "AnotherParam")
do completely different things:
The VBScript CreateObject function interprets the second parameter as a remote computer name and tries to create the named COM object on that remote computer; in this example, it tries to instantiate an instance of an object with ProgId of "some.object" on a remote computer named "AnotherParam". The WScript CreateObject method interprets the second parameter as a subroutine prefix to be used in handling events from the object. The two GetObject functions are similarly related.
(Adapted from TechNet,
section "Comparing VBScript CreateObject and GetObject Functions with WSH".)
I guess that the WScript object has the CreateObject method so any Windows Script language can create COM objects.
VBScript has that ability as a global function, but other Windows Script host languages might not.
For instance, JScript does not have a global CreateObject function (I believe) (it does, however, have a var a = new ActiveXObject("...") syntax, so you do not need to use WScript.CreateObject in JScript either).
I would guess there is no difference between the two functions.
EDIT: There is a difference (but only if you're trying to instantiate DCOM objects on remote hosts), see the answer by #Thomas Petersen.
JScript does not have a global CreateObject ?
WScript can't use JScript ?
Code from devGuru
// JScript
var objIE = WScript.CreateObject("InternetExplorer.Application","objIE_")
objIE.Visible = true
while (objIE.Visible){
WScript.Sleep(500);
}
function objIE_NavigateComplete2(pDisp, URL){
WScript.Echo("You just navigated to", URL)
}
function objIE_OnQuit(){
boolBrowserRunning = false ;
}