paul

Why not take advantage of MEP variables - there's no need for the registry at all? In your menu macro, add a boolean variable called, say, %bMenuCalled%, and set it to True. Now insert lines at the top of all your macros, as in: If Variable %bMenuCalled% Equals "True" CalledFromMenu Processing Logic Else NotCalledFromMenu Processing Logic End If Voila - Nothing else required.

What logic test? I didn't see any logic tests in any of the examples you showed!

What am I missing here? How are you going to add any code to your popup menu? I've not actually used popup menus, so I just created one, but was unable to find any code to modify or insert.

Although it converts to MEP without error, I'm not convinced that all the functionality works, and we've never spent the time and effort needed to ensure 100% compatibility. I'll take a look at the macro timing functions tomorrow and see if anything can be resuscitated.

I hardly use date/time variables, so, realizing I'd already used d for date/time, I simply used the next relevant letter for decimal, i.e. the 2nd letter instead of the first! Curiously, in VB I always use 3-letter mnemonics, e.g. int, dbl, str. But I seem to prefer single letters in ME, presumably because you always have to type the full name (whereas VB has all sorts of IDE tricks to avoid having to type stuff in).

Did you ever purchase the PGM Library? I wrote a set of functions, invoked by a hotkey, which would do this and more: - you can time the entire macro currently being edited - you can time an entire macro from Explorer - you can time any subset of selected contiguous lines within the currently edited macro Its precision is milliseconds.

Why write your macros for such a small minoritry group? The population of North America accounts for just 4.536363490514687% of the world! Most people definitely don't use such a silly date format as mm/dd/yyyy!

But why are you converting to decimal? Date/time variables support arithmetic. Displaying a date/time variable displays a readable result. And if you set dtv1 to now, dtv2 to now + 7 seconds, dtv3 to dtv2 - dtv1, and display all 3 variables, you get 30/12/1899 00:00:07 as the value of dtv3 (which confirms that MEP's starting date and time is midnight on 30/12/1899). MEP lacks quite a lot of date/time functions, e.g. DateDiff which would allow you to return the difference between 2 date/time variables in a time unit of your choice (days, hours, seconds, etc.). So, in order to make your function work, I'd do as follows: Use date/time variables to record your start and end times Subtract start time from end time into a 3rd date/time variable (dRes) Convert dRes to decimal (eRes) Convert result to seconds (eRes * 86400) into a decimal variable (eResConv) Truncate eResConv to integer (nRes), OR round eResConv to integer (more complex) nRes should not hold your answer (in seconds) I haven't thought about this too much, so there may be a more elegant solution.

Sorry, I should have made the context clear. I was talking about documenting a macro for myself only. If documenting for other people, then I agree 100% with JohnS.

The number of days and part days since some particular starting point - usually something like Midnight on 1st January 1900. This is a very standard way to represent time. Microsoft itself can't seem to agree on a universal starting point! Sometimes MS uses 1/1/1900, sometimes 1/1/1901, and sometimes 31/12/1899, depending on the product you're using.

This has produced a bit of a can of worms! 1) Right-clicking a macro and selecting Run Macro Now does update the Last Run Time, but only after I select the macro properties and change one, e.g. The macro is enabled 2) Right-clicking a macro and selecting Run Macro Now does not update the Last Run Time if I then right-click the macro and select Disable Macro, followed by Enable Macro 3) Running the macro with the Macro Run command in another macro does not update the Last Run Time if Wait for this macro to terminate before proceeding is ticked 4) Running the macro with the Macro Run command in another macro does update the Last Run Time if Wait for this macro to terminate before proceeding is unticked (but only after changing a property as in 1 above), which is what I expected

For registry names, there don't seem to be any naming standards that I've ever spotted. Given that you are not going to use these registry keys and values except from within your macros, I think the name immediately below the top level is the most important, so that you don't accidentally delete it and can easily remember what it signifies. Thus something like HKCU\TerryMEP\... is probably sufficient (and I'd exclude "Terry" if you're the only person doing this). Below that level, you might want to consider using "application" names (by which I mean a name describing which macro or set of macros), but probably only if you intend using many registry keys across a number of macros. Our PGM Library uses a section name "Professional Grade Macros", and subsections like Parameters, Pgm Functions, Swap, Variables, etc. I also like to use naming standards for my variables; %t...% for text variables, %n...% for integers, %b...% for boolean, etc., followed by as meaningful a name as possible (but shorter rather than longer) using camel case, as in %tFirstName%. I think this makes the macro a little clearer, and I'm all in favour of "self-documenting" code rather than copious comments littered throughtout the code.

I tried this in XP (a VMWare sesssion running under W7), and it worked perfectly! So let's call it a Desktop Null issue for JohnS' XP!!

Your macro will run whenever your Documents folder changes - which is probably very often. Since your .xlsx file (presumably?) still exists, Excel will be reopened again and again and again.... You need to find a way of informing the macro that you don't want it to run again on the current .xlsx file. You could use a different folder (one that changes infrequently, preferably under your direct control), OR you could change the .xlsx file's name once you've opened it once in Excel, OR you could store a value in the registry - but then you need to create a mechanism to erase the registry value when you do want the .xlsx file to be opened in Excel. I think you should change the file's name (or move it to a different folder) once you have opened it in Excel.

From Excel 2007 Help: "/e or /embed Prevents the Excel startup screen from appearing and a new blank workbook from opening. Example: excel.exe /e"

Sorry to disappoint you - but I dragged a file from a DOpus window to the desktop, and the macro was triggered.

Using Windows 7, where the Desktop folder is in C:\Users\username\Desktop, MEP's Directory activation feature works just fine. Mind you, this is a folder which usually has quite a lot of activity, so I'm not convinced it's a good target location for files!

I suggest you export the relevant Firefox keys in the registry to a .reg file which you can then simply double-click to add back into the registry when a new version arrives. As far as File Associations are concerned, you've got a real treat in store for you when you migrate to Windows 7. Many of the things you could do fairly easily in XP (e.g. all that horrid DDE stuff) appear to have disappeared from W7, though there are some 3rd party utilities that can help in this regard.

Yes, MS, in their wisdom, changed this behaviour in Excel 2007. So what you report is correct for Excel 2000.

Are you sure? If so, you must be using a very old version! I strongly recommend upgrading to the latest version of ME3.

On my machine (Windows 7 Professional x64), if I have Excel open using File1.xls[m], and I double-click in Explorer on File2.xls[m], then a second instance of Excel is started. If I open File2.xls[m] from a command prompt, exactly the same behaviour occurs. In fact, if you do a Google search on excel open instance you will find many topics describing exactly the problem you experienced, where a second instance of Excel is always opened. So I don't understand how you manage to open a second .xls(m) file in the original instance of Excel. Just to clear this up completely, if I run a Macro that opens text files in my editor of choice (UtraEdit), then only a single instance of UltraEdit is run (as defined in my UltraEdit preferences).

You don't say which version of Excel you're using. Excel's behaviour appears to have changed in recent versions (e.g. Excel 2007), so that double-clicking on an Excel file causes a new instance of Excel to load, even when Excel is already open. Below is a description of a macro to launch and activate Excel if it's not already running, or to use Excel's Open File dialog to open the desired file if it is. Here's how to solve the problem, assuming that the Excel file you want to open is stored in %tExcelFile%: If Program "EXCEL.EXE" is running Window Activate: Microsoft Excel Text Type (Simulate Keystrokes): <CONTROL>o -- opens the Open File dialog Delay: 500 milliseconds Text Type (Simulate Keystrokes): %tExcelFile%<ENTER> Else Launch Program and Activate Window: Program "EXCEL.EXE", Parameters "%tExcelFile%", Window "Microsoft Excel" End If

Sorry not to have responded earlier - I've been away. The above command is testing for a zero-length string, not a null string, nor an empty string (whatever that means). %tVar% = "this" The variable tvar contains a string of 4 characters. %tVar% = "thi" The variable tvar contains a string of 3 characters. %tVar% = "th" The variable tvar contains a string of 2 characters. %tVar% = "t" The variable tvar contains a string of 1 character. %tVar% = "" The variable tvar contains a string of 0 characters. Your If Clipboard command will return True to this, and only this, string (assuming this string is currently in the clipboard). As far as ME is concerned, forget about the word null, as it has no meaning. And the term Empty is not at all useful. String variables in ME always contain a string. The string can be from 0 to ? characters (I don't know what the upper limit is). Integer variables always contain a number. That number is 0 if the variable has not yet been used. Does that help? As far as Textpad is concerned, it looks as if it may append a linefeed (represented by Ascii13 followed by Ascii10) to a zero-length string on the clipboard. or perhaps it always appends CrLf to the last character in the clipboard. You should be able to establish that fairly easily.

What's wrong with \Windows\System32\Charmap(.exe)?

Yes, I must say I have not experienced the molasses problem with the latest release. Though I did have problems yesterday. I'm writing a macro which solicits the user for a folder, then types each fully qualified file name into a file common dialog box belonging to a 3rd-party program, followed by ENTER. During development I omitted to insert any delays, resulting in the fully qualified file name being entered without a drive letter, as in ":\dvds\VobOutput1.mpg". This caused the 3rd-party program to issue an error message, which my macro hadn't allowed for. The result was our old friend Molasses, but where I could only press Ctrl-Alt-Del and logoff to recover. I don't think it's worth reporting at this stage, since the addition of a 250ms delay solved the problem.