rberq

Ah! An existential crisis! Is ME a keystroke capturer, or is it a programming language? I hereby cast my vote for adding GOTO to ME. That, and some fancier date-time-manipulation commands, would be high on my wish list.

You can call Bill Gates a lot of names, but "consistent" is not one of them.

If the macro moves the mouse relative to the screen, try moving it relative to the window instead.

Thanks for the feedback, John. I have never run out of variables, but I have wondered what I would do when it does occur. Using environment variables effectively provides storage without limits. P.S. Do you know if there is such a thing as a "global" environment variable within Windows? The one time I tried to use env vars was to pass information from a macro to a VB program. But the variables seemed to be local to the application that created them, so VB could not see what ME had stored and vice versa.

Well, yes and no. Lots of features might be useful now and then, but how much do they complicate the application compared to how often would they be used?

Under Window Control, first Get Control (set it up in your macro by using the Get Control utility). Then Set Focus. I seem to recall that, in Help, there's a short tutorial using the Windows Calculator application that shows you how to do this.

I use a programmable keyboard for things like that, where I have to do the same thing over and over. Essentially it just captures keystrokes and replays them, much like ME can do, except that the keyboard is quicker and simpler. It's really very good when combined with ME. For example, I have perhaps ten screens I switch among all day long in Windows, and ALT-Tab is a clumsy way to switch. So ten of the programmable keys are set to send weird key combinations, like ALT-Shift-F1, and ALT-Shift-F1 in turn fires a ME macro to activate one of the windows.

That sounds like it should work. Presumably you will have another macro to load a different macro file when you want to "unload" the first. Another idea is to write a macro to enable the other macros when you want them, and another macro to disable them. That way you can stay with a single macro file.

Good points, John. If ME can be installed on the remote computer, it will run more reliably and more ME functions will be available. We have an application hosted by a remote data center on Citrix servers, and would dearly love to run ME on the Citrix servers. Unfortunately the hosting company will charge us $5,000 per month to do this, because ME is not on their "standard" application list. So we are doing extra work to make ME work locally on each user PC. If Alexis is supporting remote PCs that don't run ME at all, then in a way she is in the same boat we are, and must make do with whatever ME can handle via local Radmin.

Kevin, do you have a feel for how significant IS that 1-second schedule checking? If one has a fairly modern PC, would ME soak up 10 percent of the CPU cycles? 1 percent? 1/1000th of 1 percent? Of course, patgenn wants his MACRO to run every second, and the macro might or might not use significant resources. But how about the ME scheduling logic itself?

Go to Options | Preferences | Scheduler and change the timer interval to 1 second. My guess is, your interval is currently 5 seconds so that is the lowest scheduling interval that will be recognized. I was trying to run a macro every 15 seconds, but my timer interval was 20, so it would only run once every 20 seconds.

Could you set aside a single Tx variable and always get from / save to that variable? You might be able to write two callable macros to do the save and retreive, rather than duplicated the coding in many different places. For that matter, instead of setting aside a Tx variable, maybe you could reserve three unique environment variable names solely for use by a callable "utility" macro. In the first env var you would place the name of the env var that you want to store or retrieve. In the second you would place a (S)ave or ®etrieve indicator. In the third you would place the data to be saved. Then call your utility macro. Or in the case of retrieving, you would call the utility macro with the ® code and expect to find the retrieved data in the third env var upon return from the call. The called utility macro would no doubt need to use some Tx variables in the course of its work, but it could store their initial contents in still other reserved env vars and restore their contents just before returning to the caller.

Since you are activating the macros with hotkeys, perhaps you could make the scope Global rather than window-specific? Even if you can't let them run permanently as Global, maybe that would get you through some additional testing. I don't know how Radmin handles display of the remote machine's windows. With Citrix applications I have found ME can recognize partial window titles, enough so that macros can be activated by the appearance of a window. But when I have limited the macro's scope to window-specific it has been less predictable. Some ME functions, like hiding a Citrix window, have been unreliable at best. As you would expect, trying to use controls within a window doesn't work because the controls aren't really "there" from a Windows perspective. But keyboard actions work fine. Good luck. Let us know how it works out.

Yikes! I want that job, where I can work 30 minutes and take a 20 minute break! Maybe you could do it like this: Schedule a macro to run every minute. Each time it runs, it will: Read in a text file that you have initially primed with the first break time of the day. Get the current time (it is under Text) and compare it to the time saved in the file. If break time is not yet reached, exit from the macro. Otherwise, break time has been reached, so: Pop up your reminder using Text Box Display, with the option to remain open until you click the OK button. The macro will sit waiting patiently while you take your break, oblivious to the fact that it is working while you are goofing off. When you click OK on the text box, the macro will continue running from that point. Write the current time (obtained as above) plus 30 minutes to the text file (overlay the old file). Exit from the macro. Excuse me now, I will be back in twenty minutes. Don't call me, I'll call you.

Well, that WAS a thorough test! Thanks for the feedback. I'm sure this will be useful to others.

I'm going to guess that it will work just fine. If you have two or three PCs to test with, try it by putting a big file on the server (big, so that reading it won't be practically instantaneous). The embed some delays in your macro if necessary, to slow it down a bit more, and start the macro on all the PCs at once. The only reason for the delays is so the macro won't finish on the first PC before you have a chance to start it on the others. Or to prolong the test without building in delays, you could have a repeat loop in the macro to process the file ten or a hundred or a thousand times, just to force more contention among the several PCs. Let us know how it comes out.

Paul, thanks for the clever tip on copying a null string to the clipboard. The Clipboard Empty command has never worked for me at all. And I like your loop technique better than using the ME delay-after-clipboard parameter, with its uncertain reliability. A question, though -- would it speed things up to do the loop perhaps every 10 milliseconds rather than every 100? I have an interactive application where the user is waiting impatiently while a macro copies data off a screen. 100 milliseconds doesn't seem like much, but when it is repeated 20 or 30 times for a screen it is definitely noticeable. For what it's worth, I have also found that it is much faster if you can capture controls, then "get control text" directly to a variable rather than via clipboard copy. That has the additional advantage of leaving the cursor wherever the user put it, not moving it all over the screen to accommodate the clipboard copy.

Well, Marc, I can see why you don't want screens popping up all day. Makes it kind of hard to do any other productive work. If your application is really important, it sounds like you need a second PC just to handle it. Or, here's an idea, and I warn you I have not thought it through so it may be loony: How about one of those dual monitor setups? Maybe position a DOS session on the second monitor just to start a never-ending macro that does your screen dumps and calls (hidden) the ftp operations, then delays 5 minutes, does it again, and so on. You could do your regular work on the other monitor. You could even darken up the second monitor so it wouldn't be flashing at you all day.

Another way to delete, which doesn't seem to use the Recycle Bin, is to use the DOS command: launch program c:\windows\system32\cmd.exe and pass it parameter /C delete c:\FolderABC\FileXYZ

First, it is not clear to me why you want one macro rather than three. For simplicity and flexibility, each of three could run on its own schedule independent of the other two. The alternative would be to run a single macro on a five-minute schedule, and put logic in the program either to check the time, or to keep track of iterations -- do your 5 minute function every time, your 10 minute function only when iteration count is evenly divisible by 2, your 15 minute function when the count is evenly divisible by 3. The counter is simpler than checking time, because MacroExpress usually won't schedule macros precisely at the times or intervals you desire. Just be sure to Save your counter variable before exiting the macro, and Restore it at the beginning of the macro. As to keeping your PC occupied, it depends what the macros are doing. I have one that runs every 15 seconds but it simply exits unless a particular screen is running, so most of the time you would never know it is there. I have others that run and write files to disk, but don't have any windows to display at all, so again you would never know they were there except perhaps for a slight performance blip. If you want a program called that normally uses the screen, but you want it not to display its window, there is a Program Launch Run Hidden command that you can try, though postings by other forum members say it works with some programs but that others refuse to stay hidden. Good luck. Post again if I have misinterpreted your questions.

Under Text, there is a Date command that allows you to put today's day name into a text variable. The same Date command allows you to set DD (day of the month) back x number of days from today's date. Unfortunately when setting DD into the past, the command does not accept a variable so you will have to use a CASE or a series of IFs to do the setback. So first, Save Day Of Week 2 (format MON, TUE, etc.) into T1 Then, If T1 = "MON" Save DD into T2 (with 1 day setback into the past) End If If T1 = "TUE" Save DD into T2 (with 2 day setback into the past) End If If T1 = "WED" Save DD into T2 (with 3 day setback into the past) End If etc. Copy and paste below. <Day of Week 2{NP000}{P000}01><IFVAR2:1:01:1:MON><DD{NP001}{P000}02><ENDIF><IFVAR2:1:01:1:TUE><DD{NP002}{P000}02><ENDIF><IFVAR2:1:01:1:WED><DD{NP003}{P000}02><ENDIF><TBOX4:T:1:CenterCenter000278000200:000:Day%T2%>

I'm not sure what you mean by "multi-thread". According to the online Knowledgebase, only one macro can run at a time. However, you can for example get data from one window, then switch to (activate) another window and enter the data, then switch back to the first window, or to still another window, etc.. Or, you could have a macro run in a continuous loop like REPEAT START IF WINDOW-A IS RUNNING ACTIVATE WINDOW-A DO SOME STUFF END IF IF WINDOW-B IS RUNNING ACTIVATE WINDOW-B DO SOME STUFF END IF IF WINDOW-C IS RUNNING ACTIVATE WINDOW-C DO SOME STUFF END IF DELAY BRIEFLY REPEAT END I'm not sure why one would want to do that, though. It's not really multi-threaded, just pseudo-multi. And having a long-running macro like that would block any other macros from running. Usually it would make more sense just to activate a macro based on window name, do whatever stuff you need for that window, then end the macro.

Instead of Text Type: <CONTROL>c try using Text Type: <ControlDown>c<ControlUp> Instead of Delay 100 Milliseconds after the copy-to-clipboard, use Options | Preferences | Delays | Delay after clipboard -- I believe the default is 250 milliseconds, which seems to work pretty well, if not bump it up to 500 milliseconds and try that. Using the Preference just saves you having to code the delay after each copy-to-clipboard. No guarantees, but maybe these methods will help.

Thanks, Kevin. That's just what I had in mind, the MacroExpress equivalent of a mainframe assembler lanuage translate command. There may be some other unprintables above hex '31' that need to be converted to spaces as well, but I don't have my reference tables with me to tell you what they are.

I don't think the typing speed has anything to do with it, and I don't think you are doing anything "wrong" as such. Most mainframe screens are "formatted", meaning that there are control bytes between the visible fields which control the displaying of data. Most control bytes do not have a corresponding keyboard character associated with them. They appear as blanks on the screen, but if you could look at the data stream you would see they are not really ascii '32' (ebcdic '40') values. There may even be several consecutive control bytes where only a single blank space appears on the screen. So you are probably right, that there are bytes in there that are not true text characters and perhaps the modify string can't handle them. I copied a mainframe screen and pasted it into Notepad, and Notepad changed the non-displayables to blanks, thereby cleaning up the data stream. In many languages it's easy to write a "translate" command to filter out the non-display characters, but I don't know how you would do it in ME. So you may be stuck with the solution you have found, using Notepad as the intermediary.