paul

Same here.

Yes, I tried that NeoSmart fix, and the one from Kellys-korner, but neither worked for long!

Any chance you might share that script, or provide a reference to its location please?

And, of course, there's the long-standing bug XP has (which Windows 7 appears to have solved) of tray icon balloons being half-hidden behind the icons themselves. I tried several supposed fixes for this problem, all without long-term success.

If I come across a road sign, some of which is in capital letters, that's the part my eyes refuse to read! I rarely look at message headers in forums such as this one with so few messages!

You don't mention what OS you're using! Does this help? Tray Icons

Agreed, though MEP is a long way from offering much that's "foolproof"! And they are! Macros run using F9 always seem to run slower than their compiled counterparts. But if what you're compiling is, fundamentally, poor code, then compiling is not going to turn it into super code. No, not at all. UDFs (user-defined functions that extend AutoIt's functionality; take a look at some of the amazing stuff you can do with Internet Explorer thanks to the IE Management UDFs) are written by people very good at what they do, and very experienced in AutoIt development. There aren't many of these people around, and the fact that they do what they do for no financial compensation makes them even rarer!

I don't think I agree with you. I just wrote an AutoIt script to split a 4MB text file containing over 23,000 rows, and it runs in less than 2 seconds. If AutoIt, which allows for only one universal data type - no integers, booleans, strings, etc., can manage this, why can't MEP? After all, AutoIt offers vastly richer functionality than MEP, and I'm sure you can do everything in AutoIt that you can in MEP. All MEP has that AutoIt lacks is a script-building interface. I can see no reason why MEP shouldn't be able to equal AutoIt in its efficiency at running code. There's usually only a few ways of writing robust and efficient code; unfortunately MEP appears to contain much code that exhibits neither of these qualities. And just remember that AutoIt is free and is written by enthusiasts (who are extremely good at what they do).

Well, that's what the documentation claims. But it ain't so! Try this: Variable Modify Integer %n[1]%: Increment If Variable %n[1]% Is Greater Than "3" Macro Return End If Text Box Display: Macro Run: TestRecursive Text Box Display: <VARIABLE MODIFY INTEGER Option="\x07" Destination="%n[1]%"/> <IF VARIABLE Variable="%n[1]%" Condition="\x03" Value="3" IgnoreCase="FALSE"/> <MACRO RETURN/> <END IF/> <TEXT BOX DISPLAY Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang3081{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs16 Starting Recursive macro %n[1]%\\f1 \r\n\\par }\r\n" Left="Center" Top="Center" Width="278" Height="200" Monitor="2" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/> <MACRO RUN Use_ID="FALSE" Name="TestRecursive" ID="-1" Wait="TRUE"/> <TEXT BOX DISPLAY Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang3081{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs16 Ending Recursive macro %n[1]%\\f1 \r\n\\par }\r\n" Left="Center" Top="Center" Width="278" Height="200" Monitor="2" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/> I get this result: Starting Recursive macro 1 Starting Recursive macro 2 Starting Recursive macro 3 Ending Recursive macro 4 Ending Recursive macro 4 Ending Recursive macro 4 which is correct if recursion is allowed.

@ is also a perfectly legitimate character in other contexts, so you need to be certain that this character is used only for email addresses.

Your code looks and works fine, though I would change the "file must be ready for" of the Wait for File command to a maximum of 2 seconds instead of 10. Your code contains these assumptions: - only .exe files will be moved to the target folder - all .exe files will be moved to the target folder - the target folder will not already have [a] file of the same name as the one you want to move To be pedantic, I'd prefer to see your variable names without spaces, and of a standard format. In your code you use %Exe Name% and %file_extension%, while I would use %tExeName% and %tFileExtension%, where the initial t indicates a text variable. This isn't at all important in a macro this short and simple; but in longer macros, consistent variable names can aid in understanding and debugging.

It's almost certainly related to calling macros. I've reported similar problems to Insight, but so far they cannot replicate. And there's no consistency - sometimes Forrest goes, sometimes he stays. I have a macro that logs out of Roboform (secure password manager for web sites), initializes some variables, then calls macro1 which opens the relevant Roboform passcard. Opening a Roboform passcard when logged off causes an independent Roboform window to open, asking for the master password - and I have a self-opening macro (macro2) for this that runs when it detects the new window. If macro2 ends as soon as it has provided the master password, Forrest always disappears. But if macro2 contains more code to deal with special cases, Forrest often remains.

I didn't know there were computers around in the year 32!

And I knew a guy who could read paper tape like you and I can read a book!

I had a quick play, and Excel happily saved data back to the text file (of course the file was then locked again; and you're not going to be able to control your users to the extent that they won't be saving; but there's no reason why, any time you want to access the file, you don't run that handle command using the find syntax because it'll return nothing if the file isn't locked by Excel). Of course, as they say everywhere these days, no guarantees...

The following will work; my examples use d:\MyDir\MyFile.txt as the file whose Excel handle you want to close: - Download the Handle utility from SysInternals - run handle from your macro to extract the data you need to close the handle: handle d:\MyDir\MyFile.txt >d:\temp\xx.txt This will store into d:\temp\xx.txt data like: Handle v3.42 Copyright © 1997-2008 Mark Russinovich Sysinternals - www.sysinternals.com EXCEL.EXE pid: 6016 308: D:\MyDir\MyFile.txt which you can parse to extract the two numbers you need - the pid (6016) and the handle (308) Note: Even better, use this command: handle d:\MyDir\MyFile.txt | find /i "excel.exe" >d:\temp\xx.txt which will return EXCEL.EXE pid: 6016 308: D:\MyDir\MyFile.txt - run handle again from your macro to close the handle you just found: handle -c 308 -p 6016 -y This will close the handle without any messages; you can now access the file from ME

This program won't run in x64.

There are utilities which, when you right-click on a file and select the relevant option, will tell you who is locking the file and offer you the choice of unlocking it. I use LockHunter x64 and I was able to unlock a text file currently open in Excel. A macro I wrote to read this text file failed to work before I unlocked the file, then worked fine after. And Excel didn't seem to mind either, happily writing back to the file on request. The trouble is there's no command line capability, so it may not be what you're looking for. LockHunter

Already done.

There's actually a better way of doing this in ME3 unless you don't mind the flickering the above method causes by closing then reopening the text box display in lines 2 and 3. I used the following method in ME3, which results in a flicker-free and continuous display of changing data. I'll write this in pseudo-code - you should find this easy to convert to real code. Note that you will be using 2 almost identical text boxes, the only difference between them being the value of the Repeat No.: Set %N91% = Number of repeats (I use %N91% and higher so as not to interfere with variables you might already be using) Set %N92% = 1 Repeat until %N91% = 0 Text Box Display: Progress (Repeat no. %N92%) If Window "Progress (Repeat no. %N93%)" is running Text Box Close "Progress (Repeat no. %N93%)" End If If Not Window "Progress (Repeat no. %N92%)" is running Macro Stop Else Decrement %N91% Set %N93% = %N92% Increment %N92% End If End Repeat - It's vital to have a changing variable value as part of your text box header. - Unless you want to display other stuff, you can make the height just enough for the header only. - The 1st loop won't find the window referred to in line 5 since %N93% will be 0. - The 2nd loop will create a new window showing "Repeat no. 2" since N92 has been incremented from 1 to 2 with this new window entirely covering the old one, then close the old window showing "Repeat no. 1". etc. If your loop executes quickly, you might want to insert a delay of 500ms after line 4. Note that if the user closes the text box, the macro will stop (behaviour you can easily change).

In the beginning (i.e. when MEP is first started) no variables have any values, apart from the default values. Integer variables all equal zero, string variables are all of zero length. Now set %n[1]% to 100, and do a Variables Save Integer variables. Later (but without restarting MEP), do a Variables Restore Integer variables. Now all non-integer variables retain their current value, and all integer variables equal zero, except for %n[1]% which equals 100. Any integer variables you created and set in the same macro before you did the restore are gone. Thus, a variables restore command will restore the variables of the designated type to the values they held when you last did a variables save in the same execution of MEP (i.e. without restarting MEP).

Different behaviour tonight! Now, with a Text Box Display command following the call to MenuPopup without waiting, the popup menu appears, followed by the Text Box display (just as if the Wait for completion were ticked). The only problem now is that Forrester remains, though now I can dismiss it by clicking. And if the popup menu used the Default Style, then it appears for only a moment, then disappears because the calling macro resumes control. All in all, a can of worms.

Quite right - thanks.

It's the Text Box Display command that is the problem! If I remove it and insert non-interactive commands, it all works fine.

There seems to be a bug here which you should report. Even if you switch off the option 'Wait for this macro to terminate before proceeding', the calling macro never seems to regain control. For example, Macro Run: TestMenu2 Text Box Display: where TestMenu2 is a popup menu, the Text Box Display command never executes. At least I can kill Forrester when the option is unchecked. When checked, I must kill MEP instead. Even calling TestMenu2 via MeProc gives the same result. Popup menus must really screw MEP badly. So, of course, my previous suggestion about using variables won't work, and nor will your registry stuff because it's never executed.