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.