Cory

Yes! Good catch. I can't believe I forgot to mention that one. I had it in mind then... Well I must have forgotten.

I was just starting to review your code when the alert popped up. Auspicious timing and saved me some time. I'm happy you got it working. Whenever I have something with very long delays and several (Meaning distinct and different) tasks, I make multiple macros that work in concert. So instead of having a macro that sits around 30 minutes and then does something, I would instead schedule it to run every 30 minutes. See the "Schedule" activation options. Also I will often have one master macro respond to and control the others. Sometimes passing information in the registry or using the controls of actual macro dialog boxes. Sometimes really handy to pass a result back from a control of a MessageBox, and one can use the "Wait for control" command. Aside: I often use the Windows Scheduler to start macros. If you ever find MEP's scheduled activations lacking, check in there.

No. You need something to set the token. That's what I'm suggesting. It could be a completely invisible macro or other type of script.

I'll look at this later when I have time. In the mean time you might check to see if yoru Get Pixel is relative to a window, absolute or what. Don't be sorry, it's cool if you want to do it, I only suggest it so you get better results. I've seen it often when there are multiple issues responders focus on one and the others get forgotten. BTW many have posted here trying to automate games and often the problem is that the programs have bot countermeasures that will thwart MEP. To terminate the macro I would make another macro that places a token in the registry or in a file when you run it. Then in your loop in the main macro, check to see if that token exists and abort if so.

Please export your macro to an MEX file so we can look at what you're doing. In the future you might consider making one post per issue. Hotkeys are for activating a macro and not a normal functional thing in the macro. You should have error handling, or other checks in your code to handle termination in the cases it needs to. Please explain what you want to get out of and I might be able to offer a suggestion on how to do that when needed. Having said that, look at the categories pane at the left of the Macro Explorer look at System Macros. You can see there are built in macros to do things like suspending execution, Resume/pause terminate MEP. You can also stop a macro by clicking the running man, I call him Forrest, in the System Notification area.

You're welcome.

Not by design, but you could use two macros. I could imagine having a macro that only has the MCM and stores the result in a file, registry, or such, and the main macro could control it. Then a loop with 1 second delay without the "Wait for this macro to terminate before proceeding" option in the Macro Run command.

I don't think it works the way you're thinking. MEP isn't in Word. You can't run VBA in a Word instance that way, it needs to be in a module attached to the document. You could add button in Word to run the macro. Or if you wanted to have a pop up menu, you could have it fire a hotkey you established for that VBA macro. This article shows you how to assign a hotkey or button in Word to fire a macro.

I don't know Go. I would also consider the application. Like C++ is more for hardware. C# better for databases. I know that some hobbyist who do a lot of automation gadgets use Python mostly. So I'd find some forums of people doing the kind of things you do and see what they tend to use the most. Or just search for a typical problem and then see which languages pup up the most often. For me it should be C# so I will be learning it soon. Here's a nice list. What rberg said about getting your mind around OOP is key. It isn't so important what language it is, the biggest problem is un-learning procedural language and understanding classes, objects, events, threading, and so forth. Once that's in yoru brain, it's more like semantics. For instance I can look at a program in almost ant even driver OOP and make sense of it. So I believe that learning C# for me will be one tenth as hard as it was to learn my first OOP language, VB.NET. You might have a look at the classes at W3Schools. I'm considering taking a few of their classes.

You're welcome.

I don't have much time so I apologize for the brevity. Many years ago we talked about this problem and the short answer is that there isn't a simple solution. Search the messages and you should be able to find our posts. I think I started it and it was regarding Outlook. If memory serves. I don't remember the solution, I know there were a few. I think I ended up either tracking the handle of each window as it appeared with another macro or my macro looped though each window and used controls to identify the one I wanted. Sorry I can't be of more help today as I have many tasks to accomplish by end of day. I'll try to check tomorrow.

There's nothing that I know of like MEP. Python is considered the easiest and most readable of the modern object-oriented languages. I have not written anything in it but one of the criticisms is that it's a little too easy and facilitates sloppy code by allowing les strict typing and rules. So the "easy' is a double edge sword. There's tons of free training and swarms of people who use it. When I decided I wanted to amend my skills, I looked around and elected to learn VB.NET. It's uses the same framework, IDE (Visual Studio) and all that is the same as the other big languages like C#, but I find much more readable. Also I used to write some MS Office macros and so I liked that VB.NET is similar to VBA and VBScript. However it has now been deprecated. MS will continue to support it but they have stopped developing it. However it's not likely that I will ever need any of those improvements in the remainder of my career. But I am considering learning C#. For the kinds of things I do it's the most common and best language that MS has to offer.

You're welcome. Let me know if that helps you understand. I think control based macros make macros shorter, more capable and more reliable and I hope everyone will try to learn them. I went for years avoiding them becasue I initially didn't get it, then after learning how to use them I was kicking myself for not learning sooner. They make macro development much easier. Also great for macros that can do things without disrupting the user.

Where I grew up we soft drinks were "pop". It took me a long time to adjust to "soda" here in Cali. I was really confused when I discovered that many people call a Dr. Pepper or a Pepsi a "coke". Seems confusing to me but... Maybe it was a conspiracy by Coca-Cola. I attached "Control Example.mex" to my message. See screenshot attached. Just open it in MEP and look at the macro therein. Then open up Notepad and run the macro.

Jinx. You owe me a Coke. LOL Use this macro. I forgot to mention first open Notepad. I get the control handle then I send text to it. 2 macro commands. Remember, getting the address of the control is like looking up the number in the phone book. One still needs to make the call.

Have you followed the Calculator sample? That helped me a lot. I'm trying to find it but I don't have time. In the Samples.mex there's a Using Windows Controls. You might check that one out also. Can you show me your code so far? Where are you getting stuck? So for me I start my normal macro. Then I set the Get Control command. Then maybe send some text to that control. Attached is an example. Control Example.mex

I don't have much time but I'll try to give you a little understanding. I too found the name of the commands confusing, but after I learned how they work, the names make sense. Generally you're wanting to use Get Control. Controls are volatile. We see a control in an application and think "Oh, there's that control again." but to Windows it's different every time. In order to interact with a control you need it's address, called a handle. Every time you open Notepad all the controls including the form (program) are assigned a handle and it's different every time. And, in fact, you have have two instances of the program happening at the same time. The system distinguishes them and their controls with distinct handles. Here's where the Get Control made sense for me. We can't predict the handle the system will issue, so we need to wait for the controls to exist and then we need to tell MEP how to... Yup, Get the Control handle. So a control variable simply holds the address of the control. So this control address needs to be found before you can interact with said control. Bear in mind all the text boxes, buttons, and so forth are all controls in a traditional WinForm application. So MEP uses the title of the window to drill down and find the address of your text box for instance. Now that you have it, you can do things like sending a mouse click even to a button or setting it's text value if it's a text box. And they don't even need to be visible to do so. Also consider using the controls for flow control. I use Wait For Control often. It can make your macros Wikiwiki. I hope this helps. I'll follow this topic if you have more questions.

Good suggestion. I couldn't figure out if he was talking about the TextType editor or not. It wouldn't have occurred to me that it was sized down. Cliff if that doesn't solve your problem I suggest sharing a screen shot of what you are referring to.

Does that script work by itself? I thought one must execute macro code from within the app. I didn't think you could run them externally. For things like this I use Interop, but that needs to be executed in a .NET program. It's like a MEP for Office apps. Most of the commands are doing things as one might command a user to do them. It's not an MEP thing so if you're interested, PM me.

In cases like this I find MEP control commands are easier to implement and more reliable.

It's the same process. Just cast the sting to a date/time variable type instead of integer. Then add 20 to the year part of the Date/Time.

See attached. There's no scope or activation defined. Add.mex

rberg is right. Also when I open a new macro file I immediately delete the 4 standard variables. It's a holdover from ME3 and I feel one should meaningfully name their variables. Also only make them array variables when an array is needed.

I don't know what VDI you use, but in most like Remote Desktop the Windows controls are all paused when not connected. This makes even having a VM often pointless. I've even had clients who have had racks of old PCs that ran macros for this reason. The way we would do it with them is to connect to the console session of a headless Windows machine, typically using VNC. By doing this one can disconnect from the machine but the console session doesn't pause like a RD session.

You might want to make sure the Web Browser is focused.