joe

Ok, I can't help much with the remote direct access using Citrix. But I'm sure there are others who can.

The work being done, the data being read, the comparisons being made, is the work performed through logging into one of their systems via something like LogMeIn, or is it performed by logging in with a user ID and password to a website?

I am absolutely positive it would impact the macro speed, but by how much? It takes about .03 ms to check if a file exists, which means that for 100,000 checks it would add 3+ seconds onto the macro's runtime. That can't be bad. The code below took 30.22 seconds to check for the existence of a file 1,000,000 (1 million) times. External Script: VBScript // Timer start Repeat Start (Repeat 1000000 times) If File Exists: "c:\temp\filename.txt" MessageBox: %macroName% End If End Repeat External Script: VBScript // Timer stop

In my book, unattended operations was always the most fun. Always had structural solutions. And was usually very reliable. But it all depends on how the gears are designed to work. One thought is that you know what time it will be 10,000 seconds into the future. If the time is exactly 10pm (2200) on Friday the 4th when you fire up the macro then the target time would be Saturday the 5th at 00:46:40 am. One solution would then be to have the macro check the current date and time in each loop to see if it's past its bedtime, yet.

I understand the concern about going past midnight. 86,400 all of a sudden is back to zero. However, are you simply looking for a command line to save the seconds past midnight to a variable when the macro hits that line?

Within MXPro, the Button Down / Button Up commands are a code structure same as the If / End If and the Repeat / End Repeat structures. You will receive the same syntax error message when any part of any code structure is missing.

If Variable %xVal% Is Greater Than "100" Mouse Left Button Down Mouse Move: %xx%, %yy% Relative to Screen Mouse Left Button Up End If Add the Mouse Left Button Up line.

The marvelous reason to have and use MXPro is to give you automation access to any software package in the best ways provided by whomever makes the software. For example, opening applications like Word, Internet Explorer, Outlook, and others in order to directly use their properties, methods, and events is all easily done with MXPro. If DNS has a COM object that provides its properties, methods, and events to external applications then it could also be run and controlled by MXPro using VBScript, JScript, JavaScript, or AutoIt, and such. If not, then MXPro can still automate what you need by doing what Alan has mentioned. Since your 50+ users have their own preferred set of hot keys, does DNS store them in some sort of accessible profile on the user's workstation? If so then have MXPro read the profile and output whatever hot key that that user has set for themselves. My other suggestion is that if MXPro does not provide a solution for what you need, then see what may be available on the DNS KnowBrainer.com website forum. Not that it matters, but as a side note, DNS 12 is my version. However, it is the Preferred version and not the Professional. The Preferred version doesn't allow for command-type macros whereas the other does. I wanted something that enabled me to talk with my computers like Dr. Doliitle did with the animal kingdom. And that is the reason I switched to using Vocola. Vocola has its own script language that allows me to create the commands needed to control my computer as well as being able to have pleasant conversations with MXPro. Now, does Vocola understand what I am saying? Somewhat. At least as well as DNS and WSR did ... and do. But if three different packages of software, and another human being, have hard time understanding what I am saying then its gotta be me. Being fairly new to the world of voice recognition, it seems the requirement in dealing with its software is opposite that of dealing with things like MXPro. I train things like MXPro to do what automation needs to be done. But with voice recognition, I have to train myself to do what it wants. Even though my training is going well, I still had to type all this.

Well, a short, workable answer would be using VBScript in the MXPro External Script command to open an existing Word document containing the DNS macro and run it. Option Explicit Dim appWD : Set appWD = CreateObject( "Word.Application" ) With appWD .documents.open( "doc-file-containing-the-macro.docx" ) .run "Dragon_Mic_Wake()" .quit End With Set appWD = Nothing It may not be a final solution, and what I just posted is untested typing.

Are you trying to use MXPro to create a form for people to answer questions?

Add text manually to what? The Variable Set String - Prompt for Value command prompts the user for input, if that is what you mean.

From the Variables tab choose Add then choose Large Integers Variables from the dropdown list. According to their help file these are signed variables in the -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 range. Zowie!

One of the things needed for unattended operations is to set up an on/off switch in the macro so it knows itself when it should start and stop. An on/off switch can be something as simple as a file in a folder. If it exists, then the macro runs, otherwise it stops. Do this by creating the switch, which would be a separate macro to simply turn the switch on (create a file) or turn it off (delete the file). Set the macro that you want to run unattended to fire every few seconds (or whatever interval trips your trigger). First thing it needs to do is check for the existence of the file. If it isn't there, the switch is off, and it stops itself. If the file is there then it moves past the checkpoint, and runs. How do you stop it? Well, most of the macros created for my operations all run in some repeat loop and at the top of the loop they check the on/off switch. If it is off (file not there) then the macro stops itself. It is a very simple and basic way to have macros not only run and stop unattended, but to also change their course when they get past the checkpoint. How? Instead of having the macro just check the on/off switch, place instructions in the file for the course the macro should take next time it fires. An on/off switch like this gives us the ability to externally stop a macro as well as to have a nice conversation with it. Hope this helps.

Alien - Not that it helps you any, but these are the problems that were fixed with Mouse Locator in the previous build 4.5.0.1 (Dec 2013): 9. The Mouse Locator now displays the pixel color in separate values for Red, Green and Blue. 10. The Mouse Locator now displays the hexadecimal value of the pixel color in BGR format instead of RGB to match what is normally used by programs that accept hexadecimal values for colors. 11. Pressing Ctrl-C in the Mouse Locator now copies the Screen Position and color values to the clipboard. 12. Made a change to the Mouse Locator to eliminate a problem where the pixel color could flicker on and off even if the mouse is not being moved. 13. Made a change to the Mouse Locator so the values displayed for the Pixel Color are updated if the color under the mouse changes even if the mouse does not move. I have seen no problems on my Vista-home, XP-pro, or Win7-64-pro ... one of these days, I'll get a Win 8.1

FYI Alien ... I deleted your other post per your request.

gag- When using the External Script command for VBScript it returns errors to the variable set to recieve results from the script. When developing these programs I always use 'Option Explicit' as well as NOT using 'On Error Resume Next' so when the millions of times my development throws errors, I can see the error line number and the error in the receiving variable by placing MXPro Pause or MessageBox, after the External Script line to display the receiving variable, or by just popping open the debug variables window. Hope this helps.

Sorry, but what I meant was that the report filed was on the new 4.6.0.1 release.

Terry, If not done so already, in addition to posting it here (which is always great and informative), it would be good to file an official bug-report on the problem you are encountering at times. I myself do that. In fact, I even created a tiny, itty-bitty macro to get me to the bug report website, fill in my name and other data so then it just remains for me to type in what went wrong and append a snapshot. Heck, maybe I'll post that on my website. For example, there was an error that happened once when saving an edited External Script so I filed an official bug report. I have no way of knowing if it is just my system, however, ISS might know by getting enough bug reports covering the same thing.

Am not 100% certain of the changes that were made to MXPro, but whatever was changed since the release of 4.5.0.1 last December(?) seems to have resolved the molasses/treacle issue. Have not experienced it for a while.

Terry I have not had that problem on my desktop since upgrading. If it were me, I would reinstall the version that was running and see if anything happens. And when doing so, always put a check in that "install if older"(?) box in "advanced installation". Prior to installing any upgrade from anybody, anywhere is to create a Windows Restore point. This helps if something goes bad.

Is this an online HTML app ypu are trying to access or a local, non-HTML, client-side app (like an exe or something)?

No such thing as a shiny new 8.1 Windows in this office ... just the older 7. I have not ran into this particular problem. ISS just updated MXPro yesterday to release 4.6.0.1. Try that and see if there were any fixes. Joe

Hello Terry >>> Could you summarise the risks I'm taking please? The checkbox / radio button code structure in the article has two purposes: Speed - It relies solely on the speed of whichever application it is checking the screen for instead of delays. Reliability - Reliability by making sure the pixel is same color twice in a row. When a field is changed in an application, any field, the app repaints the window. Going from one tab to another in an app does the same thing. Popping up a new window does the same thing. Tons and tons of repainting the window. If you ever get a chance you can see how repainting a window actually looks. Make a screen video of something, do some clicking here and there. When replaying it, watch a single frame at a time. You can see the app window morphing itself, which means the pixel is not going to be the same color until it gets done being repainted. Morphing is the whole reason for the code structure talked about in the article. Now that I think about it, "Morphing" would have been a good word to use in the article. Thanks! The risk taken by your code might not even exist. Maybe there is not so much morphing of the screen. If using delays, whatever you wrote seems to be 100% reliable for you which is all that truly matters. >>> is the colouring of your nicely presented macros a feature of your text editor? No. What you are seeing is strictly HTML, however, another article was written about a macro I created to use regular expressions in MXPro to set those colors for me rather than having to do it manually all the time.

New article on Regular Expressions and MXPro.

New article on check boxes