Alt Menu Follies

Eggplant Functional
#1

So, I’ve been using a script that invokes the ALT menu on our Windows Application to Add a “Form”…

Alt F
Return
W
F

or

set the remoteWorkInterval to 1.1
set the mouseMoveSpeed to 8
set the nextKeyDelay to 0.15
DoubleClick “StartDevXP”
Wait 4.0
// Click “ClickInsertMenu”
TypeText “\af\A”
TypeText “\r”
Typetext “w”
Typetext “f”

It has always worked but now is failing 50% of the time. When I go through these steps Manually using the keyboard on the SUT. Everything is fine with our application. I’m stymied.

I’ve tried inserting Wait 4.0 etc…

Thanks

#2

I suspect your app still isn’t quite ready for keyboard input

Try this:

waitfor 5.0, ClickInsertMenu --or some other thing that indecates the app is ready to rock and roll.

That will guarantee that the SUT is ready for keyboard input. You could also stick in a waitfor between the alt-F and the RETURN key.

The beauty of waitfor is that it won’t necessarily wait the entire 5 seconds.

I know MR. P will get after me for this :mrgreen:, but try using StartMovie/StopMovie to wrap this sequence of events into a QT movie. Some very interesting things may reveal themselves. :smiley:

#3

Hmmm… well, I don’t think Waitfor will work since I’m not really waiting for an image but rather sending a keystroke.

I don’t have the movie thing on mine… we fear change.

Here… if you have a sec I can illustrate the problem

go to tawala.no-ip.org
login with 6969

I’ve left the ALT File menu in a dropdown state for you.

Get eggplant to type a “w” ( TypeText “w” ) which should just bring up the:

Add New Menu

You will see that the Add New Menu only pops up for second… then winks out again.

IF I were to walk over to the SUT and simply type a “w” on the keyboard… it would stay up …IE… our application works as it should.

I think Eggplant is sending some extra info or keystroke?

I’m not… really… sure…

#4

Eggplant generally types the key itself very quickly. It might be that we are tapping it very fast invoking a different mechanic (why this would have changed is a mystery).

You can try slowing down the actual duration of the keypress with:

set the keyDownDelay to 0.1 (default is .001)

#5

Odd… that seemed to do it. Don’t know why things would have changed though? Maybe the nature of my network connection effected VNCs abilility to communicate keystrokes back and forth?

Very interesting…

#6

Nope… I take it back… that really had little effect. Would I need to put that Keydowndelay into my master? Don’t see why since it’s in all my other scripts…

My failure rate with ALT menu / Keystrokes is about 50/50…

Hmmmm

odd

#7

Network communication is a possible, although in this case the problem seems to be that sending the down and up is hapening TOO quickly (rather than too slowly).

I would love to see if you can duplicate the “fast tap” behavior on the machine/app directly; if so you may have uncovered something in the menu handling routine that would be best if it were corrected. (Although in human speed .001 is incredibly fast, but 0.1 is actually pretty slow for a keypress).

#8

I just ran against your advertised system #128(DEV) with a 50 repeat test and it ran without failure.

What does that suggest? It reinforces my belief that it is a timing issue on on the down and up keypress. (Since I’m sure my latencey is more than 0.001). This is also bolstered by the fact that you ARE getting a UI effect from hitting “w”.

One additional possibility is that the mouse is left in a place that “impedes” the menu selection (like it’s hovering somewhere else on the File menu and is causing the menu to jump).

#9

Cool. Thanks 4 that…

I’ll tinker with the script and see if I can fix clean it up.