QuickTest on the Right
My company is good to me. They give me two 19 inch LCDs to look at all day. Unfortunately, Mercury Interactive isn’t as good to their employees. If they were, their developers would write software that works well on a dual monitor system.
I’ve spent quite some time struggling with a problem in QTP 9 where it won’t click on a button in a dialog box. I didn’t think to try moving the application to the other monitor until I called support. Fortunately, I happened to mention that the dialog was on my right monitor which tipped the support engineer off that I have multiple monitors, and he was able to tell me what the problem is. He said there is little chance of Mercury fixing the problem anytime soon because there is a workaround — only use one monitor.
I’m not writing this to get you to all sympathize with me, but to tell you that there is a way out of this single-monitor bondage. After finding out this is a monitor related issue, I tried switching monitors. Previously I had QuickTest on the primary display and IE on the secondary. I switched that around so that QuickTest is on the right (secondary) monitor and IE is on the left, and it is working beautifully.
Tags: Dual-Monitor, QTP-Bugs, QuickTest Pro, Software-Testing
March 30th, 2006 at 10:17 am
I had an issue like that once before, and was simply told that Mercury doesn’t support multiple monitors at all.
What sucks about this particular issue is that it worked just fine in version 8.2.
So, if you’re keeping score, they made a feature work in 8.2 that they didn’t support, and then when they broke it in version 9 they pulled the “we don’t support that” trick.
Nice.
The incident I reported was also with version 9:
- Maximize QTP 9 in the RIGHT-HAND monitor
- Put any script in debug mode (can be a single-line script, where “wait 1″ is the only line, and select “debug from here”)
- Without stepping through any code, use the Object Spy to identify an object (any object, not necessarily a web object)
- After you click on the object, the QTP 9 window will immediately maximize in the LEFT-HAND monitor, and it will stay there until you move it back manually
They aren’t planning to fix that.
Reply to Marcus
July 25th, 2006 at 12:08 am
There is a way to get around it.
Public Const WM_COMMAND = &H111& ‘This constant is used to indicate we are going to interact with a Command dialog box
Extern.Declare micHwnd, “FindWindowEx”, “user32.dll”, “FindWindowExA”, micHwnd, micHwnd, micString, micString
Extern.Declare micLong, “PostMessage”, “user32.dll”, “PostMessageA”, micHwnd, micLong, micLong, micLong
Hwnd = extern.FindWindowEx(0,0,vbNullString, “Microsoft Internet Explorer”)
lResult = extern.PostMessage(Hwnd, WM_COMMAND, buttonCode, 0)
‘Use OR Spy for buttonCode. Usually ‘ok=1, cancel=2, abort=3, retry=4, ignore=5, yes=6, no=7
Email me if you have any questions.
Reply to Igor