But be aware that using the .object 'object extension' technique, upon the data entry the control's events will NOT get triggerred.
The above solution is more of a forced 'entry' than a data entry in a normal run time state.
Imagine that you have a validation that should be performed when you leave the edit field. Object extension has the power to 'intrusively' set values without giving focus to the control and thus using this technique your control will accept any input and your validation will not get triggerred. Try feeding any garbage data and you'll see what i mean.
It is not the settext that really takes up your five seconds. These methods actually first create their own temporary 'T' object on which they operate and that's what may normally take a few seconds.
You may alternatively try the following:
At the start of the script create the following objects:
TestPartner.Playback.TypeDelay = 1 'Default is 4. Wait only 1 millisecond between keystrokes
'Variables names for illustration purposes only.
Dim p8fa1 as HTMLEditBox as THTMLEditBox
Dim p1403 as HTMLEditBox as THTMLEditBox
Dim pb8b4 as HTMLEditBox as THTMLEditBox
Dim p394f as HTMLEditBox as THTMLEditBox
Set p8fa1 = HTMLEditBox("Name=p8fa1")
Set p1403 = HTMLEditBox("Name=p8fa1")
Set pb8b4 = HTMLEditBox("Name=p8fa1")
Set p394f = HTMLEditBox("Name=p8fa1")
Really works! Not only did it speed things up, it also fixed the problem I've been having with the SetText screwing up the character case.
Each time I used SetText with a capitolized word like Washington, it would be displayed in the edit box like: wASHINGTON which is a real problem when your dealing with passcodes that are case sensitive...
jtdev - what you describe sounds like a defect in code that you are making go away by manipulating the test. Be very very careful. Alarm bells are going off.
As Flaggman said, using object.value bypasses any kind of triggering and/or client side routines. If there is code that is being triggered on entering the capitolized Washington that changes it to wASHINGTON, you are bypassing that code. In that case, you have the following problems:
1. You have a defect in code that you have not documented.
2. Your test is invalid because it is not testing the normally triggered code.
3. You are artificially passing a test that would normally fail.
.object.value should NOT be used routinely simply to speed things up or change the way the test interacts with the app.
The only time I ever use object.value is when I am running a data entry routine (i.e. NOT testing) and I am not interested in firing all the validation routines because I already know my data is accurate.
So, DSquared are you saying that when TP performs the .SetText method inaccurately such as not clearing existing text when the .SetText method is performed that it is a bug in the AUT code? I would hope this is not what you are insinuating.
We have had issues using the .SetText method through multiple versions of TestPartner and our product. We have products that use two entirely different technologies where .SetText does not work properly.
The reason I pose this questions is that my team has tried everything from changing the timing between the .Attach method and the .SetText method to modifying operating system settings. To date we have managed to work around the issue by looping until the .SetText method input matches our test input data. I am almost certain our issues arenít caused by a defect in our product but rather a defect in TestPartner. I have reported this issue to Compuware and have been waiting for at least an explanation of why this occurring for almost two years now.
No, I'm not saying that issues with settext are bugs in the application code. I am simply saying that you can't discount it. I could flip your question around and ask if you are insinuating that your app is good and the tool is bad. I certainly hope you are not jumping to that conclusion. In your case, you clearly state that the issue is that TP settext method is not accurate. How do you KNOW that it is TP? What data or proof do you have to say that it is TP and not your app?
I had an almost identical case and everyone told me that TP was at fault. So we changed the automation to object.value and we got the test to work the way we thought we wanted. People assumed the tool was at fault.
We went to production and guess what? The problem surfaced again without using the automation. It turned out to be an issue with the application that was masked because we were told to change the test.
To be sure, there have been problems in TP, but they are usually addressed via a service pack. What version of TP are you running? Perhaps you have a buggy version.
The caution is this: don't assume that bugs are in the tool and not in the application. There are multiple sources where an issue can be introduced. Don't assume that it is the tool. You will do yourself a disservice if you do. Unfounded assumptions will kill you in QA.