chris

Could I ask something here? When using the window scope with the title of Notepad, could you verify that there are no hidden windows with notepad in the title? During the scope testing, Macro Express does not differentiate between visible and invisible windows and on the newer versions of Windows, it seems to keep hidden windows around that contain the titles of programs you have recently run. So, when a macro is firing that doesn't look like it's supposed to, could you please open Macro Express and bring up the window list (by editing scope > Add Window button) and look in the Hidden tab? I'll bet that you find a window title that will cause the scope to pass. @paul: During your repeat loop, did you have the "Ignore Case" option checked in the "If Variable" command? I only ask because it's not obvious from the code you posted. Also, in what way are you finding the window title activation to be unreliable?

Thankfully it turned out to be something simple. Also, I've already implemented the fix so that if an invalid character (such as a '/' character) is used in the destination variable, then the variable will not be used to set the default for the dialog. This will be available in the next release.

I've located the issue in this particular instance. It appears that the repeat loop is repeating, but it's being canceled the second time through by the dialog. Here's what's happening: The first time through, the browse dialog pops up and requests a filename. You then take that filename and convert all of the '\' characters to '/'. This part is fine. However, the second time the loop executes, the '/' characters in the path cause the dialog to fail (this is a failing on the part of Windows as this is dialog is not our creation). The reason why the '/' characters are causing it to fail is because we allow setting a default value for the filename prompt by initializing the destination variable to a filename. So, if you were to set %T[1]% in this situation to "C:\My Documents\Some File.txt", then the prompt would be set to the My Documents directory with "Some File.txt" in the filename field. So, one way to fix it would be to set a default value at the beginning of the loop, either by clearing the variable or by setting it to point to a folder and file that you want as the default. I admit that this isn't documented in the help file (and we'll get right on that), but it's behavior that was carried over from Macro Express 3. The other alternative is that we check the variable for correct information before using it as the default value (there isn't a way to force the dialog to not cancel when bad data is entered as it's built into the Windows operating system). We'll investigate this solution as well.

Thank you for letting us know. It turns out that this is a bug specific to x64 systems. We'll make sure that this gets fixed in the next update.

Well, that blows that theory out of the water. OK, back to the drawing board. Thanks!

If anyone is still experiencing this rather frequently, can you please try the following for me? Go to Options > Preferences and make sure that "Auto restore the keyboard and mouse hooks" is turned off and then apply your changes. I have a working theory that this might be the cause of the problem and I'd like to test out my theory.

Thanks for catching this. It appears that the problem was in our rich-text decoder. Basically, it was stuck in an infinite loop because it couldn't remove the rich-text code for the space in order to determine if it was looking at a variable or not. I've now got a fix in place for this.

Well, I did a bit of work on this on Friday (with no success), but I managed to get it figured out this morning (the weekend break probably helped). I believe I've managed to optimize all cases where strings contain large amounts of data. At least, Steve's macro is now operating as fast as ME3 (even with the Update TextBox command enabled in the loop). Now, for the geeky explanation (as requested): The problem is in the way that ME3 and MEPro differ in variable handling. With ME3, there were a fixed number of variables, so I just allocated a fixed block of memory for each variable. Then, when I wanted a string, I already knew exactly where in memory it was, so I didn't need to copy any memory, do any lookups, etc. With MEPro, there is an unlimited number of variables, each with a different name. So, when a variable is accessed, MEPro does a quick search through the variable tree, figures out what array index the user is looking for and finds the appropriate pointer in memory. However, due to the way the variables were implemented, this area in memory is rather generic. So, if you want to do a string comparison, it had to allocate a Delphi string variable and copy the memory into that location (Delphi is the programming language MEPro is written in). This is where the bottleneck is occurring (for smaller values, it doesn't make a huge difference. But, in the case of a multi-megabyte string value, it adds up very quickly). Now, with the change I just made, string variables are allocated in a separate region of memory as Delphi strings (this is what makes the whole thing faster). When a string variable is requested, MEPro now figures out what string it needs and simply does the comparison without the need to allocate and copy memory since everything is already in a Delphi string variable. Without the need to reallocate and free memory through a repeat loop, everything simply responds better. I hope that my explanation helps. In short, though, when the next build is released, macros that deal with huge strings, such as Steve's, should run significantly faster.

Due to some optimizations, MEPro can push the keystrokes out a lot faster. If they get to be too fast, the OS will drop some (that is what you're seeing here). The only way to fix it is to slow it down. By turning off the high-speed timer, you end up using a timer that has a resolution of 55ms (instead of some number of nanoseconds), essentially slowing down the text type rate. One other thing to try is to use a "Keystroke Speed" command and keep increasing the delay value until the errors disappear.

Also, try going to Tools > Pack File. The new data file can accumulate some cruft in it, which can cause a little bit of a slowdown. I'd like to know if that helps at all.

I'll look into the activation and scope sorting. The last runtime column shouldn't even be visible. Also, I'll double-check the find function as well. As for the two sort arrows, that's actually a function of the grid (and it's a third-party grid that we purchased from another company, so we didn't write it). What's happening is that the macros are being grouped by filename and that grouping sorted. This explains why the arrow appears on the filename column. The other sorting arrow is due to the sub-sorting on the column which the arrow appears over. So, really, the grid is being sorted by nickname (for example) within a sorting of the filename. I agree it's confusing, but I haven't found a way to turn it off, yet.

Thank you for pointing this out. I just made a change to the code to restore the menu builder when opening an additional popup/floating menu.

At the moment it's not possible. This is partly due to how Windows works. If you have two or more mice attached to your system (which I have done a few times in the past), there is no information as to which mouse is sending the movement and click events. As far as the user-level software is concerned, the events are simply messages being sent from the operating system. In fact, the only information sent is that an event occurred, what button (if any) was pressed and the coordinates where the event occurred. Keys are similar in that we get the key pressed and some information about the repeat delay, etc. I'm not even sure if it's possible to distinguish between hardware devices at anything below the driver level.

There's already a bugrep about this issue (it's what brought me over here in the firstplace). However, any macro that I can use to test the speed difference between ME3 and MEPro (as far as this particular command is concerned) would be helpful. I actually have a theory about the slowdown and if it is related to the "If Variable Contains" command, like Steve suggested, and I can noticeably improve its performance, I can apply that same fix throughout the entire program, which would be a good thing all around.

OK, I'm from ISS and I'm very familiar with how the "If Variable Contains" command works. I'm also in a position where I can fix it. First off, is there some way you can send me a test file (and let me know which of the above macros to use) in order to test this? I think I may know where the slowdown is. Also, how many variables do you currently have defined in your macro (as this can greatly affect the speed)? I'd like to get this resolved as quickly as possible. Thank you for your patience with us.

Sure thing.

Fortunately, it's only isolated to the "Timed Delay with no ability to halt" option of the "Delay" command. In order to obtain that kind of a delay, we use a system object called a "Semaphore" (which is a system object used for timers). The reason behind that is simply for compatibility since I can't ask Mike (the author of Macro 2.x) why he used it. Normally, this object is safe to use because most programs do not use it. But, in this case, AWC uses the exact same semaphore (specifically, the global, unnamed semaphore. I tried using named versions, but that actually caused some significant problems). But, what AWC is doing is they're not resetting its state, so when Macro Pro attempts to use the semaphore for the delay, the OS just blows MEPro's request off, thus causing the situation where there is no delay. Since this is the only global, unnamed object in use by MEPro, it's the only command that can be affected by another program. All other global objects are named, so unless another program is intentionally malicious, they won't be affected. This "effect" can be worked around by using any other delay option.

I guess I'm having some trouble identifying the problem. Are you using F9 in the script editor to duplicate this problem? Or, does it occur when you use the macro's activation (or right-click in Explorer and select "Run Now")?

Oh, and regarding the fact that the EnableAutodial doesn't occur in ME3: that's completely understandable. We don't query the OS for the network status at anytime in that version. It is a completely new activation for MEPro.

Never at any time did we say that it was scanning the macros. When you press F9 it scans the list of open windows. There can be a delay when querying these if a window does not respond to the message immediately. That is what you're seeing. It has nothing to do with your processor or the number of macros. And, the fact that it works the first time doesn't have any bearing on whether or not it will work a second time. It all depends upon what the running applications on your system is doing. Please trust me on this because I have profiled this (because I've experienced it myself) and the most significant delay occurs when the windows are being queried for their titles. The remaining code leading up to it has taken less than one second on a P4 2.4GHz machine. Now, I will revisit the code to see if I can speed up the querying a bit, but please believe me when I say that this is the problem.

Macro Express uses its own hook system to determine if the computer has been idle. If the mouse or keyboard hooks see any activity whatsoever (this can be caused by anything injecting keystrokes or mouse movements) then the idle time is reset. A lot of times there are programs that will inject an unused key into keyboard buffer to determine some state (we do this with the "Wait for Text Playback" command). Because there is a keystroke going through our hook (we cannot determine where the key came from at the hook level, btw) the idle time is reset and the countdown starts again. We chose to do this because there is no system command to determine "idle" time as Windows doesn't even have a definition for idle (is it no keyboard/mouse, no CPU cycles being used by third-parties, etc?). We are looking into this, but I would also take Cory's advice and start shutting down applications, just in case there is an application that is injecting keystrokes into the keyboard buffer.

When the program crashes do you get any kind of address or a callstack? I ask because it's useful to us in tracking down exactly what is causing the problem (as Cory said, it's probably a conversion problem). Also, for additional information, would you mind sending us a copy of the macro file you're using? A lot of times we can track down issues using the file a lot faster than following the error information.

We're addressing this as quickly as possible.

Well, fortunately this isn't a bug with MEPro. You can't compare the dialog with the test dialog in ME3 because it's not the same dialog. In ME3, when you hit F9, it brings up a text box where a macro can type into. In MEPro, the dialog that comes up is a list of all of the visible windows. The delay you're experiencing is due to the fact that MEPro is querying all of those windows for their titles. If a program isn't responding quickly then it adds to the delay you're seeing. You can turn off this dialog by going to Debug > Switch Focus. This will become unchecked and the dialog will no longer appear, making your test runs a whole lot faster.

Can I ask what window title you're waiting for? Also, are you using the "When opened" or "When focused" option?