joe

Just got back from out-of-state. Read your post. Thanks for the reply Cory. Very detailed. In my line of work, the gathering and distribution of data from various ERP systems was always designed to be live and corporate wide ... sort of a birds-eye-view in real time. For example, a person moves inventory from building to building, truck to truck, and dock to dock it was viewed in a real time. The powers-that-be always knew what, where, when, why, and who as inventory transferred from point-to-point. From the supply chain it was all live MRP stuff. Everything was web, ajax, php

Understood Cory. I looked at iMacros a while back and saw what you saw. You probably looked deeper than I, but we have the same opinion. BTW, when you say "console program", are you referring to something like cmd.exe running behind the scenes for MXPro interactivity? Interaction with web-based apps is centered around events. We know that an event is anything a user does with their mouse, keyboard, touchscreen, and voice. But events are also driven by whatever the app needs to do for itself. Most events are asynchronous anymore which are less difficult to handle than they used to be. That being said, event handling is what takes the most design time. It always took 80% of the time in every web-based app I created. A lot of web-based apps are designed to be nearly 100% dynamic. Elements are usually created or made accessible only at the time some event happens i.e. a user clicks on a button. So the document elements and their attributes can always change in an instant. Still, a user can only do one thing at a time i.e. click here, click there, hover over this, hit a key, and so forth.

acantor - Here is a generic explanation for the regex (regular expression) pattern. What regex engines do is to find portions of strings based on a pattern. It processes the string passed to it one character at a time moving from left to right. In this case it returns only the first thing found and is case-insensitive. \b[ABCEGHJKLMNPRSTVXY][0-9][A-Z] [0-9][A-Z][0-9]\b Assert position at a word boundary (preceded or followed—but not both—by an ASCII letter, digit, or underscore) «\b» Match a single character from the list "ABCEGHJKLMNPRSTVXY" «[ABCEGHJKLMNPRSTVXY]» Match a single character in the range between "0" and "9" «[0-9]» Match a single character in the range between "A" and "Z" «[A-Z]» Match the space character " " literally « » Match a single character in the range between "0" and "9" «[0-9]» Match a single character in the range between "A" and "Z" «[A-Z]» Match a single character in the range between "0" and "9" «[0-9]» Assert position at a word boundary (preceded or followed—but not both—by an ASCII letter, digit, or underscore) «\b» rberq did something similar to this by logically changing the characters in the string to be known characters which gave him the ability to find a pattern. Most, if not all, programming and scripting languages provide a regex engine. Macro Express does not, even though it could, because Delphi itself has one (TRegEx). But in my opinion, the implementation of it would be beyond the general meaning and purpose of Macro Express. That being said, Macro Express provides both the Program Launch and External Script commands which allow us to use features of other programming languages and return results back to Macro Express.

Well rberq ... your idea of converting many possible characters to a single-known character is a good concept, indeed.

I'm just guessing but more than likely you utilized the Split String command to create an array to work through. As fun as that sounds, I used the External Script command instead. Not what you are looking for but it is indeed a Macro Express command. <VARIABLE SET STRING Option="\x00" Destination="%location%" Value="1234 Chaplin Dr. Twr. 1- 6th floor , Mississauga, ON L4Q 5Z3 Canada" NoEmbeddedVars="FALSE"/> <VARIABLE SET STRING Option="\x00" Destination="%pattern%" Value="\\b[ABCEGHJKLMNPRSTVXY][0-9][A-Z] [0-9][A-Z][0-9]\\b" NoEmbeddedVars="FALSE"/> <EXTERNAL SCRIPT Language="VBScript" Dest="%console%" Script="Dim regEx, matches\r\nSet regEx = New RegExp\r\nregEx.Pattern = \"%pattern%\"\r\nregEx.Global = False\r\nSet matches = regEx.Execute( \"%location%\" )\r\nFor Each match In matches\r\n WScript.StdOut.Write match.Value\r\nNext" Encoding="0"/> <MESSAGEBOX Caption="Result" Message="%console%" Icon="0"/> Also, the regular expression pattern I placed in the code is good, but not perfect ... c'est la vie

Hi Terry! Yes, I have been away for a long time and I thank you for dipping into the book. As a matter of fact, I needed to do the same thing several times recently! So, we know that MXPro6 has the "Wait for the web page" feature in the Website command (and other commands?). But you think it needs to be used for browsers other than Internet Explorer, yes? If so, then I agree. I don't think Microsoft even supports IE anymore, but I could be wrong. Do you think that web page automation would be a good feature for MXPro6 or, as Cory mentioned, a new Insight application?

Cory - Thanks! Yes, the underlying requirements for web page interaction is different than it is for local apps, so maybe a new app from Insight outside of MXPro6 would be good for this. Indeed, they do have other apps for other things. That being said, it would still be nice to expand the External Script command somewhat to handle possibilities. You live in the .NET world which is a much broader and flexible than my web-based application world. And like you, I have seen many apps whose claim to fame is web scraping, which is a term that I abhor. But it is what it is, and it seems to be more acceptable than before. Personally, the term automation is better. Then again, web scraping is automation <sigh>. Do you think the market is too flooded with applications designed for web automation?

New features of any application can be good, bad , or ugly. So being inquisitive, I was wondering what kind of a feature would it be for MXPro6 to interact with websites in the same manner and power as it does with local applications? Personally I think it would be great. What is your opinion?

Paul - I was referring to the macro System Event macro activation feature. When it gets down to the Windows messaging system, I am totally ignorant and blind. My eyes cross whenever I attempt to think about it. That being said, I think it would be nice to know how to set the System Event macro activation fields along with how to write a simple AutoIt, or preferably, VBScript program to handle firing a macro via PostMessage. I would imagine VBScript would need to use some WMI calls. Another eye-crossing thing for me to even begin thinking about.

The best way to read and write to web pages is accessing IE's DOM, which is easily done using MXPro's External Script command and VBScript. In order to accomplish what you want programmatically (reading webpage fields, creating CSV files, and writing to webpage fields) HTML is a good thing to know. Here is an article on how to access a webpage in general from MXPro and get data off from it. This article covers only anchor elements but any type of element on a webpage is accessed in the same manner.

duchi- Nice post, indeed. Very understandable. Read this article covering the interface between MXPro's External Script and Internet Explorer. It will be a starting point for you to see how the DOM on IE web pages are accessed and read via MXPro without having to download the source page, or use the mouse or the tab. It does not cover writing data into fields, at least not that I remember. Placing data into fields without using the mouse or tab key is very, very easy to do in the IE DOM with MXPro. Here also is a link to a 10 minute preliminary video covering a product I am working on which is, more or less, an interface between MXPro, HTML, VBScript and Javascript.

Paul - That looks very nice ... but what are the properties to be set in the "TestMacro" activation tab?

There is ALWAYS good reasons for YOU, Mr Cory, to reinvent the wheel.

droo- I have never encountered this problem, so I do not have answer for you. My systems are 64-bit Win7. And I have not yet installed 4.6.0.1 on any of my VMware systems.

Nuts. I did not know that someone beat me to it.