paul

All, I'm running a simple macro illustrated below..

...

The streaming video is brought up and runs for a short period or time. To determine if anyone is still watching the streaming video i display a message box. If the user clicks on the "yes" button in the message box the video app continues to run. After the "wait for time to expire" elapses the video app closes. I want to repeat (loop) this somehow so that as long as the user continues to click on the "yes" button the video app will continue to run. The default response to the "IF Message" is "no". If no one clicks on the "yes" button the video app closes out after the first pass of the "IF Message" statement or after no response after a pass (or many) within the "Repeat until" phase. With the "Repeat until" function i can't figure out how to set it up using variables and stuff. If i am totally wrong in what i am doing please let me know that also. Thanks.

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

I am trying Clipmate for the first time, on Windows 7 Home Premium 32-bit.

Powerpaste does not work properly when Macro Express Pro is running.

Symptoms are the same - selection runs up the list of clips without

user intervention. From previous items on the Web, it seems that any

macro software that monitors the clipboard will cause Powerpaste to

behave this way. My question is, can clipboard monitoring by

Macro Express Pro be turned off?

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.

I have been running Windows 7 for a few months, and initially, I had a lot of crashes as well. Not only with Macro Express, but with other programs as well.

...

Perhaps it would be worthwhile to experiment with disabling all Windows 7 eye candy, and determine whether Macro Express becomes more stable.

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).

Yeah, I would second the addition of regex support. A search-n-replace operation that needs dozens of lines of code can often be distilled into a single regular expression.

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?

I just had another freeze and did the user switch trick again but this time tried something a little different. First I killed MacScript.exe and went back to my session to find it still frozen. Then I went back and killed MacEdit.exe but again this did not thaw the first session. After I killed the final process MacExp.exe it finally thawed the first session. Not that much new, just that it seems all the MEP processes must be killed in order to get it to thaw.

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!

The code is also a kludgy. MEP can't seem to perform logic operations on nested variables like %movie%loopcounter%% so I had to use intermediate variables.

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

Hi, am just returning to Macex after a long absence. Many new features!

 

I'm happy to see the addition of arrays, but I can't seem to get them to work.

 

I have a list of IMDB Top 250 films in a text file (attached). One movie per line.

 

How do I get Macex Pro to parse the file and stick each movie into a separate element?

 

e.g.

movie[1] = The Shawshank Redemption (1994)

movie[2] = The Godfather: Part II (1974)

movie[3] = Il buono, il brutto, il cattivo. (1966)

and so on...

 

I did try the "TEXT FILE BEGIN" command, but all I get is a single variable (movie[1]) filled with the last movie on the list.

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.

Anyone else see the behaviour I've illustrated here please?

I get the identical behaviour - clearly another bug.

We have made a number of changes to correct this problem. The feedback we have received indicates that Macro Express Pro v 4.1.6.1 has corrected this issue. We advise all to upgrade to the latest version of Macro Express Pro.

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.

Clear Variables > Clear All of this Type executed in a called macro does not clear global variables from the parent. My question is do you macro writers consider this a bug or should it work this way? I can think of arguments either way.

 

Example: Macro A sets the global string variable %test% to "something" and then runs macro B. Macro B which has %test% defined as a global clears all text variables then displays %text%. But the text box now shows "Something".

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?

I've been dabbling in VB.NET and find things even quicker then you AutoIT anecdote.

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!

I agree with you on the performance issue. I guess I'm just optimistic they can solve them soon.

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.

It's one reason I don't understand why any seasoned ME3 user would not want to migrate to MEP. In fact that feature alone would be worth it to me.

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.

Tried that a few times, Alan, with no luck. And it seems that only macros that run their normal course get an updated entry in that column. A macro that's interrupted, by whatever, doesn't get a new Last Run Time.

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.

Hint: I suggest you not use the 4 predefined variables. Instead create your own named variables. So much nicer to have meaningful names and not be limited to 99 elements.

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.

It was fixed in 4.1.6.1. What version are you running? I would have Forrest get stuck running many times but I have not seen it once on any machines since 4.1.6.1.

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

One particularly odd thing is that during these MEP runaway macros, when I do eventually get Task Manager displayed, all of the 3 MEP processes (MacExp, MacEdit and MacScript) are shown as consuming zero CPU resources.

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.

Yes, that's what I mean about your having misunderstood me! Not surprising mind you, as I did raise a complex side-issue. If you read below

Edit, an hour or two later:

you'll see I was decribing behaviour unrelated to runaway MEP macros. Whatever is causing this strange effect (a consistent roughly 20 second delay in launching a shortcut from a KB shortcut) it's not 'degraded responsiveness' due to MEP. Not only is there no MEP macro running, stable or otherwise, but it arises with MEP closed.

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.

But for an application like the one below (which I've simplified for discussion) I really see no reason why this facility shouldn't work. Where am I going wrong please?

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.

Here, Here!

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

Eh? As I said, this hotkey delay issue applies to all shortcuts, not just that to my MEP killer.

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).

Is it possible to have a macro "know" that text it copied is italicized

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).

I think I am going to put in a feature request...

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!!!