rberq

Very strange. It certainly seems that your solution is a good one. If the command MOVE MOUSE TO CURSOR POSITION is working, then GET MOUSE COORDINATES should certainly work. You should not have to click the mouse before trying to get its coordinates. I wonder if it would help to get rid of that command? Maybe the application is doing something funny when the mouse is clicked. But if you are clicking to assure Windows returns focus to your application, then yes you may need the click. After MOVE MOUSE TO CURSOR POSITION, try inserting a quarter-second or half-second delay, to give the application time to finish positioning the mouse before the macro continues. Are you getting mouse coordinates relative to the screen, or relative to the window? Whichever it is that is failing, try switching it to the other. Also, near the end of your logic: subtract 2nd set of coordinates from 1st, save in New Variable mouse left button down mouse move position by the amount in New Variable mouse left button up Instead of stepping the mouse one character at a time to the end of the text, simply move it to the coordinates you originally saved after your PRESS RIGHT-ARROW KEY. Ditto for stepping the mouse backwards to get to the beginning of your text -- if you can find a trick like PRESS RIGHT-ARROW KEY to automatically position the cursor there (HOME key maybe???) it will be much faster than single-stepping the cursor.

Another way, but probably too slow -- If you know the color of highlighted text, scan the screen to find the upper left and lower right positions of the color, and save the pixel positions. Then to reproduce the highlighting later, move mouse to upper left saved position, mouse button down, move mouse to lower right saved position, mouse button up To make this work fast, you would have to be fairly creative in the logic of the original scan, because to examine every pixel of the screen would just take too long. Maybe some sort of binary search to put you in the highlighted area, then sequential stepping backward and forward to find the limits. If I judge Brain Virus correctly, he will have the logic written for you by tomorrow morning.

This should work with a MS Word document and some others: When your macro starts, data is already highlighted, so copy to clipboard and save in a text variable, T1. To reproduce the highlighting later, the macro will: Mouse click within the document screen to restore focus to the document. Ctrl-Home to go to beginning of document, or mouse click at upper left corner of the screen to stay on the same page. Ctrl-f or Alt-Edit-Find to open search box. Type T1 into the search box, type ENTER to do the search. At completion of the search, your text should again be highlighted.

IF VARIABLE CONTAINS command can be used to check for strings within the variable, as well as for single characters within the variable. Or, just throw out the whole password and start fresh when you find an illegal character or string within the password. It may take a few microseconds longer to generate passwords, but it's probably simpler to write the macro.

You can build a very simple menu structure using Notepad. First make file menu.bat, which is a sequence of statements like cls echo *** MENU *** echo 1 Notepad echo 2 MS Word echo 3 Excel etc. All this is, is a series of reminders to the user. So when he opens a DOS command window and types "menu" he sees the list. (Or, you give him a desktop icon to run menu.bat.) Then, if the user wants Excel, he types "3". You make file 3.bat which consists simply of start c:\Program Files\ .... \excel.exe exit Same for the other options. 1.bat runs Notepad, 2.bat runs Word, etc. Now instead of you manually building all these .bat files, you could write an interactive macro that asks the user what he wants, then builds the .bat files using Variable Modify String [Append to Text File]. Use Variable Set String [set String from File Name (Prompt)] to allow the user to drill down to the file he wants to run for each menu option.

It does sound strange. Maybe they want each person to be able to construct his own menu structure on his PC, to enable him to quickly get to various applications? If so, then the macro you write would need to associate some logic with each menu choice, for example, Launch Notepad. I don't know how to do it, but take a look at Run Macro in Variable and Load Macro Text File -- maybe there's something there to help. I'm thinking you might write a generalized menu macro that will then be loaded, modified, and saved by the interactive macro accessible to the users. Just thinking out loud here ....

You can generate each random letter into a variable, for example into T1 with the Variable Set String option. Then have a series of IF commands to check whether T1 equals any of the forbidden characters. If it does, generate another character to replace it. REPEAT START VARIABLE SET STRING T1 WITH RANDOM CHARACTER IF T1 NOT EQUAL "/" AND IF T1 NOT EQUAL "&" AND etc. etc. etc. REPEAT EXIT END IF REPEAT

I don't think recorded macros would be any different from macros created with the script editor.

I don't believe ME can pass keystrokes to Windows when the user is logged off. However, if the system is "locked" (as opposed to logged off) then you can at least open and run programs. For example, I have batch command files that are started by macros while the server is locked. I don't know about passing keystrokes to an application while locked.

A timing problem is certainly possible. There are a number of threads on the forum about clipboard-copy issues and solutions to those issues. An easy way to diagnose this would be, on that one user's PC, to set the clipboard delay to a very high value temporarily, say 3000 ms (3 seconds). If that makes her PC work right (albeit slowly) then you have found the problem. Does the problem PC have the same 3270 emulator brand and version as the PCs that are working?

The inner Repeat Start - Repeat End is OK. The outer (first) Repeat Start is after the main IF, but its Repeat End is after the END IF. So, logically your code may reach the Repeat End without having executed the Repeat Start. I think that is the problem.

Try going to Options | Preferences | Delays, and bump the clipboard delay up to some high value like 3000 milliseconds (3 seconds). If your macro works consistently with that value, then you have pretty much proved it is the clipboard copy that is the problem. I understand your feeling that "Macro Express behaves erratically and unpredictably". But ME is only passing keystrokes to Windows, for the most part, and I have found it is usually Windows behaving erratically and unpredictably. The "unpredictable" part is usually unpredictable timing. Think about your manual interaction with Windows applications. Sometimes the response is instantaneous, but when the Bill Gates Random Performance Function kicks in, the same response can take several seconds rather than the blink of an eye.

....

Try including the > (greater than) sign in the program parameters: -R > C:\logfile.log rather than -R C:\logfile.log I don't think it is the space that is causing the problem -- I have a similar program call where I pass two parameters separated by a space, like this: MGM %T82%

Get Pixel: Screen Coords: 324,197 into %N1% Repeat Until %N1% <> %N1% Get Pixel: Screen Coords: 324,197 into %N1% If Variable %N1% <> variable %N2% Break End If Repeat End As Paul pointed out, variable N2 is not being set anywhere. I think you want your second Get Pixel command to get into N2, not N1.

I use Kevin's method 2 with Visual Studio / Visual Basic. I inserted the commands in the "click" logic for the button which is supposed to trigger the macro.

You're right, I wouldn't normally use it for 10-20 characters of typing. However, I have 10-20 characters in 10-15 fields across two forms, so the time adds up, especially since there is other overhead involved in looking up the data before typing it into forms, while the customer stands there and fidgits. You may be onto something, though, about it being an application problem and not an ME problem. It's an IE-based application, and that puts another layer of software between the keyboard and Windows. I can't prove it, but I feel like IE responds differently (slower) to keystrokes than most Windows apps. Each field to be typed is preceded by a tab, to get to the field, before data is pasted into the field. Maybe the CTRL portion of CTRL-v is happening before the Tab operation completes. I can try Wait Text Playback or maybe just delay 1/10 second after the Tab and before the pasting of the variable data. Thanks for the idea.

Yes, and I have a similar macro that is largely a copy of Paul's. I experimented a little today, with saving the variable to be typed into the clipboard, then explicitly typing CONTROLDOWN - v - CONTROLUP to paste it. That worked better, but was still unreliable. I guess I'll just revert to TEXT TYPE normal typing instead of trying to use the clipboard. It's definitely slower, but way more predictable.

I have tried several times to use TEXT TYPE with the checkbox "Use Clipboard to Paste Text". When it works it is wonderfully fast. However, often I wind up with just the letter "v", either upper or lower case, in the target location. It's as if the macro uses the CTRL_v sequence to paste the data, but the CTRL part gets lost and it just types the letter "v". I have preferences set to zero delay after clipboard commands. Ideas, anyone? Except don't ask me to set a clipboard delay -- that is zero for good reason and has to stay zero.

I don't know the answer -- but the default text type delay is not 300 ms (milliseconds), it is 300 microseconds. In theory that's 3,333 characters per second. I'm curious how you are distinguishing between 3,333 and "something even faster"? What are the symptoms of the problem you are having?

Post a description of your problem, and if possible include a copy of your script. Chances are you will get help here for free.

I have been programming for more years than I care to admit. With pre-Microsoft systems, you could generally go to a manual, read up on how something worked, then write your code based on the documentation. Bill Gates turned that on its head. Now the documentation is either non-existent or moot. You have to do trial-and-error to see how the system works, then write your code, then wait for it to break because of something you didn't see first time around, modify your code, then start all over with the next release of Windows or IE. Idiosyncrasies handled easily by the human brain are difficult to code for, but that's exactly what we wind up doing with ME. Philosopher Bob

I have macros that type data into several Internet Explorer forms (IE6). Each macro turns on caps lock before it exits, because the users want it on for their own typing. Each macro, before it begins typing, turns off caps lock and does a shift-key-down followed by shift-key-up. Keyboard delay is 20ms. ME preferences relative to caps lock are disabled (not selected). "Wait for web page" is done prior to the caps lock off. The problem: On one of the forms, turning off caps lock intermittently fails. Because the text to be typed is already upper case, having caps lock still on causes the text to be typed in lower case. Suggestions, anyone?

Now I'm confused. With text variables I have always used commands like Variable Set String %T1% "" and If Variable %T1% = "" Text Box Display: T1 is null End If Are you saying this "should" not work? Granted, I would not try it with an integer or a decimal variable.