chris

The If-End If blocks would work the absolute best. However, we also have Goto-Label commands for this, as well.

Thanks for clarifying that, Paul. That was one of the design decisions we had to make when developing the new variable system. In the end, we decided to use strongly-typed variables in order to maintain efficiency (variants are actually very much discouraged by Microsoft, even though they do allow them). Now, as for the variable creation, if you allow MEPro to prompt you for each variable, you will be given a selection of allowed variable types for each variable. It's not always going to default to text variables (for instance, in a "Variable Set Integer" command, the text variable option will not even be available). But, when using the automatic creation MEPro has to make a guess as to what type of variable you were wanting. In the case where the "TextBox Display" command is used, all variable types are supported, so we default to the text variable type as it's the most often used type of variable in that command. We are currently looking into ways to make the automatic variable creation a little more friendly.

MEPro is supposed to be getting the 12/24 hour format from the OS. At least, whenever we test it it works fine. The tricky part is picking that up if you switch time formats while ME is running. Is that what's going on here?

I'm sorry about that. Yes, I'm still trying to locate the problem.

So, I've been looking into this today (the bug, not the report) and I can't find a reason for it. Using the script example from the post #4, I had it properly locate iTunes and activate it. I looked through the source code, just to be sure, and it looks like everything is being called correctly. However, please be aware that this was not the case several builds back. I can't remember which build it was, but the parameters to a function call were reversed, causing exactly what you were seeing. However, if you're using 4.1.7.1, then it should be working correctly. So, if you have "partial" selected and "use wildcards" unselected (as is the case with the code in post #4), then it's fixed in the latest build of MEPro. So, I know that this is an obvious (and perhaps dumb) question, but could you please make sure that you're running MEPro 4.1.7.1 and iTunes 10.1 (which I tested against)?

Sorry. I missed that. My bad.

Thanks for the information. Which version of Windows are you using? I want to make sure I test against it to verify the issue. As for "exact vs partial", I did see that and I'm looking into it.

Cory, please disregard my request for a test file. I created a 61265 line file totaling approximately 4.08MB. The original split string command took forever, just as you noted. I played with it this morning as my fix yesterday did nothing to speed up this particular command. As of right now, I am now able to split the file in just under two seconds. I found that loading the text file into memory twice (so, in RAM it occupies 8.16MB instead of 4.08MB) gave me a significant performance boost. Of course, that memory will be freed as soon as the command finishes. Now, I just have to optimize it when using the debugger (when used in the debugger, the original, significantly slow, speed is still retained).

I'm looking into whether or not I can speed this up. I'm actually surprised to find that the disable works faster than the enable because they're actually the same block of code executing. Specifically, the code looks like this: if( (macro.currentCommand() = scEnableMacro) and (mac^.flags and mEnabled = 0) )then mac^.flags := mac^.flags or mEnabled else if( (macro.currentCommand() = scDisableMacro) and (mac^.flags and mEnabled <> 0) )then mac^.flags := mac^.flags and (not mEnabled); The speed problem may be related to some synchronization code we have to keep the macro threads from interfering with each other (we need to use that in this area to keep multiple macros from writing to the macro file simultaneously). This is something we didn't need to do in ME3 because of the lack of simultaneous macros. It is a potential slowdown. Another possible cause of the speed problems could be that we have to reload the menus. We did this in ME3, but again, we have to synchronize the file access. One question, though: are the macros contained in the same file that contains the macro that is enabling/disabling them? Or, do they exist in a separate macro file? If they are in a separate file, that would definitely account for the speed difference as MEPro would have to open the file, enable/disable the macro and then close the file. But, if the file was already open in the explorer, that operation wouldn't be executed. I'll take a look at this today.

It may or may not be a bug in the Wait for Window Title command. I won't dismiss that possibility. However, let's look at one thing, please. What version of Windows are you using? I ask because in Vista and 7, the window titles are no longer visible. As such, it's easy to get the wrong title. In Windows XP and earlier, if the folder window had the explorer treeview on the left side, then the window title would contain the full path. But, if the treeview was not visible then the window title would contain just the name of the folder you're looking at. In Vista and 7 the treeview is always present, so you would think that the window title would contain the full path, but it doesn't. Instead, you need to change your "Wait for Window Title" commands so that they're not waiting for an explorer window with the full directory path in the title. This will also affect the "Window Move and Size" command as there is a central function that we use to locate the windows by title. So, try changing your "Wait for Window Title" and "Window Move and Size" commands in this example to "MAGIX Exports" (without the quotes). I'd be interested in knowing if that fixes things (assuming you're running Windows Vista or 7). If that doesn't fix things, then I'll gladly look into whether there is a bug there or not.

I think so. What I was testing against was a text file that contained a large number of percent signs. Actually' date=' the test file I used was 1.03MB of just percent signs (with a few 5s thrown in for good measure). It was taking upwards of 30 minutes to process the "Variable Set String from File" command just because the variable processing was having a difficult time working through all of those percents and trying to extract the contents of non-existent variables. After my change, the time decreased to just under a second. So, if your text file that you're doing a replace all in contained a fairly large number of percent signs, then yes, it will increase the speed. However, I would be willing to test your file out and make any corrections to the program that are necessary to increase the speed there, too. You have no idea .

Not at this time. Sorry.

I actually just implemented a fix for this yesterday as we're finding that if a clipboard monitor is in place, the clipboard is not always "redrawn" properly. Apparently Microsoft's documentation concerning clipboard monitors is incorrect, so I've written up a slight modification to our monitor to "fix" it so that other programs aren't affected.

I am very familiar with this particular issue as it's caused us a lot of grief since Microsoft started implementing this back in Windows 2000. Essentially, the idea is that a program should not come up into the foreground unless you started it from Explorer (i.e. the start menu, an explorer window, etc.). That way your workflow is not interrupted when a background program launches another program. Since Windows 2000, each version of Windows has a slight change to how this is implemented. We have some code in place to work around this, but it's not always 100% perfect. Add to that fact, Vista and 7 added an additional quirk with the thumbnail previews of windows when you hover over their taskbar entries. In this case, the preview window is not marked as hidden and it has the same name as the window you're previewing. So, when we go to do our activation code, Windows will sometimes give us the preview window instead (most likely that's where your activations are going). One way to get around this is to follow up your launch command with a "Window Activate" command. We've found this to be the most reliable solution as it gives Windows a moment to finish cleaning up after a program launch and then give us the correct window handle to activate. Could you try that and let me know if it works any better?

You may be pleased to know that we found the performance bottleneck. Apparently it was all in the variable processing routines. Specifically, there were more memory allocations and deallocations occurring than we really needed. This wasn't a problem in ME3 because the version of Delphi we used was for that version was faster at these memory allocations than the current version. Case in point, in MEPro 4.1.7.1, if you load a 1.03MB file containing all % symbols, it was taking more than 30 minutes to process (much like Cory reported above with the split string). In my new test build, it took under a second. Since all of the commands run through this particular function, this most likely accounts for much of the performance problems everyone is experiencing. I think the main reason it's not more widespread is because most people are using smaller datasets and thus don't notice the issue as those who use much larger datasets. As such, Cory, could I trouble you to send me a copy of the file that's causing the split string slow down? I'd like to make sure that this fix will work for that particular function, too. And, if it doesn't affect performance in this area, I would like to be able to find a proper fix for you. I do apologize that it has taken this long to find the problem. I will do my best to make sure that situations like this don't happen again.

I can say for sure that the version of Delphi that we're using is MUCH slower at anything requiring memory allocations than previous versions of Delphi (but those versions of Delphi have significant bugs, too, which is why we upgraded). We are looking into ways around this. I may have to start preallocating memory and just reuse it (like the Linux OS does for its apps).

Actually, Delphi does not have any split string utility (though it would be nice if it did), so I had to write it up myself. Also, unfortunately, the version of Delphi we're using is much slower with strings than the version we built ME3 in, which accounts for most of the slowness. I'll see if I can optimize my code a bit. This is one time (of many) when I wished we had used C/C++ to write MEPro because the speed would have been much better as there are things like this built into the language.

One other thing to look at is that you have spaces in the variables field. For instance, your destination for your first Variable Set Integer command (on line 9) is " %PIXEL%" (without the quotes). This is what is throwing Macro Express off. I'm making a change to make it more fault tolerant of this particular situation. But, in the meantime, if you make this change, it will work much better (and only create one copy of the variables during a save).

It could be related. Are you running it on the same computer?

When using the external script command, we use a function called WaitForSingleObject to query whether the process has completed. In this API call we pass a time value, which is the maximum time to wait before the function exits. We have the option of using either milliseconds or a value called INFINITE (which means the function waits indefinitely before returning control back to Macro Express). The problem with this function is that it's not 100% accurate when waiting for a process handle when using the INFINITE flag. Experience (and a lot of web searching) as shown that using the INFINITE flag while waiting for a process handle will cause the app to lockup as the API call will not return control to Macro Express. So, we coded in a 1000 millisecond wait time. If the function was not successful (meaning the process is still running), we immediately run the function again (with no delays in between except for the normal overhead caused by threads and API calls, which is on the order of microseconds, usually). In theory, the 1000 millisecond delay is an upper-limit (at least, according to Microsoft), meaning that the function will wait at most 1 second for the application to terminate . This is the only delay we have in that particular block of code. So, if you're seeing a delay, either the WaitForSingleObject API is misbehaving, or the code to read from the data stream is taking longer than it should (again, the only delay here should be the standard API overhead). Are you outputting a large amount of data through the script, or is it just a few characters?

John, you'll find that a lot of programs use hooks, either locally or at the system level. When we upgraded our menu control components that we use in ME3 and MEPro, we found that the components installed their own hooks that caused problems activating our macros within our own program. Adobe Photoshop uses hooks in such a way that they completely bypass our ability to capture mouse movements within that program. On Windows XP there was a program that you could use to find all the hooks throughout the system and what program created them. I wish Vista and 7 still had that because there are now so many programs that do so.

Terry, could you export and post a copy of the macro that's giving you problems? I want to take a quick look inside it because we're not able to reproduce the issue. As for needing to restore the hook frequently, it would have to do with whatever software is running on your computer. The only time this is needed is if there is another program which is hooking the keyboard and not forwarding the necessary messages back down the hook chain. Restoring the hooks pulls Macro Express out of the chain and then puts it back at the top so that it gets first priority. If you need to keep doing that then there is a program that is doing the same thing automatically. The auto-restore hooks feature should work when you switch between windows. When a window becomes focused, Macro Express will pull the hooks out and put them back on top. But, if you have another program interfering with the hooks, then I can see why that isn't working very well.

@terrypin: The visible/hidden tabs are for your convenience only. When Mike originally wrote Macro Express, he included invisible windows in a lot of the functions. Unfortunately, Mike passed away several years ago, so I don't have the option of asking him why he did that. So, we maintained that in Macro 3 and Pro (it's never good to just change functionality without providing a backwards compatibility path). We added the tabs because people were confused why there were so many windows listed when they couldn't see them. But the underlying functionality has remained the same. So, in answer to your question: I'm saying that that was never true. It's been that way since before I joined the company back in 1999. As for the scope, after typing my previous post, I went through the code, just so I could see if there were any problems with picking up non-existent windows. When we search for a running window, we ask Windows itself for a full list of the windows. The OS takes a snapshot and returns that to us, which we then store, temporarily. The program then runs through every window title in that snapshot and checks to see if it matches. If it does, then the macro is queued up for launch. The snapshot of running windows is then discarded. That way, we don't run into situations where we're looking at old data. The "program" option of the scope does the exact same thing, except it looks at the running processes instead of the window titles. The fact that changing the scope from Untitled - Notepad to Notepad.exe indicates that the code is sound as it runs through the same code, except for how the snapshot is acquired. So, we have a situation where Windows is telling us that some window title contains "Untitled - Notepad" somewhere in its title. This has become much more frequent with Windows Vista since the hint windows and taskbar preview windows get populated with the title of the window your mouse is hovering over. And, these windows don't get immediately destroyed when the program closes. Windows 7 is even worse about this. That's why I asked you to look at the hidden window list. Also, if you have the Macro Express editor up and the name of the macro contains the window title you're looking for, that can also cause it (because the titlebar of the editor contains the title you're looking for). This is a rather common occurrence. So, since I last posted, I've made a change to the program. On the window scope, there is a new option to include hidden windows (which is enabled by default for backwards compatibility). When you get the upgrade (which should hopefully be out soon), you'll need to go back into the scopes and turn that option on. I understand that viewpoint and don't think that I discount that. When we were developing Macro Express 3, we came across this situation. Specifically, we found that when we used the "Window Activate" command, we were activating hidden windows more times than not. We initially changed the code to only work on visible windows, but we found that there were many "big" customers who relied on the hidden window being activated (I think they knew for sure that that was what was happening), so removing that broke some things. So, we rewrote the code to give visible windows the priority by sorting them to be first in that snapshot I mentioned above. That way, it improved the reliability, but kept the Macro Express 2 customers happy. For backwards compatibility reasons, we maintained that in MEPro. I hope that explains the way things work. If there are any more questions or comments, please let me know.