Running Man in System Tray

[patgenn123]

Hello all,

 

I know there are still many bugs that ME Pro needs to work through. However, the most annoying one is the "running man" in the system tray.

 

I keep on having to reboot or kill to ME process in the Task Manager and start over because of how annoying it is.

 

Is there any indication as to when this is going to be fixed?

 

Pat

[Cory]

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.

[patgenn123]

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.

[patgenn123]

Cory,

 

I have the same version as you do. It's the most recent one posted-4.1.6.1.

 

Why am i having this problem?

 

Pat

[Cory]

No clue. Have you called ISS Support yet?

 

Also how do you know for sure you have no macro running. The last guy I helped with this inadvertently set a delay to 600 seconds instead of 600mS. When you hover over Forrest does he report any macros running?

[paul]

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.

[terrypin]

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

 

Same here - as per my several recent posts. It may be fixed for you, Cory, but not me!

 

--

Terry, East Grinstead, UK

[acantor]

After this happens, it might be helpful, once you are back in the Macro Explorer, to sort the macros by "Last Run Time." This might provide a clue as to what was happening when the system got stuck. For example, maybe a script activated by a control or window event was running without your awareness.

[terrypin]

After this happens, it might be helpful, once you are back in the Macro Explorer, to sort the macros by "Last Run Time." This might provide a clue as to what was happening when the system got stuck. For example, maybe a script activated by a control or window event was running without your awareness.

 

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.

 

--

Terry, East Grinstead, UK

[Cory]

It may be fixed for you, Cory, but not me!

Then the question is what's different between you and me. Oh, and all the other machines I work on. That covers Windows Servers 2000 and 2003, Windows 2000, Vista, 7-64. Are you running XP still? I can't imagine how that would make a difference though. In any case it should be documented and reported to ISS including the fact that not everyone has the problem.

[Cory]

I suggest you enable the global option in Preferences Playback > Log All Errors. This will cause a log entry at the beginning and end of the macro execution. This will log at least one entry regardless of completion. A very quick and easy way to determine, especially since by default all the log files are in the same folder which you can sort by modified date. If you find one that crashes and leaves Forrest running you can create a reproducible scenario for ISS to troubleshoot.

[paul]

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.

[Cory]

Last Run Time seems to work fine for me with the exception of the refresh problem. I can't find any way to get the times to update in the display without closing the explorer and reopening. But they are getting logged. If I right click the macro and run it works, if I use the macros activation it works. And if the macro is terminated or the macro crashes (use a divide by zero if you want to test this) the last runtime still gets updated. The only scenario it doesn't update is when I do a debug run from the Scripting Editor. And that's likely by by design as I can think of a few reasons one would not want to update in this case. Anyway that's the way it works on my machine.

 

Interestingly the modified date gets updated in the explorer.

 

Has someone made a bugrep for the Last Run Time refresh issue?

[Cory]

Here's something interesting. If one creates a one line macro with a pause, executes macro, closes the explorer, and reopens the explorer, all with the macro running, one will see the Last Run Time updated. IE MEP must update the last run time at or before the first line of the script which could be well before the time of a crash or cancellation. Might think of it as the Time of Last Activation.

[terrypin]

I suggest you enable the global option in Preferences Playback > Log All Errors. This will cause a log entry at the beginning and end of the macro execution. This will log at least one entry regardless of completion. A very quick and easy way to determine, especially since by default all the log files are in the same folder which you can sort by modified date. If you find one that crashes and leaves Forrest running you can create a reproducible scenario for ISS to troubleshoot.

 

I have that enabled but I misunderstood its function. I see I still have to add Log Errors commands to every macro. I'd assumed this was automatic.

 

--

Terry, East Grinstead, UK

[terrypin]

Has someone made a bugrep for the Last Run Time refresh issue?

 

I've just done so.

 

--

Terry, East Grinstead, UK

[terrypin]

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.

 

You're right, thanks. I hadn't realised you needed to close and re-open Explorer to see it. But, like Cory, I'd say that was a bug, and I've duly reported it.

 

Have the other quirks/bugs you identified in this post and which I reported now been fixed?

 

On an associated point, I think a more serious problem is the one I reported months ago, that all the data reverts to 'Never' when a macro file is reopened or restored from a backup. Apparently this is because it's stored in the registry for improved performance. Meanwhile I suppose the practical conclusion is to ignore the column entirely for serious housekeeping purposes. Or add a submacro to every macro to do it yourself, reliably.

 

--

Terry, East Grinstead, UK

[Cory]

I see I still have to add Log Errors commands to every macro.

That was not my understanding of it but I did a simple test and found that they behave differently even thought they sound like they should have the same effect. If I enable the option in the general preference it only makes a log entry on error. If I enable it in the macro (Miscellaneous tab) it logs the start and stop whether there was a error or not. So it would appear I had it wrong and you would have to enable the logging in each macro you suspect might be causing it. Sorry, not as simple as I thought.

 

I wonder if this has changed. I remember we had a big post about this in the past and I don't remember this difference.

[Cory]

Have the other quirks/bugs you identified in this post and which I reported now been fixed?

You know you could actually test some of these tings yourself instead of posting the question to get someone else to test them for you. Too me about 30 seconds. But the answer is that execution by Macro Run does not change the Last Run Time. Like I said before, it should really be called "Last Activated Time" as it appears to only update when the activation is triggered. And I'm OK with that. IE I don't think it's a bug. Terry you can't expect a program to do every little thing exactly the way you want it to work. As with every application or programming language you sometimes have to work around things to get the results you need. And it seems that things you consider atrocious and unpardonable failures are simply minor annoyances, if that, to me and many others. I agree either the wording needs to be changed or the function changed like you suggest but to me this is a 'as and when' kind of issue. And I can think of many other performance and reliability issues I'd rather have them fix first. Make your feature request or bug report and let it be. They'll get to it after they fix the other things. IE I don't think being a squeaky wheel is going to get you greased any sooner.

[terrypin]

You know you could actually test some of these tings yourself instead of posting the question to get someone else to test them for you. Too me about 30 seconds. But the answer is that execution by Macro Run does not change the Last Run Time. Like I said before, it should really be called "Last Activated Time" as it appears to only update when the activation is triggered. And I'm OK with that. IE I don't think it's a bug. Terry you can't expect a program to do every little thing exactly the way you want it to work. As with every application or programming language you sometimes have to work around things to get the results you need. And it seems that things you consider atrocious and unpardonable failures are simply minor annoyances, if that, to me and many others. I agree either the wording needs to be changed or the function changed like you suggest but to me this is a 'as and when' kind of issue. And I can think of many other performance and reliability issues I'd rather have them fix first. Make your feature request or bug report and let it be. They'll get to it after they fix the other things. IE I don't think being a squeaky wheel is going to get you greased any sooner.

 

What have you tested? All 4 of Paul's scenarios?

 

I particularly addressed Paul, as it was he that identified those issues, and so I thought he would be best placed to re-check them. Possibly using his original test macros. Although even Paul might have trouble doing that in 30 seconds.

 

And, as you're apparently taking me to task for implied laziness, I'll remind you that it was I who took the time to formally report those quirks. [iSS8361], 19th March 2010.

 

 

--

Terry, East Grinstead, UK

[Cory]

What have you tested?

The issue you linked to that macros do not update if run from another macro. Did you have other off topic posts in that other thread? I didn't re-read the whole thing, just the first message you linked to.

And, as you're apparently taking me

I don't understand how you can be confused as to who I was addressing since I quoted you in my post. And it took me 30 seconds to test. OK, maybe a minute. Just one line of code in any case. But if it took longer and it's something that's important to you I would think that to be all the more reason for you to spend the time to test it yourself. But perhaps you're talking about some other bug. But I followed the link in your post and that was the only bug mentioned in that post.

[terrypin]

The issue you linked to that macros do not update if run from another macro. Did you have other off topic posts in that other thread? I didn't re-read the whole thing, just the first message you linked to.I don't understand how you can be confused as to who I was addressing since I quoted you in my post. And it took me 30 seconds to test. OK, maybe a minute. Just one line of code in any case. But if it took longer and it's something that's important to you I would think that to be all the more reason for you to spend the time to test it yourself. But perhaps you're talking about some other bug. But I followed the link in your post and that was the only bug mentioned in that post.

 

Why not take a rest and then calmly read the relevant parts of both threads again, Cory, as you've obviously lost the plot so far!

 

Take "I don't understand how you can be confused as to who I was addressing." I didn't say I was! You seem to read a couple of words and then hastily assume the rest to suit your prejuidices.

 

--

Terry, East Grinstead, UK

[Cory]

Naw, I think I'm done with this thread.

 

I'd like to suggest you not continue this topic on this thread as you're way off topic here. Perhaps start a new thread or reply to the aforementioned and continue it there.

[terrypin]

As I described in this thread mouse commands seem to be implicated in a high proportion of the occasions when I get this problem (of being unable to stop a macro via either the running man or Scroll Lock + Pause).

 

 

In case it offers ISS any further help in isolating this irritating issue, since that thread, which was about mouse cursor commands, I've noticed that quite often it arises when testing macros that involve repetitive mouse moves in general, not just cursor commands. But despite a considerable time trying, I've so far still been unable to write a simple demo macro that does this consistently.

 

--

Terry, East Grinstead, UK