rberq

I see what you mean about the coordinates being always the same. Apparently in Adobe there IS no "text cursor", so even though the MOVE MOUSE TO TEXT CURSOR command does not error out, the mouse coordinates returned seem to be always the upper left corner of the screen. Brandon's original idea of having the macro running before the user selects text MIGHT work, by capturing the mouse-button-down coordinates and then the mouse-button-up coordinates. But in practical everyday use it will probably fail due to timing constraints -- the user simply is not going to pause long enough at the begin and end points to allow the macro to capture the mouse coordinates. The second difficulty I see is, the user may highlight data that spans several screens by dragging the mouse down below the bottom of the screen while the text scrolls off the top. Then, capture of mouse coordinates relative to the screen becomes useless.

IF THE DATA SELECTED IS CONFINED TO A SINGLE SCREEN, WITH NO SCROLLING, then I still think what you want could be accomplished by scanning the screen for the selection color, finding where the color begins and ends, saving those coordinates, and using them to re-select (drag the mouse from beginning point to end point) after the highlighting tool has been invoked. The difficulty would be knowing what selection color to look for, adjusting for 16-bit vs. 24-bit vs. 32-bit color, and getting a scan routine that works fast enough.

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.

Once you've created your password, check for each illegal combination.

IF VARIABLE CONTAINS command can be used to check for strings within the variable, as well as for single characters within the variable.

Keep checking for illegal combinations (and replacing as per the above method) until there are none left.

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

From what you describe it sounds like you would be better off just turning on the two Caps Lock options in the Preferences./quote]

 

 

Thanks for the suggestion. However, there are several scheduled macros that run every one to three seconds to scan for the presence of specific Citrix-based application windows and specific Internet Explorer pages. (ME can't discriminate among the IE pages by window title, because they all have the same title: "Centricity Group Manager - Microsoft Internet Explorer".)

 

If I use the Caps Lock options in Preferences, and the user manually turns on Caps Lock to type additional information into a form, then the scheduled macros switch their caps lock off and back on every second. That's obviously not suitable; which is why I REALLY need to have Caps Lock Off work reliably.

 

I downloaded a small freeware utility that I can launch from ME to turn caps on and off. I'm testing that with the problem users now, but I fear that whatever causes the ME command to fail intermittently, may cause that to fail as well.

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?