paul

I don't think this is true. A program can exist without any windows, so I suppose it follows that a program can be active while a window from a different program is active.

ME v3 doesn't support this at all. Neither does MEP, except that it can provide the structure to allow such a facility to be developed (I have constructed exactly what you're after in MEP - it runs to 39 macros (1 macro for each keypress I potentially want to be able to monitor - all of which are identical except for the keystroke they detect - and 3 control macros).

Wait until the app's window opens, start Task Manager, use the Applications tab, right-click on your app's window name and select Go To Process. No, but, under Windows 7 Professional, I do have this scheduled event, which runs when I awake the machine from standby: - Trigger: On an event - Log: System - Source: Power-Troubleshooter - Event ID: 1 Using this scheduled task, I can, of course, run a macro if I want.

Would activating when process starts running work in your context?

Why is your loop so slow? Within each iteration of the loop: - you are doing a text box display and close - you are doing a Window Activate and Wait For Window - you are doing a Wait for Mouse Cursor - you are extending a selection of cells instead of selecting the start and shift-selecting the end cell just once And it doesn't run reliably on my machine, probably because you are typing stuff too quickly for the macro to react properly. You could rewrite this macro to remove the loop and do your operation just once, as in: - solicit the number of cells you want to select - click on the 1st cell - move to the last cell - do a shift-click There are even better ways to do this using Excel objects and methods, but it shouldn't be necessary to use that approach here.

I must have missed something! He said earlier he was using the text type command and since my code is also using the Text Type command, it looked straight-forward to me.

Try outputting in 2 parts. This works for me: Text Type (Simulate Keystrokes): cd % Text Type (Simulate Keystrokes): windir%

My pleasure! It's no nice being thanked!

I recommend that you convert your start and end measurements into seconds (for simplicity, use the beginning of the current year or month as your zero point if you don't need to handle overflows), do the subtraction and reconvert into your desired output format.

Request a feature

Easiest for you perhaps? Certainly not easiest for Insight, and entirely unnecessary. Simply create 2 scheduled macros according to your criteria above, then have the body of logic in a 3rd macro that is run by either of the other 2 macros. I wish you'd stop making facile requests for features that are unnecessary, and which appear to be of interest only to yourself. In any case, this isn't the place for requests for new features - Insight provides an alternative method for this, if you could only take the time to discover.

I don't think you understand how a scheduler works. A scheduler is designed to initiate a specified task at its first appointed time, then reschedule the task so that it will be able to run at its next appointed time, if relevant. Once the task has been started [and rescheduled], the scheduler has completed its job. It does not hang around, waiting for the task to complete and report back its success or failure. Once you understand that, then you can see that a task is therefore either to run once only, or to run repeatedly at various intervals. If the task is to run once, then that task's next run time is Never. In the case of Windows startup tasks, they are presumably scheduled to run each time Windows boots, and it is the task's responsibility to "delete" itself when it has run successfully. In your particular case, the job failed and so remained to be run again next time Windows was restarted. And if you think about that strategy for a moment, then you will see that the key requirement for the chkdsk task was to complete successfully, because until that happened, there was no guarantee that your disks were in good order. In the circumstances you describe, you really have no idea what state your disks are in because of that recurring BSOD. For the continued health of your system I really think you need to get to the bottom of that issue and resolve it properly.

Really? Have you looked at the Windows (7) Scheduler? You can schedule tasks to run even when the user isn't logged on (try that with MEP and see what happens ), there's a plethora of events you can use, etc., etc. As I said, it's far more powerful than MEP's, but, for the most part, I think MEP's scheduler is adequate for its purpose.

I disagree with you about what I expect of a scheduler. IMHO, a scheduler should be able to schedule programs according to various date/time criteria. Once you start examining specific files for their dates and times, you should be processing that logic in a user-written program. The Windows scheduler is much more sophiticated and powerful than MEP's, and includes the ability to turn on a sleeping computer.

You can always use Windows' bult-in scheduler (which is far more sophisticated than MEP's) to fire off macros. I'll leave you to take a look at all the things you can do with the Windows scheduler - the command line you require is: "x:\Macro Express Pro\meproc.exe" /AMyMacro where: - x: is the fully qualified name of your Programs folder, e.g. C:\Program Files, C:\Program Files (x86) - MyMacro is the macro name of the macro you wish to run Of course, you won't need to include in your macro any of the date stuff, though you will still have to compare the file year and month with today's year and month.

Below is the outline of a macro that should solve your problem. I have assumed you know MEP sufficiently well to turn it into real code. This macro is activated via ME's scheduler: - Schedule it to run each day at 9pm - Tick the box "If the activation was missed, run at the next available time" (if the computer is off at the appointed time, when you next turn on the computer, the macro should run) Macro Outline - Get today's date in a text variable using format mm (tMonth) - If tMonth is neither 03 nor 09, exit the macro (note the leading zero as we are dealing with a text variable) - Get today's date in a text variable using format dd (tDay) - If tDay is more than 07, exit the macro (note the leading zero as we are dealing with a text variable) - Get today's date in a text variable using format yyyy (tYear) - Convert tYear to integer (nYear) - Get today's date in a text variable using format mm (tMonth) - Convert tMonth to integer (nMonth) - Get the file's Modified Date/Time Month and Year only (nFMonth and nFYear) - If nYear equals nFYear AND tMonth equals nFMonth, exit the macro - Display your reminder message Notes - I have kept this macro simple so that it does only one thing at a time (for example, we could have retrieved Today's Date only once and then extracted the various substrings needed). - Names in parentheses simply identify specific variables used in the following line, where the first letter of the name identifies its type, e.g. t for text, n for integer. - This macro will run each and every day, and takes an imperceptible amount of time to run, even when it displays its reminder message (only on 14 days each year). - If the computer is not switched on at 9pm, this macro will not run: instead, it will run when you next start Macro Express. We could make this more sophisticated and have it turn on your machine at 9pm each day, but that would involve using the Windows scheduler; however, if your computer is off at 9pm on the 7th of March or the 7th of September and you don't turn your computer back on until the next day, this macro will not display any reminder for another 6 months. - You can make your message as bright and loud as you like by using colours, fonts, etc.

I'm slightly confused by your points 2 and 3: Does this macro run only for the first 7 days of May and September at 9pm, or does it run until the specified file has a current date? Also, May and September are not 6 months apart! And the macro will not be able to determine when you die, either in advance or after the event !

Questions: 1) What operaing system do you run? 2) Do you cause your computer to reboot each day? By this I mean you don't hibernate or standby your machine, or have it on all the time. What I want to find out is whether you start Macro Express each day, or whether it's already running when you start up each day (e.g. because the machine wakes from hibernation). Depending on your answers, a good solution might be to have a startup macro that runs each day which handles all the logic needed to achieve your aim.

Well, quite honestly Kevin, anyone who uses MEP actually to develop their scripts is not going to be doing anything very sophisticated or complex! How on earth would one seriously set about debugging such scripts? The very idea beggars belief! IMHO, the syntax hightlighting feature of MEP is almost irrelevant, and certainly not worth going to the trouble of incorporating a scripting language for.

Still not sure about your conclusion. Admittedly I'm not running loops 100000 times or more, but IMHO AutoIt, for example, is very fast and not compiled. I suspect all you're really saying is that, for the most part, MEP is really very slow (much slower that ME3). Well, which are you? An axe murderer, or a chainsaw specialist? Surely you're not both?

I never noticed! That's the 2nd time you've mentioned the word "compiled". I'm not sure about this one - you do realize that .Net technology doesn't really compile anything, it just converts user code into an intermediate stage, ready for the JIT (just in time) "compiler" to take over at runtime? I don't notice any difference between running AutoIt .exes and AutoIt scripts, but then I'm not running heavy number-crunching stuff.

You may very well be right. If so, that surely begs this question: what on earth is the point of includng the capability to run HTA scripts in MEP's External Script command? What advantages are provided over simply running the HTA via the Launch Program command? If none, then it ought never to have been included, don't you think?

As we all know (by now, at any rate ) MEP has a command "External Script" which allows scripts written in one of JScript, VBScript, HTA/HTML, AutoIt to run and return console output which MEP captures in the "Save console output to:" variable. I don't think it's unreasonable to expect ISS to know how to fully use each of these scripting languages without having to resort to workarounds in order to get this feature to work properly. Yet it appears that I expect too much, as no-one seems to have any idea whether HTA scripts support this, and, if so, how to accomplish it. I'd hope that ISS could provide workarounds in those cases where there is a bug in MEP. But in this case, we don't know whether there is a bug or not, because we haven't yet got to the point where we have anything to test. And what would be the point of including HTA in the list of supported scripting languages if we can't after all integrate it into MEP. All that has been suggested so far is different in no useful way to running an HTA script just like we did with ME3, i.e. Launch Program and Activate Window: Program "xxx.hta", Parameters "", Window "windowname"

Nobody denies that Joe's code works in MEP - I don't believe that's the issue. In what way does Joe/Floyd's code help to resolve the issue of how to get HTAs to write to the console? I thought I'd explained above how that code works, by creating ME3 macro code that then can be run using the Load Macro Text File command? Have I missed something? I believe the original author wants to have the HTA write/echo text to the console which is then returned to MEP via the "Save console output to:" facility in the External script command. How does Joe's code assist in that exercise? Please clarify.

No, what he did was quite different (and written for ME3). His HTA code created ME3 code, so he could write a command as if he'd used the Direct Editor to populate a ME3 variable with a vbs variable, as in: strOutput = "<TVAR2:11:01:" & strFirstName & Chr(01) & ">" then he wrote the variable strOutput to a text file which he then ran in ME3 by using the load macro command. As you can see, this is entirely different to what is needed in MEP. Joe's code is not at all relevant.