paul

No need for boolean variables, or, indeed, any variables at all! Repeat Until %n[1]% Does not Equal "%n[1]%" If Message "CNN" Wait for Time to Elapse Continue End If Repeat Exit End Repeat - My Repeat never ends automatically since I have set an impossible condition - If the response to If Message is Yes, we execute the Wait and Continue commands; this latter command ignores the remaining code in the Repeat loop and restarts the loop - If the response is no, we execute the Repeat Exit command, which ends the loop Here's another way of expressing the same idea: Repeat Until %n[1]% Does not Equal "%n[1]%" If Message "CNN" Wait for Time to Elapse Else Repeat Exit End If End Repeat

Sorry to disappoint you, but if you terminate MEP you'll still find that PowerPaste "works" in the same way as you described above. I experienced the PowerPaste problem in Windows 7 within hours of installing W7. In a nutshell, PowerPaste has worked for me in W7 on exactly 3 occasions, none of which I can reproduce! The latest example of it working was the other day when I accidentally invoked PowerPaste: all my suspect software (UltraEdit, MEP, DOpus, Actual Window Minimizer, Everything, Executor, Firefox, Gdow, Katmouse, ResizeEnableRunner, Roboform, Logiitech SetPoint, True Launch Bar, UltraMon, Vmware) was running, and PowerPaste worked. I got quite excited, and immediately tried it again - this time it behaved as you described. Unfortunately ClipMate was written in Delphi, for which there's no prospect of a 64-bit platform until long after that leaking oil well has been capped! I know you're not running 64-bit, but ClipMate has not been updated for a very long time, and I think the author (Chris Thornton) has simply given up.

The first thing I do after installing a new OS is remove all eye candy (except for the ability to see a window while dragging, and ClearType).

You know, I'd far, far rather Insight fixed all the outstanding MEP bugs before they start to add new functionality! I still experience screen display problems, freezes, running men when they should be stationary, extreme slowness in many operations, etc., etc. And I would really like the Run Macro In Variable command to work properly, i.e. with user-defined variable names. Recently I'm not receiving acknowledgements of new bug reports, nor of bugs fixed. Anyone else experiencing this?

In contrast, I also had a freeze yesterday; but killing just MaxExp.exe and leaving MEProc64.exe running cured the freeze on this particular occasion. I think there's only one consistent rule that holds true in all freezing circumstances: there are no rules; each instance can be different from any other. For example, I've experienced freezes where: - killing one process and restarting MEP cures the problem - killing both processes and restarting MEP cures the problem - killing both processes and restarting MEP does not cure the problem, nor does logging out - only a reboot works - facing east and uttering imprecations never works, but it may help you feel better!

1) If you make %movie% an array, then %movie[%loopcounter%]% works just fine. When %loopcounter% is 1, this represents %movie[1]%, etc. 2) I wrote this macro: Variable Set String %tString1% to "String1Value" Variable Set String %tString2% to "String2Value" Variable Set Integer %nIndex% to 1 Text Box Display: --String1 = %tString%nIndex%% Variable Set Integer %nIndex% to 2 Text Box Display: String2 = %tString%nIndex%% And the macro displayed String1 = String1Value followed by String2 = String2Value

Did you look at the example under the command "Text File Process"? I think its text makes things fairly clear. Hint: You need to process each line of the file using the variable you declared in the Text File Begin Process - place this code before the Text File End Process command.

I get the identical behaviour - clearly another bug.

Sorry, but this statement is no longer true. I have just experienced my worst MEP lockup ever! With MEP v4.1.6.1 loaded but not running any macros, suddenly my machine slowed down in the same way I've reported before. Bringing up Task Manager under Windows 7 Professional x64 proved difficult, but after perhaps 5 minutes I ended up with multiple copies running. Killing "MacExp.exe *32" didn't solve the problem. But killing MEProx64.exe allowed the machine to return to normal. Then, for the first time ever, restarting MEP immediately brought my machine to its knees again. This time I killed the 2 MEP processes in reverse order, and it was only after the 2nd process had been terminated that the machine returned to its usual excellent performance. My only solution was to reboot, as logging out and back in also failed to solve the problem. I'm almost certain the problem is caused by some strange failure by MEP to interact with other processes. At the time of this failure, I had a video editing program running (VideoRedo TV Suite v4.20.5.600) and I was playing Backgammon (GNU v0.90-mingw 20100220). I had just saved an edited video when the problem occurred. MEP is clearly the culprit, even if the original cause is (as I suspect) a video problem of some sort. There is absolutely no possibilty whatever that any other program is to blame. Otherwise the unloading and reloading of MEP would not immediately cause the same problem to disappear and reappear, over and over again.

Interesting question. My answer would be: it depends whether MEP has any concept of ownership of variables. If Yes, then only Macro A should be able to clear %test%; if no, then your example should have worked as you expected. Now try your test again, this time making %Test% an array of 1 element, and changing all references to %test% to %test[1]%. Leave the Clear Variables command as is, i.e. Clear all Text variables. Run Macro A again, and there's no change in behaviour. Finally change the Clear Variables command to clear only the 1st element of %test%, and it now behaves as you probably expected in the first place. IMHO that's now become a bug, because variables should behave the same whether they are arrays or not. Do you agree?

What version of VB.Net are you using? Did you ever learn VB6? Do you find the language relatively easy to use? I've not really taken the plunge into the world of .Net. Perhaps I should!

My fear is that these performance problems are caused by flawed basic design, and therefore cannot be solved without a fundamental rewrite. For example, in its early days (and even now) MEP had a number of very silly display problems, which I always thought were caused by not using standard graphics techniques (e.g. prompting for a variable used to cause the running macro to freeze, requiring MEP to be unloaded and reloaded). My current problem (reported some time ago but never further referenced by Insight) is the command categories in the script editor. They go funny on me after a while, so that the category names disappear, and the detailed commands misbehave when I double-click on one (an entirely different command appears). Running the mouse up and down the invisible categories without pressing any buttons usually fixes this, but it's irritating.

Well, MEP is still full of bugs, and is extremely slow at many operations ME3 ran in the blink of an eye. You know, I still have no clue why AutoIt can process large text files very quickly, while I have never had the patience to wait for MEP to complete the same operation (after waiting for up to 30 minutes where AutoIt ran in less than 2 seconds). This "feature" is so bad that I question the technical competence of those responsible for such atrocious code.

Actually, I'm not sure that's true. I wrote, saved and ran a macro containing 2 text display commands, terminating it during the first text display command. As in every macro that I run, the Last Run Time does not get updated until I close Macro Explorer and then re-open it. And, sure enough, the Last Run column now reflects when it last ran.

Of course I agree with you completely about meaningful names. But you're not limited to 99 elements with the predefined variables - simply adjust the number of elements as desired, exactly like any other array variable.

I get the running man problem fairly often - it usually occurs when I'm running 2 independent macros at the same time.

The problem is certainly not caused by MEP hogging CPU, and never has been. The problem appears to be static, in that some system setting(s) are altered, or something is delaying keyboard messages by causing some sort of wait.

By "MEP closed", I assume you've terminated all of the MEP processes which Kevin documented a while back? My shortcuts run instantly every time. I fear I can provide only my usual response to you - it runs along the lines of "It's your machine...."! I suggest the following: - Stop MEP from running at bootup - Reboot - Try the keyboard shortcut If it's still slow, then it's your machine! If it's consistently quick, then it's probably caused by MEP - maybe MEP does lasting damage, not resolved by closing MEP. Assuming it's consistently fast at this stage, reenable MEP. When you experience the slowness problem with MEP, close all MEP processes, and try the shortcut again. This will probably produce the slow behaviour, thus suggesting that MEP does lasting damage. BTW, I experienced my first slowdown for ages, caused by MEP. At the time I was doing some video conversion, and not doing anything in MEP (latest version). Suddenly the machine slowed down enormously. I eventually managed to terminate MEP, at which point the slow behaviour ceased.

Your submacro Count Names has declared the integer variable %Count% as Local, because you haven't ticked the "Make this variable available" box! Local variables are not saved.

To which my response would be "Where, Where?"! Perhaps you meant "Hear, Hear!".

I believe that is exactly what I said; keyboard responsiveness may be severely degraded when a macro goes awry. This degraded responsiveness will apply to anything you try to do, regardless of whether it's running another MEP macro, or anything else (including Ctrl-Alt-Del).

How on earth would it know that? When you say the text is italicized, you mean that the text is prefixed and suffixed with codes that tell the target program to italicize the text. But the codes differ from one program to another. Word's codes for italizing text are quite different to, say, XyWrite. So this is going to work for you only if: - the target program is always the same, e.g. Word - you know what codes Word uses to italicize text - you can force the copy to include those codes rather than just the text itself LOL!

Here's what I experienced. I wrote 2 macros, M1 and M2, where M2 is activated by a hotkey (Ctrl-K), and simply dispalys a textbox. M1 contains these commands: Lock Player: Wait for running macros to stop Text Type (Simulate Keystrokes): <CONTROL>k Unlock Player Here, Lock Player has no effect; M2 runs when M1 types <CONTROL>k. However, if I insert a Text Box Display command immediately after M1's Text Type command, where the Text Box Display command is of the type "Timed floating box or end of macro" and the time is set to 0 seconds, then <CONTROL>k does not start M2! I consider this a bug (presumably M1 without the Text Display command displays the bug), and duly reported it (not that I've yet received any confirmation of receiving this bug from Insight).

But what is the feature you're requesting? If it's to find 10 consecutive pixels of a specified colour, you can already do that with the commands provided by constructing a simple Repeat loop. Surely new features are to be requested only if there's something you cannot already do in MEP? Or something that takes a lot of code to achieve.

Well, you're trying to kill MEP. Why are you trying to kill MEP? Because you've got a problem with one or more running macros, and you need to terminate them. I find that when MEP is behaving so erratically, one of the things it tends to interfere badly with is the keyboard! Keyboard responsiveness is often/usually/always (?) severely degraded. So why are you surprised about the hotkey taking so long to respond? It's a little similar to the infamous sequence "Keyboard error - press F1 to continue" that we used to see when booting up!!!