paul

The following code opens 2 copies of Notepad, saves all window titles containing "Notepad" to a handle variable %hwin% (an array variable of 5 elements), then repositions the first window (%hwin[1]%). It works perfectly for me. Launch Program and Activate Window: Program "notepad.exe", Parameters "", Window "notepad" Launch Program and Activate Window: Program "notepad.exe", Parameters "", Window "notepad" Variable Set Handle %hwin% from all windows with the title of "notepad" Window Reposition: %hwin[1]% Move 10%, 10% relative to the current location <LAUNCH PROGRAM AND ACTIVATE WINDOW Title="notepad" Exact_Match="FALSE" Wildcards="FALSE" Path="notepad.exe" Mode="\x00" Default_Path="TRUE" Wait="1" Wait_For_Program="12"/> <LAUNCH PROGRAM AND ACTIVATE WINDOW Title="notepad" Exact_Match="FALSE" Wildcards="FALSE" Path="notepad.exe" Mode="\x00" Default_Path="TRUE" Wait="1" Wait_For_Program="12"/> <VARIABLE SET HANDLE Option="\x00" Info="notepad" Partial="TRUE" Wildcards="FALSE" Destination="%hwin%"/> <WINDOW REPOSITION Option="\x01" Title="%hwin[1]%" Partial="TRUE" Wildcards="FALSE" Method="\x0B" Left="10" Top="10" Monitor="0" _IGNORE="0x0006"/>

When you start a process, the system needs to know which process you want to start, so you specify the path in order to avoid any ambiguity. Once the process is running, there's no ambiguity any more because each process has a unique Id (PID). So you may have several processes running, all called xyz.exe. If you use Task Manager to kill one of these processes, you must manually select which process you mean. If you use a Kill utility, you'd use a PID, otherwise you'd likely kill all processes with that name (that's how PsKill works). With ME, you can specify a window name. If you use the process name instead, one of the named processes is terminated; I don't know if it's the first process found, or the first process started, or whatever. But the path used when starting the process is completely irrelevant to Windows.

You can say "Your English has improved [a lot]", or "Your English is much improved". But if you say "Your English is improved", or "Your English has much improved", then I know immediately that you're not a native English speaker. Neither of these latter sentences flows properly - I can't really explain it more accurately. Und ich habe Englisch an der Odenwaldschule in Heppenheim an der Bergstrasse unterrichtet!

AutoIt, which is one of the supported scripting languages in MEP, has a range of sophisticated commands for handling windows, even multiple instances with the same window title.

Well, I've installed and used this utility on several machines with absolutely no problems. My reaction, Terry, is the same as Cory's (I think it was Cory) recently - your machine is wondrous strange and produces errors in many circumstances which appear unique to you and your configuration. If ever there was a candidate for a complete rebuild of everything (OS and all apps) from scratch, I'd say yours would be the one!

As an alternative, try FileNotify

AutoIt would certainly allow the generation of sophisticated multiple choice menus - you'll need to learn the language, with especial reference to the built-in GUI command set. And no, the user does not need to install AutoIt since you can "compile" AutoIt scripts into .exe files.

Have you managed to obtain the Shutdown utility? It's not the one included iwith Windows! You can get it here: Shutdown

Yes. It's exactly the same as your normal environment. So have this macro call a separate macro called, say, Unattended, and include in Unattended all the stuff you want to achieve. Once Unattended has finished, include in my macro the final command "Lock Workstation" (I assume that command is available in ME3? - if not, let me know and I'll provide an alternative method), or Hibernate or Shutdown, whichever you want.

I do this regularly as follows: - I have a macro that changes 2 registry settings to allow the computer to boot and log in automatically - The macro then reboots the machine even though it is currently locked - Once the machine has rebooted and logged in my Autostart macro undoes the 2 registry settings so that the machine no longer logs in automatically - The Autostart macro runs whatever macro(s) you need to run - The macro finally locks the computer Please refer to Running macros on a locked workstation and the last message in More information for more details

I wonder if that's true. Doesn't MEP inist on rebooting after installing an updated version, even if all MEP processes are terminated before installation?

Well done, Chris, for both reading this forum and responding so quickly.

My MEP Startup options are as follows: - Show the Spash Screen Unticked - Show the quick start guide Unticked - Show the editor Unticked - Run when windows starts up Ticked - Wait for n seconds before initializing the program Unticked My Startup folder shows this: "E:\Program Files\Macro Express Pro\MacExp.exe" normal window MEP starts up minimized.

Let's examine the logic here. I think we all agree that if the specified key is not pressed within the nominated time, then an error occurs - "The condition was not met within the specified amount of time". There must certainly be a standard method of handling all errors. When an error occurs, MEP provides us with 4 alternatives: - Ignore the error and continue - Ask the user what he wants to do - Handle the error with error-specific code (On Error/Catch Error) - Halt the macro The 1st choice allows the developer to say "I don't care about this error - just carry on as if the error hadn't occurred". The 2nd choice allows the user to choose whether to Halt the macro, ignore the error and continue, or handle the error (I don't really understand what this last choice really means, as it seems to behave like the ignore choice; perhaps the user is expected to conjure up some error-handling code and somehow get the running macro to execute it ). The 3rd choice allows the developer to plan what to do in advance of the error. This offers maximum flexibility, and could presumably offer the user a menu of choices if relevant. The 4th choice is a bit of a cop-out! It's the default choice for many (or perhaps all errors?), and just provides the same behaviour as in ME3 (which was almost the only choice in ME3). The important point to consider is that choices 1 and 3 represent decisions that the developer has made about what to do, so no notification message is required when the error occurs. Choice 2 obviously tells the user an error has occurred - he gets to decide whether to carry on or give up. Choice 3 represents the fully planned approach - the developer chooses whether to display error messages or not. Choice 4 really is no choice at all. When choice 4 is mandated, I definitely want to know that an error has occurred. Otherwise who knows what is going on? If I want the macro to stop without any notification, then I must write the error handler. I think that if we're asking for this particular error to halt the macro with no notification message, then we're asking for this behaviour to occur throughout MEP for all commands, whenever such an error occurs (which I am definitely not in favour of). IMHO, it would be unreasonable to request this pattern of behaviour for the Wait For Key Press command alone. In his original post, Rich expressed a wish that MEP would behave more like Visual Basic. Unfortunately, VB no longer behaves like this - VB.Net now provides error-handling very similar to MEP. So, IMHO, this is not a bug, but a feature!

Yup.

Actually, I can think of many uses for a mute button, many of which would certainly make much of this discussion moot!

I think I must be wiser than you! I would never ever ask any dentist for "a cut" - it would be too painful to contemplate!

Well, if we're into making our messages less irritating and easier to digest, I'll add two pleas of my own. Try and get the apostrophe right in "its" and "it's". The first "it's" above (it's own self) is wrong, the second one (It's very simple) is right. "It's" means one thing, and one thing only. It means "It is". "Paul's coat" gets an apostrophe, while "its coat" (denoting possessive) doesn't. Every time I see a misused apostrophe in "it's", I gnash my teeth and rage silently to the wall. My dentist wants me to stop this! Please read through what you've written before posting - preferably more than once. This forum is full of messages with sentences that are very hard to read because of misspellings, or missing verbs, or missing nouns, etc. You're more likely to get help if your message is easy to read and understand.

1) Not hittng the Enter key within 5 seconds: - If I run your macro from a hotkey, I get a Script Error about the condition not being met within the specified amount of time. - If I run your macro with F9, I get a debug error message to the same effect. 2) Hitting the Enter key within 5 seconds: - Error message continues to appear When I disabled the 2 Notepad lines, it still didn't work. Changing the Enter to Shift also didn't work. Changing the Shift to Tab did work. Changing the Tab back to Shift did work. Changing the Shift to Enter did work. Re-enabling the Notepad lines stopped it working again. Re-disabling the Notepad lines allowed it to work again. There are clearly several problems occurring. Before reporting the problem, you should try replacing Notepad with a few other different types of program - this might help isolate the aberrant behaviour.

I don't see a problem! Here'a macro that waits for up to 5 seconds for the letter "a" to be pressed. If the letter is pressed, a message is displayed to that effect. If the letter isn't pressed, the macro stops without displaying any message. <WAIT FOR KEY PRESS Key="A" Indefinite="FALSE" Hours="0" Minutes="0" Seconds="5" _HANDLE="0x0014"/> <ON ERROR/> <CATCH ERROR Code="20"/> <MACRO STOP/> <END CATCH ERROR/> <END ERROR/> <TEXT BOX DISPLAY Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang1033{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\lang3081\\f0\\fs16 A was pressed within 5 seconds\\lang1033\\f1 \r\n\\par }\r\n" Left="Center" Top="Center" Width="278" Height="200" Monitor="1" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/> In English: Wait for Key Press: A (The On Error tab is set to "Handle Error" for the first error code shown) On Error Catch Error: The condition was not met within the specified amount of time Macro Stop End Catch Error End Error Text Box Display: (A was pressed within 5 seconds)

Just a caveat here. I use the same approach of checking the colour of that X. I often attach to a remote MySql database via a web page, and need to select the database, open the SQL tab, run a dummy query, edit it, and close the results window before I'm able to use the facility. So, of course, my macro goes through all these preliminary steps for me. But opening the SQL tab does not work unless I wait several seconds after that X becomes grey, even though there's no visible on-screen indication of anything changing.

On my sick machine (disk activity is relatively slow, I can't hibernate, and often have to reboot to get the Internet working again - but, hey, watch me fly when Windows 7 arrives), it's less than a second. I have 510 macros. I agree wholeheartedly with you about the overall sluggishness in the current release. It's fixed a couple of important bugs for me, but is noticeably slower across the board than any previous release. And some commands, e.g. Variable Restore, are glacial.

You can achieve this by: - setting x and y to 0 - within a Repeat loop - scanning for a specific colour at the current x,y location - if not found, increment x + (or reset x to 0 and increment y when all x values have been tested, + or exit when all x and y values have been tested) - if found, move the mouse to the current x,y location, and exit or wait for a response Repeat the above as many times as desired, using the last found x and y values as your starting point.

Interesting.... Me too!

How very true! I'm simply trying to encourage your users to upgrade to MEP!