paul

I cannot replicate this. If I close the Script Editor without saving a macro, the "Modified" column is exactly as it was before I opened the macro for editing.

Same here.

I didn't think to post a link. I can't find the script and I later changed to ToolTipFix.exe from Neosmart. I originally ran v1 which has no install requirement. v2 has the option to run as a Service to permanently monitor, or as a standalone install. I've used the standalone option as I have too many services running already.

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

I noted in Post #3 that I also have that problem, fixed temporarily with a script by other and run by my own ME macro. I usually run it about once a day. That is definitely worth automating.

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.

Oh yes I did! It's in the title of the topic.

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!

My settings for the system tray icons regularly change for no apparent reason, eg "Always Show" becomes "Hide When Inactive". I want to be able to store the settings for my common applications (using reg file or in ME) and run a macro to restore them. Does anyone know where in the registry the settings are kept?....and no I don't want instructions how to do it manually.

 

I know how to reset via the TrayNotify keys but that's not much help. The key

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer

may be involved but I can't find any obvious data. Settings may also be stored in the application's area.

You don't mention what OS you're using!

Does this help?

Tray Icons

For many that use ME, AutoIt is not a viable alternative. It's programming versus filling in foolproof dialogs.

Agreed, though MEP is a long way from offering much that's "foolproof"!

Aren't both macros and mxe files compiled at runtime? Even if there is a lot of overhead in the programming dialogs to make them foolproof, once the code is saved, surely it's possible to store in a compiled form that will be quick to run?

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.

A big difference with AutoIt is that you have a number of programmers writing UDFs that make many sophisticated tasks simple (like all the Excel manipulation scripts). Easier to do when the labour is free.

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 did a Split String on CRLF on a TSV file with approx. 61k lines and it took 36 minutes so beware that I don't think this command was intended for any heavy lifting.

 

This is intolerable for my purposes so I'm going to have to find another solution and I think I'm just trying to push MEP to far at this point so it's no condemnation of MEP. I'm just using the wrong tool for the job.

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

Also one cannot use Macro Run to re-execute the selfsame macro.

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.

Ok I think I may have cracked this I was just wondering if someone could check it over and tell me if there is a better way to do it.

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.

A fairly complex macro I run consists mainly of a series of Macro Run commands. The last such command calls a macro, let's call it LastMacro. It's trivial, basically just a few mouse clicks and a Ctl+F4 to close that window. And it works consistently if I run it on its own. But when I run the main macro, it sometimes fails to finish. All its operations are performed with the occasional exception that the window doesn't get closed, but Forrest sometimes continues running and has to be clicked.

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 have been busy installing Windows 7 on a few computers. By the way it is the best install I have done and I go back before 32

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

You may be surprised. Do you remember the days before Windows, before DOS, before CPM? Before floppies (3.5, 5.25 or even 8 inch)? When storing programs on cassette tapes was an improvement over paper tape and punched cards? Batch processing? And when 32K of RAM was a lot of memory? Ah, the tales we could tell.

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

Now my only problem is whether I'll confuse Excel by changing the file contents. I suppose I could run some experiments to see if there are any adverse effects.

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

Excel locks file when open or even if accessing as read-only. Does anyone know of a way to get Excel not to do this? MEP will not run an ASCII File Process if the user has it open and usually it's only because they're looking at it and forgot to close it out. Also I have source data files that are created with MEP and are only referenced by Excel but I can't update the files if a user has them open. Short of having a macro sit around and wait all day I can't seem to think of an elegant work around either.

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:

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

- 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

The free program Unlocker should let you do what you want, downloadable from here.

This program won't run in x64.

Excel locks file when open or even if accessing as read-only. Does anyone know of a way to get Excel not to do this? MEP will not run an ASCII File Process if the user has it open and usually it's only because they're looking at it and forgot to close it out. Also I have source data files that are created with MEP and are only referenced by Excel but I can't update the files if a user has them open. Short of having a macro sit around and wait all day I can't seem to think of an elegant work around either.

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

Paul: Are you going to report the intermittent pop-up menu issues you described?

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

BTW, does my code look OK? In particular, I'm puzzling over the Variable Restore. Does 'restoration' only apply to variable values before a macro is run? If I precede

Variable Restore: Restore Boolean Variables

with either Variable Set Bool %bMenuCalled% to "True" or Variable Set Bool %bMenuCalled% to "False" it makes no difference. I'd have expected that value to apply directly after the restore. This is the sort of factor that has me leaning towards the registry for variable storage!

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

That's your original, not my test? Very odd. Why should that matter? Can you export your macro so I can play with it please.

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.

Extracting milliseconds from a Date/Time variable works fine.

 

The Date/Time variables do include milliseconds.

 

Here is a sample macro demonstrating their use.

Quite right - thanks.

I can't reproduce your problem. It all seems to be working OK here.

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

Edit: Hmm - not so simple after all! The menu activation etc all appears to work just fine. But I've hit an obstacle that may kill the approach dead in its tracks. A pop-up menu will 'run' for ever if you leave the option 'Wait for this macro to terminate before proceeding' checked (the default). I switched it off but have now discovered that my logic test after the Macro Run command is then ignored, despite the variable being correctly shown as ON. Still trying to figure it out. And I just slogged through adding extra code to 40 or so macros!

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.