July 2, 2009

Selecting from a Drop Down List

Filed under: Automation,Scripting — Marcus Tettmar @ 1:12 pm

A project I’m currently working on involves populating data into a rather poorly designed user interface.  A particular challenge were the drop down lists and list boxes due to the fact that you can’t “drill down” by sending the text of the item you want selected.

The solution we settled upon uses the text capture function GetTextAtPoint in a loop which arrows down the entire list, with GetTextAtPoint capturing the text in the selection box to see if it’s the value required.  If it is we stop, else we continue to press down and loop.  We stop if the item selected is the same as the previous item, signifying that we’ve reached the end (obviously this assumes the list doesn’t have duplicates appearing together).

Here’s the subroutine:

SRT>dropDownSelect
/*****
Usage: GoSub>dropDownSelect,X,Y,text_to_select

Where X and Y are coordinates in the edit box (where the item appears once selected)
 and text_to_select is the text you want selected  

Important: the drop down needs to have the focus
*****/
  If>dropDownSelect_Var_3<>
    GetTextReset
    Press Home
    Wait>0.1
    Let>prev_comboText=Z@$%#XXX
    Let>dropDownFound=FALSE
    Label>select_drop
    GetTextAtPoint>dropDownSelect_Var_1,dropDownSelect_Var_2,comboText,c
    Pos>dropDownSelect_Var_3,comboText,1,p
    If>p<>1
      If>prev_comboText<>comboText
        Press Down
        Wait>0.2
        Let>prev_comboText=comboText
        Goto>select_drop
      Endif
    Else
      Let>dropDownFound=TRUE
    Endif
  Endif
END>dropDownSelect

So, for example, you could call it something like:

Press Tab
GoSub>dropDownSelect,240,355,Apples

Note that the drop down needs to be focused. Usually you’d be “tabbing” through fields on the form, so once you’ve used “Press Tab” to get focus onto the control you can call dropDownSelect.

This version requires that you pass the X,Y screen position of the text box area of the drop down. In development at the moment we have a new function which returns the handle of the currently focused object, and this can then be used in GetWindowPos to get the X,Y position. So in future you will be able to determine the X,Y position dynamically.

Hopefully you won’t need this function as you can usually “drill down” on a list box or drop down list by sending the text of the item you want as mentioned here. But for those badly designed controls that won’t allow that this function can be a life saver.

May 9, 2014

Macro Recorder vs Code Wizards

Filed under: — Marcus Tettmar @ 11:59 am

Macro Scheduler includes a Macro Recorder. In the early days it didn’t have one. In fact we resisted adding one at first.

We didn’t want to add a macro recorder because we believe their power is limited and the reality is that at some point you have to edit the code it produces. A macro recorder records an entire sequence. If you want to alter a part of that sequence in the middle you can’t really do that with a macro recorder. You need to edit the code.

More importantly there’s a limit to how clever a macro recorder can be. To work everywhere, in every app, it can only really monitor your keystrokes and mouse moves. Our Macro Recorder also monitors window positions and sizes, and creates code that sets the window positions and sizes to be the same at runtime as they were at record time, to try and eliminate issues where positions change between design time and run time.

Even then window names can be different at run time, and for most business processes the data you are entering is going to be different next time around – you are probably going to want to loop the input to work for different records. So you’re going to have to edit the code that was produced. Sure, this can be done – you can edit the code our Macro Recorder produces, but if you’re going to do that then maybe it would have been easier to write the code in the first place?

Also, we had experience of macro recorders and writing scripts manually. We knew that we got smaller, tighter, more reliable macros when coding manually. But rather than leave our customers staring at a blank white editor window we provided wizards and code builders.

Eventually we did add a macro recorder mostly due to overwhelming demand. See, IMO people think they need a macro recorder, but really don’t. And because of that we needed one commercially. Without one many people wouldn’t have given us a look-in. I am pretty certain that most people end up not using it and soon move on to more flexible methods.

I believe we offer something just as easy but far more powerful than macro recorders. Right from the start Macro Scheduler had “code builders”. We didn’t call them that back then but to output script code you could choose from drop downs and so on. Nowadays, of course, we offer a full featured script editor, but every function also has a code builder and there are wizards for the slightly more tricky routines that require a bit more code, or where you would usually need to poke under the hood of an app.

These wizards are incredibly powerful. They allow you to build up macros without any programming skills. They allow experts who do have programming knowledge to build code quickly. They allow you to address specific parts of a routine in isolation, whereas a macro recorder generally requires you to perform a number of steps with no way to jump into the middle of a routine.

Just watch these videos to see how easy it is to build up a script to automate the control of applications and web apps using the wizards:

How to use Macro Scheduler’s Image Recognition Functions
Using Macro Scheduler’s Find Object Wizard
Using Macro Scheduler’s Find IE Element Wizard

Of course, the macro recorder has it’s uses. For basic stuff and for complete newcomers who just want to automate a few keystrokes or mouse actions it might make sense. There’s also a keyboard wizard, and a mouse wizard which are effectively just mini recorders, which are useful when you want to insert small blocks of keyboard/mouse events into a script.

However, for anything robust and dynamic the wizards are far more powerful yet just as easy to use.

Consider a scenario where you need to open the most recent Excel file in a folder, and grab some data from it and input that into another window. How would you record finding the latest file in the folder and opening it in Excel? Believe it or not I’ve seen people do this by automating mouse clicks – they open Windows Explorer, click on the columns to sort, click on the first item – and they make all kinds of assumptions such as the size of the window, the original sort order and so on. Then they proceed to mouse click in Excel.

When I see people do this, first I scream, and then, when I’ve calmed down, I show them how to do the same using a few basic commands, using the code builders and some wizards.

To find the newest file in a folder? There’s one line of code for that, using the GetNewestFile command. Not sure how to use it? Open up the code builder and it will tell you what you need to enter – the folder to look in and a variable to store the result in.

That’s one line. Instead of lots of crazy mouse clicks. Next, we can open the XLS file up with one XLOpen line. There’s even a sample macro which ships along with an example XLS file which shows this in action. And a code builder. Next use XLGetCell to get the data. Right, so that’s three lines of code instead of dozens of mouse clicks and waits. Finally use the send keys wizard, or find object wizard or code builders to send the data into the target app.

It’s really no more difficult than using the macro recorder and probably quicker. And you get shorter, tidier, more reliable code that is easier to understand.

So for me, wizards win out every time. I believe wizards provide the simplicity of macro recorders but with the power and reliability of manually written code.

November 18, 2010

WebRecorder Update

Filed under: Uncategorized — Marcus Tettmar @ 11:23 am

WebRecorder and the IEAuto runtime have been updated as follows:

IEAuto 2.08 :

  • Added the ability to specify classname for ClickTag
  • Fixed issue where some fields may not click in IE8/9

WebRecorder 2.4:

  • Added Name/ID to Tag Extraction Wizard and will now output an ExtractTagByName if an ID or Name is present
  • Workaround for pre-focused fields to ask user to mouse click in element to identify it
  • Added detection of classname for ClickTag
  • Fix for situation where a form has no name (was previously returning [Object])
  • Removed old tag extraction drop down from toolbar and added Tag Extraction Wizard button

Registered Updates | Trial Downloads

January 27, 2010

Why Does My Script “Hang” and Never Continue?

Filed under: Automation — Marcus Tettmar @ 9:47 am

This is a variation of a question we get regularly. Usually it turns out that the script is waiting on a WaitWindowOpen line because of a typo in the window title.

WaitWindowOpen, given a window title, will cause the script to wait until a window with that title exists.

If you misspell the window title WaitWindowOpen will wait forever, because a matching window will never appear.

Rather than rely on your typing, you can select the window title from a drop down list. With the window you want to wait for open on the screen edit your WaitWindowOpen line in the Code Builder by right clicking on it and selecting “Edit in Code Builder”. Now, select the window title from the drop down box.

Remember you can also do a sub-string match using the asterisk:

WaitWindowOpen>Notepad*

This works for all window functions and will match the first window found that contains the given text (regardless of case). So the above will match “Untitled – Notepad” as well as something like “My Notepad – MyFile.txt”. It will stop at the first one found, so don’t be too general and try to find something unique.

More advanced users might be interested to know that we’re adding the ability to use Regular Expressions in the window functions for version 12.

December 15, 2008

Mass Import of Scripts and Groups to v11

Filed under: General — Marcus Tettmar @ 11:23 am

Because Macro Scheduler 11 saves scripts with Unicode encoding, and previous versions understand only ANSI encoding the decision was made to install Macro Scheduler 11 into its own folder, with its own data folder and registry hive. By keeping it entirely separate from previous versions it can run side by side with a previous version without any chance of scripts being prevented from being opened in the old version. If you open a script up in v11, save it, and then try to open it in v10 it will appear corrupt (though this is recoverable – more in a sec). So for those that will continue to use v10 for a while it is sensible to keep things separate.

However, if you are happy and ready just to point v11 at your existing setup you can do so quickly by exiting Macro Scheduler and modifying the following registry entry:

HKCU\Software\MJTNET\MSched11 – DataDir

Replace the value of DataDir with the path to your existing Macro Scheduler macro folder.

You’ll also want to copy comdef.ini from the Samples folder in the Macro Scheduler 11 Program Files folder into the macro folder above, overwriting the previous one – this contains the function definitions for the code builder – so you’ll want the v11 one.

Alternatively, if you still want to run v10 but want a complete copy, copy the entire contents of your v10 macro folder to the v11 macro folder (apart from comdef.ini). Then open up groups.ini and do a search/replace on the root macro folder so that all groups are now pointing at the new v11 folder.

In either case, make sure you exit Macro Scheduler fully first.

If you ever need to open a script in v10 (or earlier) that was edited/saved/created with v11 then do one of the following:

1. Open it in v11 and select File/Save As and select “ANSI Script Files” in the “Save as type” box, or,
2. Open it in Notepad, do File/Save As and select “ANSI” in the Encoding drop down.

October 16, 2007

What’s in a Name?

Filed under: General — Marcus Tettmar @ 4:10 pm

Sometimes I wonder if Macro Scheduler has outgrown its name. “Macro” seems too small a word, and “Scheduler” is just one small feature. It’s so much more than these two words suggest now.

When version one was released there were less than 20 commands, purely for simulating user input and manipulating windows. No script editor, just a drop down list to select the few commands you needed. And a scheduler. Macro Scheduler was the perfect name. People used it to write macros and schedule them.

Fast forward ten years and Macro Scheduler’s script language, which we call MacroScript, is now vast, with all kinds of functions, looping constructs, conditional statements, subroutines, internet functions, etc. It has a dialog designer for creating user interfaces, embedded VBScript, see-screen image recognition, a debugger, DLL functions you can use to run functions in custom DLLs and Windows API functions, and a full featured editor. There really is nothing it cannot automate. I know people who have created routines over 5000 lines long. The emphasis now must surely be on the word “automation”. But at the same time it has got easier to use.

One feels the word Macro just doesn’t do these capabilities justice. I also wonder if first time visitors might initially make the mistake of comparing Macro Scheduler to other products which are more basic.

But what’s the solution? Change the name? I’m loathe to do that for a number of reasons. There’s ten years of history, loyalty, word of mouth and Google-juice in the name “Macro Scheduler”. No way should we drop the name altogether. Or maybe we should leave Macro Scheduler where it is but start a new branch of the product with a new name? I don’t know. I do know that the word macro is searched for on Google many many times more than the word automate. So perhaps we should leave things be? I also know that Macro Scheduler is a very capable product and we want people to realise that. I don’t want the name putting anyone off.

The other day I was talking to someone at one of the largest utility companies in the USA. She told me that her IT department uses HP’s WinRunner product for automation but they were unable to get it to automate one particular piece of software. WinRunner costs thousands of dollars. She found Macro Scheduler and was very quickly able to use it to automate this tricky application. Other customers report similar stories. Well I guess the name didn’t matter in this case. She found our product and it proved itself.

So does the name matter?

October 20, 2006

Get Back Vista Run Command!

Filed under: Vista — Marcus Tettmar @ 3:47 pm

The biggest annoyance for me with Vista is that, by default, the “Run..” option is no longer on the Start menu. If you’re like me it’s probably one of the most used items on your computer! Now, you can use the search box in Vista in the same kind of way. But there’s no drop down bringing up the last typed entries. Apparently, Microsoft removed the Run box from the Start menu because they seem to think most people won’t need it any longer. Hmph. I’m obviously not most people!

Luckily you can get good old “Run command” back by right clicking on the Start menu and selecting “Properties”, then “Start Menu”, then “Customize” and checking the “Run command” option.

But the simplest solution is one I missed completely! Just press the Windows key and R together. Win+R is the shortcut for the Run command. Simple!

February 2, 2006

WebRecorder 1.65 Update

Filed under: Announcements — Marcus Tettmar @ 12:58 pm

I spoke too soon re WebRecorder and IE7. Microsoft have improved the way SELECT fields (drop down boxes) work in IE7. For previous versions of IE, WebRecorder has to use a convoluted process to detect clicks on SELECT fields and find the corresponding drop down object (Internet Explorer_TridentCmboBx). In IE7 things are much simpler and they are exposed just like other HTML elements. So we’ve updated WebRecorder today to handle this. WebRecorder 1.65 now works with IE6 and IE7.

Registered users can download the update from the registered downloads area. Evaluation downloads are here.

January 16, 2006

Keyboard Shortcuts

Filed under: Automation,Scripting — Tags: — Marcus Tettmar @ 9:19 am

As mentioned in my last post, the easiest, most reliable way to automate an application is via keyboard shortcuts. But I’ve found that many people are so used to using the mouse that they don’t even realise you can use the keyboard to move around Windows applications.

Some things I take for granted are completely new to others. For example, moving from one field to the next is accomplished with the Tab key. After entering some information into an edit box just hit Tab to move to the next edit box. This is surely faster than moving your hand away from the keyboard, moving the mouse, clicking in the next edit box, moving back to the keyboard … and so on. Tab is all you need. Something a lot of people don’t realise is that this even works on web pages. Tab will move from form field to form field, but also from link to link. Try it now while you are reading this post. Press Tab a few times. You’ll notice a faint hashed box around the focused link. Press Tab again and the box moves to the next link. And so on. When you’re on a clickable object, or link, the Enter key will select or “click” it. Tab to a link and then press Enter and you will go to that page. In a Windows application you can tab to any standard object. You can tab through edit boxes as well as check boxes, menu items and buttons, and pretty much anything else. If you tab to a button pressing Enter will “click” it.

Checkboxes can be toggled from checked/unchecked and back again by pressing the space bar. Tab to a checkbox and hit the space bar. Its checked status will change. To select an item in a list box you can use the up and down arrows. Same goes for treeviews and combo boxes. But what you might not realise is that many list boxes and combo boxes have a kind of “drill down” feature. Type the first few characters of an entry and the selected item will change to the first item that starts with those characters. Type more characters in one go to narrow down the selection. This can be really useful when automating applications where you want to select an item in a list box or drop down – you can just send the text of the item you want to select. E.g. the following script automates the Regional Settings control panel applet to automatically change the default input language to Chinese (Hong Kong):

//Set to Chinese (Hong Kong …)
ExecuteFile>intl.cpl
WaitWindowOpen>Regional and Language Options
SetFocus>Regional and Language Options
Let>SK_DELAY=10
Send>Chinese (Hong Kong
Press Enter

This works by sending the first few characters unique to the entry we want to select. Unfortunately not all list boxes work like this. That’s why Macro Scheduler has advanced commands like GetListItem to determine the index of an item given it’s text caption.

Most of us know that we can select menu items using the Alt key. When you press the Alt key you should see certain characters in the menu items and on other objects become underscored. These are the shortcut keys. So to select the file menu in most applications you would press ALT-F. If an application has been designed properly other fields and buttons will have underlined characters also. Even labels associated with objects should have shortcut keys so that when you press ALT and that key you move focus immediately to that object. All this makes automation so much easier.

Other key combinations that are useful include CTRL-TAB to move from page to page or tab to tab in a tabbed window, such as Firefox. Try CTRL-TAB in firefox with several tabs open. You’ll move from one to the next.

Did you know you can select the next word in an editor by pressing CTRL-SHIFT-RIGHT? SHIFT-RIGHT on its own just moves the cursor to the end of the word and then to the next word and so on. Reverse it with SHIFT-LEFT. SHIFT-END will highlight to the end of the line. SHIFT-CTRL-END to go to the end of the document.

This is just the beginning. There are all sorts of keyboard shortcuts that make working in Windows so much faster and make automation so much easier and more reliable. I don’t know them all. But it’s worth getting to know them if you want to get the best out of Windows Automation.

Here are links to some pages that list useful keyboard shortcuts:

List of the keyboard shortcuts that are available in Windows XP
http://support.microsoft.com/default.aspx?scid=kb;en-us;301583

Shortcut keys in Windows 95,98,Me:
http://support.microsoft.com/default.aspx?scid=kb;en-us;q126449

Getting the most out of your Windows Keyboard
http://www.internet4classrooms.com/winkeyboard.htm

February 27, 2020

Using Macro Scheduler 15’s Chrome Automation Functions

Filed under: Automation,Scripting,Web/Tech — Marcus Tettmar @ 6:48 pm

Macro Scheduler 15 now has native Chrome and Edge functions. You may be wondering how they work. There are a couple of sample scripts included with v15 but if you’re not sure how to get things set up or how to identify elements in the page this article is for you.

I wanted an example that wasn’t too involved but juicy enough to offer a few hurdles and demonstrate some features like xpath. I’ve set upon using Yahoo Finance to pull out the value of a stock symbol. Bear in mind that websites have a habit of changing so I can’t guarantee that the code in this article will work 6 months from now. But that shouldn’t matter much – it’s the principles of how to do this that matters most.

Before we begin make sure you are running Macro Scheduler 15.0.06 or above.

ChromeDriver

Before we can use the new Chrome functions we need to download the win32 version of ChromeDriver from: https://chromedriver.chromium.org

The zip file contains a single file: chromedriver.exe. Save this somewhere.

We need to tell the script where chromedriver.exe is. In my examples below I’ve got it in the root of drive C. So the first line of my script needs to be:

Let>CHROMEDRIVER_EXE=c:\chromedriver.exe

Start a Chrome Session

Now, we can start a Chrome session. To do this we use the ChromeStart function and give it a variable name that we want the session ID stored in. I’m using session_id. We’ll need this for the rest of the commands:

ChromeStart>session_id

Run your script and if your script is correctly pointing at ChromeDriver.exe you should see an empty Chrome window appear.

Navigating

To navigate to Yahoo add the ChromeNavigate command, passing the session_id to it:

ChromeNavigate>session_id,url,https://finance.yahoo.com/

Close the Chrome browser window (you don’t have to but running your script is going to start another) and run your script again.  This time you should see it navigate to Yahoo and show something like this:

Using Developer Tools

So the first thing we need to do is get past that “I agree” button. This is where Chrome’s Developer Tools comes in to help us find the element and the attributes we can use to identify it.

Right click on the “I agree” button and select “Inspect” at the bottom of the popup menu.  Chrome’s Developer Tools should appear. Usually at the bottom, but if you’ve used it before you may have changed the layout. It should appear in ‘Elements’ view and the highlighted element should be the “I agree” button:

Sometimes, I’ve found that the first time I select “Inspect”, if Developer Tools wasn’t already open, the element I want isn’t the highlighted one. Usually right clicking on the element and selecting Inspect a second time does the trick.

Another way to identify the element once Developer Tools is already open is to click the element selector button which you see at top left in the screenshot above. Then move the mouse to the “I agree” button and click.

Once you’ve got the right element selected look for an attribute which we could use to identify it:

<button type="submit" class="btn primary" name="agree" value="agree">I agree</button>

Ideally we want something unique.That isn’t always possible and I’ll talk about what we can do in those cases later. Here we’re in luck. The element has a name – “agree”. We can use this to get a reference to the element so that we can then ‘click’ it:

ChromeFindElements>session_id,name,agree,agree_elements

Notice how we’re passing the session ID again (we want to make sure we’re referring to the Chrome window we started). The second parameter is the “Strategy” we want to use to identify the element. ‘Name’ is an available strategy – find the element by name. The third parameter is the strategy value. For ‘Name’ it’s the name itself which in this case is “agree”. Finally we give the command a variable name we’d like to store the located element IDs in.

Valid ‘strategies’ you can use are:

id, name, class name, css selector, link text, partial link text, tag name, xpath

Clicking on the Element

ChromeFindElements returns an array of matching elements. In this case the array should have only one item because there’s only one matching element. So the item we want is the first one: agree_elements_1.

Let’s use that to click on the button using the ChromeElementAction command:

ChromeElementAction>session_id,agree_elements_1,click

The script so far:

Let>CHROMEDRIVER_EXE=c:\chromedriver.exe
ChromeStart>session_id
ChromeNavigate>session_id,url,https://finance.yahoo.com/
ChromeFindElements>session_id,name,agree,agree_elements
ChromeElementAction>session_id,agree_elements_1,click

Close your browser window and re-run the script. Hopefully you’ll sail right through that I agree box.

ChromeDriver should wait for events to complete and pages to load before firing new events, but if you have any issues you may need to slow things down a touch. E.g. stick a Wait>1 before the click.

Sending the Stock Symbol

We now need to find that input box, enter something and submit it. Using the same ‘Identify’ technique as described above you should find that the input element has its “id” attribute set to “yfin-usr-qry”:

So we’ll use that:

ChromeFindElements>session_id,id,yfin-usr-qry,input_elements

I’ve used input_elements as my array name for the found elements. We now want to enter some text. Let’s search for Microsoft which is stock symbol “MSFT”. To do this we’ll use the ChromeSetElementValue command. There’s only one matching element again so as above we use the first match input_elements_1:

ChromeSetElementValue>session_id,input_elements_1,MSFT
Wait>1

Notice this time I have put a wait afterwards. The next step is to ‘submit’ the field. I found that submitting it without the wait didn’t allow enough time for the entry to ‘take’. There could be some background processing going on which needs time to finish. Remember, as with most automation, we’re automating something that was designed for a user, and Robots run faster than users, so sometimes need slowing down!

We will now use the ChromeElementAction command again, this time with the submit action:

ChromeElementAction>session_id,input_elements_1,submit

Instead of doing this we could have found the search button and issued a ‘click’ on that. But that would require another ChromeFindElements which in this case is unnecessary. We can ‘submit’ the input directly.

Extracting The Stock Value

Rerun the script and you should end up looking at the Microsoft stock info which we want to extract.

Tip: rerunning the script from the top every time isn’t ideal. We’ve got the Chrome window open so the session is still active. So what you could do if you just want to run and test a few commands is grab the session ID from the watch list and assign it with a Let statement placed just before the commands you want to test. E.g:

Let>session_id=b6976cfec0326dcce35ad3674c3ed90e
ChromeFindElements>session_id,id,yfin-usr-qry,input_elements
ChromeSetElementValue>session_id,input_elements_1,MSFT

This is where things get a little more interesting. Use the inspect element tool to locate the element as above. You’ll see it’s a span element. You might also notice the class keeps changing. This site is very dynamic, updating as the stock value changes. In this instance we aren’t lucky enough to have an id, or a name. But notice those custom ‘data-reactid’ attributes.  You’ll see that they all have different values, and the one we want is “34”.  Let’s see if we can use that.

Now, ‘data-reactid’ is a custom attribute. It’s not standard html, and there’s no ‘strategy’ called that. So we’re going to use something called ‘xpath’. xpath is incredibly powerful and can help us find pretty much anything. There’s a great tutorial on xpath here.

We need to find a ‘span’ element with attribute data-reactid which is set to “34”. In xpath we can do this with:

//span[@data-reactid='34']

The // means find nodes regardless of where they are – we don’t need to provide a path. The @ symbol is used to specify an attribute. And we’re giving it a value. We’re saying find a span element with attribute data-reactid set to value “34” and we don’t care where it is.

So we can use this in the ChromeFindElements command as follows:

ChromeFindElements>session_id,xpath,//span[@data-reactid='34'],info_elements

Now, before we continue we should confirm whether or not this is the ONLY span tag with this attribute and value. We could do that either by searching the source using Chrome’s element inspector, or, I think easier, just debug the code to see what we get back. Stick a breakpoint just after this line, run the script and then look at the watch list. You’ll see there are two:

Now, we’re going to need to extract them to see which is the right one. We’re going to use the ChromeGetElementData command:

ChromeGetElementData>session_id,info_elements_1,text,stockValue

If you step through this command and look at the value of stockValue in the watch list, you’ll notice that info_elements_1 is not the one we want. We want the second one:

ChromeGetElementData>session_id,info_elements_2,text,stockValue
MessageModal>Value is %stockValue%

So there we have it. We’ve started Chrome, navigated to Yahoo Finance, clicked ‘I agree’, searched for MSFT and extracted the stock value.  We might want to close the Chrome window at the end:

ChromeQuit>session_id

Here’s the full script:

Let>CHROMEDRIVER_EXE=c:\chromedriver.exe

ChromeStart>session_id
ChromeNavigate>session_id,url,https://finance.yahoo.com/

ChromeFindElements>session_id,name,agree,agree_elements
ChromeElementAction>session_id,agree_elements_1,click

ChromeFindElements>session_id,id,yfin-usr-qry,input_elements
ChromeSetElementValue>session_id,input_elements_1,MSFT
Wait>1

ChromeElementAction>session_id,input_elements_1,submit
Wait>1

ChromeFindElements>session_id,xpath,//span[@data-reactid='34'],info_elements
ChromeGetElementData>session_id,info_elements_2,text,stockValue
MessageModal>stockValue

ChromeQuit>session_id

Using Edge instead of Chrome?

The Edge commands work in exactly the same way as Chrome. And finding elements in Edge is done in exactly the same way. So you should be able to adapt the above code to work with Edge very easily. The main difference is that Edge is a bit more picky when it comes to installing the correct version of Edge Driver.  And if you have an older ‘legacy’ version of Edge you will need to install Microsoft Web Driver instead of MS Edge Driver.  The manual explains how.

Conclusion

The Chrome and Edge functions are incredibly powerful and finding elements using Chrome’s, or Edge’s, Developers Tools is quick and easy. There’s also a lot more that you can do, such as grab the entire source of the page. I hope this has been useful. Let me know in the comments below how you are using these functions.

You’ll find more info in the manual. See Chrome Functions and Edge Functions.

If you have any questions find me on the forums or drop us a line.

Older Posts »