Tabbing in browser - erratic results

[terrypin]

If I open a specific web page I can reach the box I need to change in 33 tabs. But when those steps are taken with TextType commands I get unpredictable results. Usually I end up 4 boxes short of where I want. But that depends on the keystroke speed. Even with that set to 1000 ms (a full second between tabs!) it still falls well short.

 

Another variable is whether I run it from ME Pro Explorer or the Script Editor Debugger. Why should that affect it?

 

Controls don't work (as usual) but I'll now try the alternative of scrolling and mouse clicking. But I would like to understand once and for all why plain tabbing is so unreliable?

 

--

Terry, East Grinstead, UK

[paul]

And the web page is...?

[stevecasper]

How is your macro built?

 

Do you have 33 separate Text Type: <TAB> commands, 1 Text Type command with 33 <TAB>s in it, or do you use a Repeat x33 loop?

 

I can't begin to answer why Text Type commands are unreliable, as I, too, have a LOT of problems with them. With this particular situation, I've had the most success building loops that look like this:

 

Repeat Start (repeat 33 times)

__Text Type: <TAB>

__Wait for text playback

Repeat End

 

As usual, I don't fiddle with keystroke speed.

 

Occasionally I insert a Delay rather than a Wait for playback... it really depends on my mood, or something. How's that for vague.

[acantor]

The more tabbing you need to do on a web page, the less reliable the scripts become, especially when a site uses JavaScript.

 

I get the best results using these techniques:

 

Repeat X times

Text Type TAB

End Repeat

 

Repeat X times

Text Type TAB

Delay Y milliseconds

End Repeat

 

Sometimes you can get where you need to go faster and more reliably by sending SHIFT TAB instead of TAB.

 

And this is also a possibility:

 

Text Type CONTROL f ' Find

Short delay

Text Type Surname: ' Name of field you are searching for

Text Type ENTER

Short delay may be needed

Text Type ESC

Short delay may be needed

Text Type TAB ' (or maybe SHIFT TAB to reach the target

[terrypin]

And the web page is...?

 

No point telling you as it's for registered users of Magix video editors.

 

Anyway, I've had this problem elsewhere too, so I'm wondering if it's a generic issue?

 

--

Terry, East Grinstead, UK

[terrypin]

Steve, Alan,

 

Thanks both, I'll try those techniques over the weekend.

 

The page is a 'form' to the company's Support team. It requires prior user selection of options like 'Type' and 'Product'. One factor I've only just noticed is that it changes its opening appearance depending on what I entered last time. So obviously that will affect the number of tabs to reach my target box. It may well be that the problem is resolved by simply ensuring I always enter the same options, instead of assuming (as I was) that they will be recalled automatically.

 

Meanwhile I got it working by mouse clicking. One temporary snag there was that I needed to get focus back several times by clicking in empty areas of the page. That happens quite often I find, in various circumstances: focus somehow seems to get lost when a macro performs steps, yet not when those same steps are performed manually.

 

--

Terry, East Grinstead, UK

[acantor]

A technique I have used with Web applications is to identify a "neutral" column on the page -- a vertical zone where there are no links or controls anywhere on the page, and "click" there before doing anything else. (A few pixels to the right of the left edge of the screen is usually where I look for the neutral zone.) The scripts usually end up looking something like this:

 

Mouse Move ( a, b ) // Move mouse pointer to neutral zone

Left Click // Give the page focus. This is especially helpful if the last focused control was an edit box.

Text Type HOME // Go to top of page (or END to go to bottom of page)

Mouse Move ( c, d ) // Move mouse pointer to its target

Left Click

[terrypin]

A technique I have used with Web applications is to identify a "neutral" column on the page -- a vertical zone where there are no links or controls anywhere on the page, and "click" there before doing anything else. (A few pixels to the right of the left edge of the screen is usually where I look for the neutral zone.) The scripts usually end up looking something like this:

 

Mouse Move ( a, b ) // Move mouse pointer to neutral zone

Left Click // Give the page focus. This is especially helpful if the last focused control was an edit box.

Text Type HOME // Go to top of page (or END to go to bottom of page)

Mouse Move ( c, d ) // Move mouse pointer to its target

Left Click

 

Thanks Alan, I'll try that.

 

--

Terry, East Grinstead, UK

[Cory]

Most of the macros I write for my other clients these days are doing data entry pushes into java based web forms. They suck in ways I can not describe in a public forum. But what I will tell you is that it's my experience that there is no keyboard buffer in Java and similar apps. IE most apps, or more accurately windows, will queue up keystrokes in the case tha tthe app becomes momentarily unresponsive. Java appears to accept the keystrokes whether it's ready or not. This results in the occasional missed tab or even parts of typed text in a field. It's madness.

 

Normally I avoid mouse manipulations like the plague but in this case I have found that they are far more reliable. Also I find that for text fields clipboard pastes for multiple characters are more reliable. The downside is that you need to make sure your fields are always in the correct place. I haven't done it yet but next time I plan on having a setup macro that prompts the user to point to all the fields and buttons in form and save them in the registry for use in the main macro. And finally I find that creating enter, check and recover routines are useful. move thru the fields entering values then go back thru them and copy their contents and make sure your text made it. Then if it doesn't have a routine to clear the fiel;ds and try again.

 

The debugger adds extra overhead and I'm not convinced that when switching back that there isn't a hole that input can fall into. I've had times when the switching back and forth from the debug was not working and I added a bunch of Window Activates before the inputs and it worked better.

[paul]

Normally I avoid mouse manipulations like the plague but in this case I have found that they are far more reliable. Also I find that for text fields clipboard pastes for multiple characters are more reliable. The downside is that you need to make sure your fields are always in the correct place.

Well, I suppose that, having moved your mouse to a "known" location where there was a text field last time you looked , you could always then take one or more pixel measurements of some other (preferably related) area in close proximity so as to better ensure that the text field hasn't been moved. The problem with this approach is that each different graphics card (and who knows what other variables) will probably require different pixel values.

 

What a mess we human beings have made of the web. Isn't it really hard to navigate programatically?

[Cory]

What a mess we human beings have made of the web. Isn't it really hard to navigate programatically?

I accept no fault in this Every time I've been involved in a web form where people could possibly be spending hours typing in mundane information I have always insisted there be an en masse way to upload as well. IE make a nice friendly form for non-tech humans and a slick back door for those with know how.

 

However I've often wondered if one might be able to employ a more programmatic method of handling HTML forms. Like create your own local web page with a stripped down version of the form pointing to the same form handler. Hmmm... Also makes me wonder how a browser pushes data to a form handler anyway...