stevecasper

What a genius! Thanks so much for giving this such prompt attention! I love you guys. But not in a weird, awkward-making way.

My first suggestion is to check the spelling of the macro in the "Macro Run" command. If there is any variation at all, the macro will fail. I've had this problem when I've changed the name of the target macro but forgot to change it in the Macro Run command.

Hmm, that's odd. I usually use Notepad, but I had Word open and chose to use it as a testing ground. After reading your post, I opened Notepad, re-did the Activate command and tried again. Strangely, my first run gave me this: Further runs gave me the desired results. So weird.

So, to make life easier, I have a code snippet that looks like this: <VARIABLE SET TO ASCII CHAR Value="13" Destination="%CRLF%"/> <VARIABLE SET TO ASCII CHAR Value="10" Destination="%T[1]%"/> <VARIABLE MODIFY STRING Option="\x07" Destination="%CRLF%" Variable="%T[1]%"/> Then I can just drop the %CRLF% variable into a text-type or combine it with another variable and voilà, insta-carriage-return. Except that it doesn't always work right. Take the following macro code for example: <WINDOW ACTIVATE Title="Document1" Exact_Match="FALSE" Wildcards="FALSE" _IGNORE="0x0006"/> <VARIABLE SET TO ASCII CHAR Value="13" Destination="%CRLF%"/> <VARIABLE SET TO ASCII CHAR Value="10" Destination="%T[1]%"/> <VARIABLE MODIFY STRING Option="\x07" Destination="%CRLF%" Variable="%T[1]%"/> <REPEAT START Start="1" Step="1" Count="10" Save="TRUE" Variable="%N[1]%"/> <TEXT TYPE Action="1" Text="Test%N[1]%%CRLF%"/> <END REPEAT/> If I leave it as "Use clipboard to paste" the macro ignores the %CRLF% altogether. If I change it to "Simulate keystrokes," I get a fresh new line with each "Test." I imagine it has something to do with the clipboard not knowing how to paste a carriage return... except that it should, since I can copy lines of text that have carriage returns in them and the clipboard pastes them just fine. What am I misunderstanding about this process? Or am I missing nothing and should file a bug rep?

Just 2 more cents: I occasionally use Modify String commands where I connect multiple variables together to create a [booming voice]mega-variable[/booming voice]. Example:' Imagine the following is part of a... mad-lib macro (or something): %T[1]%= "This is my " %T[2]%= "dog, " %T[3]%= "Argos. He's " %T[4]%= "an Australian Labradoodle." To build a mega-variable, I do a Modify String: %Modified% = %T[1]%%T[2]%%T[3]%%T[4]% Sometimes this works. Sometimes MEP fails to notice the opening % and prompts me to create a variable named something like: T[1]%%T[2] I've only seen it a few times, and it goes away if I separate the %% with a comma or a space, but definitely something strange going on with %s

Chris, here are a pair of files you can use to test. The "Mule" file needs to be renamed as a .csv (the forum wouldn't let me upload it as that file type). This file is only 188KB, so the MEP version handles it fast enough... the slowness becomes obvious when the text file gets into MBs. You may just want to do a series of copy/pastes within the .txt to increase the file size. ACH_Mule_File.txt ACH_Test_File.txt

Hi there, My first thought was "you're using an If Greater Than" comparison on a text variable. I didn't think that would work, but I just ran a basic test and it seems to be not a problem for MEP. So that's good. The next thing I noticed is that you're setting the Date/Time to %T1[1]% but then your If statement is checking against %T[1]% Very minor and easy to miss. Also easy to fix. Further tests lead me to conclude that this is the only problem with the macro.

Ok, I've been messing with your harvest macro all morning, and I really like what I've learned from it. You looked at the problem from a much clearer perspective than I had, and took an approach I had looked at but tossed aside as too complicated... and you made it easy. I did have one problem right from the start, but it was an easy fix: ME doesn't like 15 digit integers, so I tweaked that early command down to 9 digits, and from that point the macro was smooth. But then I ran into a wall bricked out of my own denseness: Now that I have all these variables stacked %Counter% deep, what do I do with them? I came up with lots of options - everything from running a comparison on each processed line against the Mule file (quickly discarded as WAY cumbersom), down to simply adding a repeat loop at the end, set up to repeat %Counter% number of times, and create a whole new text file replete with the variables just created. When I was satisfied, I ran it on my 300KB text file. It ran fairly quickly (though not as fast as the If Contains via ME3), and looked beautiful and clean. Encouraged by this, I ran it agains a less modest 39MB file. After about 5 minutes, I killed it. I disabled most of the macro, just keeping the first part, searching for the 15 digit (9 digit) integer matches. I built a counter and set it up to give me a text box every 500, then I modified that to every 30,000. It took 11 minutes to pop up the 30K mark, and after about 22 minutes, it finally popped up 60,000. I then accidentally hit my abort key to kill another macro I was running, and incidentally shut down this one, too (oops). So this was taking too long to be useful. I don't know how many lines it was going to have, ultimately, but that 39MB file is nothing compared to the 250MB monster I had to check today (took just over 4 minutes with the If Contains in ME3). Now, there is a better-than-average chance that what I did wasn't anywhere near what you were expecting me to do. Because, let's face it, if we lived 5,000 years ago, I'd be the guy trying to figure out how you were able to make bronze from rock and sunlight. Oh, I got your email, I'll respond to it when I get home this afternoon. I think you are on to something.

Hi Chris, I do have a test file I can post here, but it's on my home PC. The files here at work are full of very sensitive information, but at home I built a macro that systematically built a 30+ MB text file that contains a lot of random number-series and letter sequences. A small fraction of those numbers and letter sequences match (by design) some mock-up account numbers, routing numbers, and client names in a .csv file that I also built through a macro. The .csv looks much like the one I'm using here at work, but the .txt file looks nothing like it. However it does contain exactly the information I need the macro to find via the "If contains" command. I don't know what the file-size limit is on this board, but I will post it here if I can, once I get home from work. If not, I'll cut it down until it does fit. Not including the built-in T and N variables, I have defined 11 Text Variables, and 2 Integer Variables. The ME Pro macro to use for the test is: <VARIABLE SET STRING Option="\x00" Destination="%MuleLocation%" Value="G:\\Loss Prevention\\ACH\\Mule Accounts.csv"/> <TEXT BOX DISPLAY Title="Find the Source" Content="{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil Tahoma;}}\r\n{\\colortbl;\\red0\\green0\\blue255;}\r\n\\viewkind4\\uc1\\pard\\cf1\\lang1033\\b\\f0\\fs24 Browse to the Source ACH file.\\cf0\\b0\\fs16 \r\n\\par }\r\n" Left="469" Top="50" Width="295" Height="73" Monitor="0" OnTop="TRUE" Keep_Focus="FALSE" Mode="\x02" Delay="0"/> <VARIABLE SET STRING Option="\x08" Destination="%ACHSourceFile[1]%" Value="Browse to the ACH SOURCE .txt File"/> <TEXT BOX CLOSE Header="Find the Source"/> <VARIABLE SET STRING Option="\x00" Destination="%ACHSourceFile[2]%" Value="%ACHSourceFile[1]%"/> <VARIABLE MODIFY STRING Option="\x0F" Destination="%ACHSourceFile[2]%" ToReplace=".txt" ReplaceWith=" " All="TRUE" IgnoreCase="TRUE"/> <VARIABLE SET STRING Option="\x00" Destination="%ACHMatchName%" Value="%ACHSourceFile[2]% Match File.txt"/> <VARIABLE MODIFY STRING Option="\x11" Destination="%ACHMatchFile%" Filename="%ACHMatchName%" CRLF="FALSE"/> <DATE/TIME Format="h:mm:ss AMPM" Flags="\x80" Date="12/30/1899" Day_Offset="0" Month_Offset="0" Year_Offset="0" Hour_Offset="0" Second_Offset="0" Left="Center" Top="Center" Monitor="0" Variable="%Start%" IsDateVar="FALSE" _IGNORE="0x0002"/> <TEXT BOX DISPLAY Title="ACH Checker" Content="{\\rtf1\\ansi\\ansicpg1252\\deff0{\\fonttbl{\\f0\\fnil Tahoma;}{\\f1\\fnil\\fcharset0 Tahoma;}}\r\n{\\colortbl;\\red0\\green0\\blue255;\\red0\\green128\\blue0;}\r\n\\viewkind4\\uc1\\pard\\qc\\cf1\\lang1033\\b\\f0\\fs24 The macro is running.\\cf0\\b0\\fs16 \r\n\\par \\pard \r\n\\par \\pard\\qc\\f1 Items processed so far:\\i \\cf2 %Processed%\\i0\\f0 \r\n\\par \\pard\\cf0 \r\n\\par \\pard\\qc Started: \\b %Start%\r\n\\par }\r\n" Left="469" Top="50" Width="290" Height="128" Monitor="0" OnTop="TRUE" Keep_Focus="FALSE" Mode="\x02" Delay="0"/> <VARIABLE SET STRING Option="\x03" Destination="%ACHTextContents%" Filename="%ACHSourceFile[1]%" Strip="FALSE"/> <ASCII FILE BEGIN PROCESS Filename="%MuleLocation%" Format="CSV" Start_Record="2" Process_All="TRUE" Records="0" Variable="%T%" Start_Index="1"/> <VARIABLE MODIFY INTEGER Option="\x07" Destination="%Processed%"/> <VARIABLE SET STRING Option="\x00" Destination="%T[4]%" Value="%T[4]% "/> <IF VARIABLE Variable="%ACHTextContents%" Condition="\x06" Value="%T[4]%" IgnoreCase="FALSE"/> <VARIABLE SET STRING Option="\x00" Destination="%MatchedClientInfo%" Value="%T[3]%, %T[4]%, %T[5]%, %T[6]%"/> <VARIABLE MODIFY STRING Option="\x12" Destination="%MatchedClientInfo%" Filename="%ACHMatchName%" CRLF="TRUE"/> <VARIABLE MODIFY INTEGER Option="\x07" Destination="%MatchIncrement%"/> <END IF/> <UPDATE TEXTBOX Header="ACH Checker" Content="{\\rtf1\\ansi\\ansicpg1252\\deff0{\\fonttbl{\\f0\\fnil Tahoma;}{\\f1\\fnil\\fcharset0 Tahoma;}}\r\n{\\colortbl;\\red0\\green0\\blue255;\\red0\\green128\\blue0;}\r\n\\viewkind4\\uc1\\pard\\qc\\cf1\\lang1033\\b\\f0\\fs24 The macro is running.\\cf0\\b0\\fs16 \r\n\\par \\pard \r\n\\par \\pard\\qc\\f1 Items processed so far:\\i \\cf2 %Processed%\\i0\\f0 \r\n\\par \\pard\\cf0 \r\n\\par \\pard\\qc Started: \\b %Start%\r\n\\par }\r\n"/> <ASCII FILE END PROCESS/> <TEXT BOX CLOSE Header="ACH Checker"/> <DATE/TIME Format="h:mm:ss AMPM" Flags="\x80" Date="12/30/1899" Day_Offset="0" Month_Offset="0" Year_Offset="0" Hour_Offset="0" Second_Offset="0" Left="Center" Top="Center" Monitor="0" Variable="%Finish%" IsDateVar="FALSE" _IGNORE="0x0002"/> <TEXT BOX DISPLAY Title="Finished" Content="{\\rtf1\\ansi\\ansicpg1252\\deff0{\\fonttbl{\\f0\\fnil Tahoma;}{\\f1\\fnil\\fcharset0 Tahoma;}}\r\n{\\colortbl;\\red0\\green0\\blue255;\\red0\\green128\\blue0;\\red255\\green0\\blue0;}\r\n\\viewkind4\\uc1\\pard\\qc\\cf1\\lang1033\\b\\f0\\fs24 The Checker has finished.\r\n\\par \\cf0\\b0\\f1\\fs16 Items processed: \\cf2 %Processed%\\cf0\\f0 \r\n\\par Matches found: \\cf3\\b\\fs24 %MatchIncrement%\\cf0\\b0\\fs16 \r\n\\par \\pard \r\n\\par Started - %Start%\r\n\\par Finished - %Finish%\r\n\\par }\r\n" Left="570" Top="Center" Width="278" Height="200" Monitor="0" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/> The ME 3 code to compare with and possibly use as a control in the test is: <TVAR2:14:01:G:\Loss Prevention\ACH\Mule Accounts.csv><TBOX4:F:6:000469000050000290000083:000:Find the SourceBrowse to the Source ACH file.><TVAR2:10:09:SOURCE File><TBCLOSE:Find the Source><TVAR2:15:01:%T10%><TMVAR2:21:15:01:001:000:.txt ><TVAR2:12:01:%T15% Match File.txt><TMVAR2:17:13:00:000:000:%T12%F><DT:h:mm:ss AMPMT:20:1:><TBOX4:F:6:000469000050000290000106:000:ACH CheckerThe macro is running. Started: %T20%><TVAR2:11:04:%T10%><ADFBEG:F10:001:000002:000000:%T14%><TVAR2:04:01:%T4% ><IFVAR2:4:11:7:T4><TVAR2:07:01:%T3%, %T4%, %T5%, %T6%><TMVAR2:20:07:00:000:000:%T12%T><NMVAR:08:01:0:0000001:0:0000000><ENDIF><ADFEND><TBCLOSE:ACH Checker><DT:h:mm:ss AMPMT:21:1:><TBOX4:T:1:000570Center000278000200:000:FinishedThe Checker has finished. Matches found: %N1% Started - %T20% Finished - %T21%> If this isn't exactly what you were looking for, please let me know! EDIT ACH_Mule_File.txt ACH_Test_File.txt I'll post these as a new reply to you, Chris, also. PLease note, the Mule File needs to be renamed to .csv (the forum wouldn't let me upload it as a .csv file).

Actually, you're probably not far off on a lot of this. However the "standard" variables are, as far as I understand them, no different from the custom variables in MEP. You can name your variable "T" or "TexasHoldem" and MEP handles them identically. As far as waiting for ISS to address/fix the issue... Yeah, that's probably what will end up happening, however, I'm learning a LOT about other functions in the mean time. I tend to get stuck in a rut thinking, "This situation requires the macro to do this..." Running into a road-block that forces me to find other ways to perform what should be a simple process opens doors for enlightenment. Sure, if the roadblock wasn't there, heading straight down the road would be the most efficient, fastest course, but I end up missing the challenge of cutting a new path, building a bridge, etc. which - though less efficient for going down the road - may be the most efficient course for something else I come across. Honestly, I probably will keep using the ME3 version of this macro until the developers (AKA real programmers) finish building the program they're working on that will do what this macro already does, only completely automated. Should only be another week or two. My macro is only intended as a "bandaid." Now to see if I can make Cory's macro work for me...

I've looked over the code you sent, and I have to say that I hadn't considered the exact processes you are using. I won't be able to test it till tomorrow at the soonest, but I promise to keep my hopes up. And if we ever meet in person, I promise to buy you a beer. Something cheap, though, I'm on an Eggos-for-breakfast, lunch, and dinner budget

hear hear

Yeah, just a couple of mid-range 17" Dells. We've only had them about 6 months, and we had to fight tooth-and-nail to convince the Power that Be that having dual LCDs would improve our productivity enough to be worth getting rid of the 15" CRTs we'd been using for who-knows-how-long.

My first thought is that it has something to do with windows stealing focus from each other. Something within your operating system is trying to prevent one or the other window from stealing focus. Of course, when it comes to that stuff, I'm pretty much just spouting off my own interpretation of something I read somewhere once. This does not constitute legal advice.

Ok Cory, Because I trust you, and because I think I've tried just about every possible way to weed out the unnecessary information that I can think of, I'm going to come right out and ask how you would do it. I've taken a small page from one of today's reports and altered account information and the name of the client, and I'm adding a screenshot of it here. The highlighted line contains the only information on this page that I would care to keep. The underlined information is the only information that would be pertinent to my macro. None of this information is uniform throughout the text document. Some lines will have the same Trace information for several lines, but then that will change suddenly. The macro scans through the text file looking for matches to the RFI Account No column. The way the macro is built it checks for the existence of the account number anywhere in the document, which results in false-positives when an account number is short and that sequence of numbers appears at the end of any of the other number-series within the document (the acct number is modified with a trailing space to eliminate matches in the middle of another sequence - no leading space is added, because some accounts may contain leading zeroes in the text document that are missing from the Mule). This is an abnormally short page. On most pages, the highlighted section would be 10-30 lines long. So, I'm curious how you would strip the extra baggage out of this file? I've tried setting Integer variables to positions of text that are the same throughout (such as the INFOPOINT at the top , which doesn't appear to change from page to page; and "TRACE" which appears before each section of accounts ), and then deleting everything within them. I've put it on a repeat and let it go. It worked great on the 300KB file, but when I attempted it on a 39MB file the I let it run for about 5 minutes before deciding this was not going to be efficient enough, since I can run the ME3 macro without distilling and have my results on that 39MB file in 41 seconds. 44 seconds if I run the beta version which removes a good chunk of false positives for me. -EDIT A note about false positives: They're not a big deal. Of the 548 accounts on my Mule file, I have to search for each and every one through all 5 text reports, however, on average less than 20 account numbers match even on the 100,000 page reports. The idea is to remove as many accounts from the list as possible prior to manual review. 20 accounts is much better than 548. My bosses don't care if there are 20 accounts or 5, as long as there aren't 548. But I'm occasionally very anal about this kind of thing, so I want to eliminate all the false positives I possibly can - but it isn't a priority.

I cheated, though. We're running dual monitors at work.

Cory, Thank you, as usual, for your input. I've thought about distilling the text file... but to be honest, some of these text files are over 200 MB in size, which translates to over 100,000 printed pages (according to the Citrix source file that the .txt is downloaded from). The process of distilling the file would take a number of hours, after which, I'd still need to make the comparison. All I need the macro to do is verify whether or not an account number appears at any point in the text file. ME3 is able to accomplish this in a fraction of a second (I calculated over 17 checks every second, actually), but MEP takes between 10 and 15 seconds to process just one file. To give a little more information about what is in the text file, there are bank routing numbers, account numbers, various other numbers (I don't know what most of them pertain to, could be anything from DL# to SSNs - they aren't specifically identified); client names; business names; transaction dates; etc. Each "page" is separated by a multi-line header and multi-line footer each with specific information regarding the banking transactions contained between the header and footer. The header and footer also contain numerous special characters used as separators and line-dividers. It's honestly a huge waste of space (some of the pages contain less information than the header and footer). Another thought on the distillation idea: In order to distill it, I'd need something to base the process on, but since the pages look an awful lot like this: (Just imagine that those are in columns that make sense... ) I don't really have any firm hook-point to look for. I could make it find the first integer after the "other stuff" section, remove everything between the first and second chunks of spaces, and I would have my account number and client name squared away, but again... this goes on for tens of thousands of pages with anywhere from 5-30 lines to distill on each page. And I'd still have to do it all within a variable. It's possible that I'm not fully understanding the processes you're recommending (you have way more experience at this than I do), so please forgive me if my density gets a little frustrating. By way of anecdote: Today I built a mock-up of a macro that does an ASCII process from my "Mule" file (as does the macro I'm actually using), but this one also utilizes a Text File Process scanning line by line through the .txt file. This was an attempt to eliminate false positives from my final output text file. I knew it would be ridiculous, so I only had it process 1 account from the "Mule". It took 1 minute 16 seconds. I calculated that it would take about 11.5 hours to process the entire 220 MB file I tested it on (548 accounts * 76 seconds = 41,648 seconds = 694.1333 minutes = 11.56888 hours). This would result in 0 false positives, which is a win. But half a terrestrial day would be used. The macro I'm currently running as the live 1.1 version processed that file in about 2 minutes and 50 seconds, with 14 matches. All false positives. A human person could then go through those 14 matches and eliminate the false positives in a matter of only a few minutes more. I'm waiting on approval to implement my beta 1.2 version that looks for account number matches, if matched, check for R/T matches. If match, check for Client first name match (long story why I can't use last name). If all three occur within the .txt then the account gets added to the output file. It reduced a 14 matches (via 1.1) to only 4 matches. Which were also false positives - verified manually within about 2 minutes. But it all has to be done with ME3 - a very fine program indeed - though I would really rather be able to utilize MEP, since it has so many more aesthetic and logical qualities to offer.

Ok, to test this problem, I first checked to make sure my mouse was programmed for "Middle Click" (the default is something else). Then I created two nearly identical macros: 1) One activated by Middle and Right Mouse-clicks, opens a Dialog Box centered on Monitor 0 that says TEST - Area: 0,0 and 2545,1023 2) One activated by Middle click only, which opens a Dialog Box centered on Monitor 1 that says test - Area: 0,0 and 2545,1023 At first, the Middle click was only launching the 1st macro, which it shouldn't have been doing at all. I disabled the 1st macro and ran the 2nd one a couple of times before re-activating the 1st. After that, they both worked as they were supposed to. Definitely a strange bug.

As a matter of fact, I just checked my email, and found this little beauty from our good friends at ISS: This issue has been assigned the tracking number [iSS7518] I was considering filing a bug report, just as you suggested... but they are on their toes over there. Gotta love it!

5 minutes 36 seconds. Decidedly slower than the ME3 version... but remarkably faster than when performed on my work PC. Of course the processing power of my home computer dwarfs the cybernetic dreams of my work PC... but I'm still not impressed with the 5 minutes 34 second increase over the ME3 design for this macro. Even at this much faster rate, the 220 MB file would take a half-hour, rather than the 3 or so minutes it takes running it in ME3... and I have to assume there would be a progressive increase in the processing time as the .txt gets bigger... so I could still be looking at 1.5 hours or more. ----- I modified the code to create a percentage-complete variable, and adjusted the Update dialog so it only changes if the % complete changes. Results: 5 minutes 36 seconds. Doing it this way made no difference to the actual speed that the macro processed the file. It's possible that my code was not perfect as I've never done this before... however, the code is good. I don't imagine a streamlined version of this code would make a world of difference. Here it is, in case you're curious: <VARIABLE MODIFY INTEGER Option="\x05" Destination="%N[1]%" Variable="%D[1]%"/> <VARIABLE MODIFY DECIMAL Option="\x03" Destination="%D[2]%" Value1="%D[1]%" Value2="549"/> <VARIABLE MODIFY DECIMAL Option="\x04" Destination="%D[2]%" Places="2"/> <VARIABLE MODIFY DECIMAL Option="\x02" Destination="%D[2]%" Value1="%D[2]%" Value2="100"/> <VARIABLE MODIFY DECIMAL Option="\x06" Destination="%D[2]%" Variable="%N[3]%"/> <IF VARIABLE Variable="%N[3]%" Condition="\x01" Value="%N[4]%" IgnoreCase="FALSE"/> <UPDATE TEXTBOX Header="ACH Macro Running" Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang1033{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs16 The macro is running.\r\n\\par \r\n\\par Start time: %Start%\r\n\\par \r\n\\par Percentage of Items Processed: %N[3]%\r\n\\par Matches Found: %N[2]%\\f1 \r\n\\par }\r\n"/> <VARIABLE SET INTEGER Option="\x00" Destination="%N[4]%" Value="%N[3]%"/> <END IF/> ----- I have just disabled two lines of necessary code, to try and isolate the slowness. I disabled the Set String command (wherein Ts 3-6 were saved to %MatchedClientInfo% ) and also the Variable Modify command where MatchedClientInfo was appended to the text file. I did this with the vague hope that the act of appending the text was what was slowing things down (though I knew it wasn't, since only a small percentage of account numbers will actually be matched; if this had been the problem, only those particular cases would have slowed the macro down). As it is, I'm down to two possibilities: The Process file is processing slowly, or the "If contains" is performing slowly. ----- I just disabled the Process file and replaced it with a basic "Repeat Loop" (creating dummy T3-T6). Result: SLOW as usual. I then re-enabled the Process file and disabled the "If contains" sequence. The macro smoked through in a heart-beat. I now have evidence supporting my conviction and no idea how to make that particular function move faster. Hence, I must stand beside my "MEP FAIL" statement, for the time being.

Cory, I'm flattered that you think I was a beta-tester, because frankly, I think that honor is reserved for folks who have shown ISS that they know generally what is going on. So thank you. I'm convinced that the slow-down is occurring during the "If variable contains" command. I don't have any quantifiable evidence supporting my conviction, though, so I'm creating a 30MB text file (on my home computer, now) in an attempt to duplicate my problem, and maybe isolate exactly where the problem is. You mention "dyno" macros, and based on my recollection of some of your previous posts, I believe you use that term to refer to sub-macros called by the main macro. Is that correct? I'm curious how you would implement such a macro to perform the function I'm striving for here. Also, I like the idea of using a percentage complete, rather than an exact number, and though it will take a little extra code, I can see how it would benefit my macro, by not updating the dialog box on every iteration. My PC has finally completed the production of a 33.7 MB text file full of faux account numbers and made-up names. I'll keep you posted on my results.

Hi jwood, I let this one sit there because I figured there would be more qualified people on the board to address it. Based on your example, I'd have to say that the only way to make it work would be to follow your "work-around" of click, capture, copy part, then ESC (or however you exit out of the pop-up). I'm by no means an interweb java/SQL/XML/etc. wizard so I could be wrong, but I know how crappy it can be to ask a question and get no response.

Ok, I love MEP as compared to ME3. However I just discovered a HUGE problem with MEP and was wondering if anybody else has come across a similar discrepancy. Cory, you'll be familiar with the general idea of this macro, as it is the one we PMed about last week. Scenario: At work we use ME3 (except for me, because I'm an angry rebel). My boss's boss requested a macro last week that performed a very simple function, but a necessary one. Here's the gist: We have a .csv file 550 lines long (title "Mule"). We also have a .txt file generated 5 times throughout the day. The .txt file ranges anywhere from several hundred KB in size to several hundred MB in size. The macro needs to grab the account number from the comma delimited .csv and check the .txt file for occurrences of the account number within. Only one hit is required, and if the account number does appear, the entire line from the Mule file needs to be entered into a separate .txt file. After much tribulation (thanks in no small part to the sheer crapiness of my PC), I was finally able to make a macro that works wonderfully well in ME3. Today, the bosses told me that they would like me to be the guy who runs this macro throughout the day to gather the necessary information. Not a problem. The largest file so far was 220 MB, and it ran in about 3 minutes. However, since I'm a snob and like the features of MEP, I decided to convert the macro to MEP and "improve" it for my own pleasure. My changes consist of adding a counter and utilizing the "Update Textbox" feature so I can see about how far along the macro has progressed. The first thing I noticed (during a test using a 300 KB .txt file): Running the macro in ME3 was just a little faster than MEP without any changes. Not enough to really matter, but noticeable. The second thing I noticed (still using the 300 KB file): Adding the "Update Textbox" feature slows the macro down a little more. This I expected, so it doesn't bother me. The tradeoff of viewing the progress is worth the insignificant slow-down. The third thing, and this is the killer: I ran the fully MEP-tricked-out macro against a previously processed 31 MB file (clocked at 32 seconds to process the entire file in ME3 (just over 17 lines per second)), and the macro stalled. Or at least, I thought it stalled. The text box sat on "Items processed: 0" for so long I thought the macro had broken. Then it changed to "1". I waited... eventually it changed to "2". At this rate it was going to take an hour and a half to process the entire file. About a 17000% increase over ME3. I didn't dare test it against the 220 MB file. Has anybody else noticed this? Does anybody else think that this is a highly unacceptable discrepancy? Here are the codes for the ME3 and MEP macros. I can't provide examples of the actual files, since it's all very sensitive bank account information... not to mention the fact that the .txt files are gargantuan. Please notice that the changes between the two macros are really very superficial: I renamed variables for MEP-sized convenience, and added just a couple of commands for the Updater. ME3 Script Variable Set String %T14% "G:\Loss Prevention\ACH\Mule Accounts.csv" Text Box Display: Find the Source Variable Set String %T10% from File Name Text Box Close: Find the Source Variable Set String %T15% "%T10%" Replace ".txt" with " " in %T15% Variable Set String %T12% "%T15% Match File.txt" Variable Modify String: Save %T13% to Text File Date/Time: Save "h:mm:ss AMPM" into %T20% Text Box Display: ACH Checker Variable Set String %T11% from File: "%T10%" ASCII File Begin Process: "%T14%" (Comma Delimited Text ) Variable Set String %T4% "%T4% " If Variable %T11% contains variable %T4% Variable Set String %T7% "%T3%, %T4%, %T5%, %T6%" Variable Modify String: Append %T7% to Text File Variable Modify Integer: Inc (%N1%) End If ASCII File End Process Text Box Close: ACH Checker Date/Time: Save "h:mm:ss AMPM" into %T21% Text Box Display: Finished ME3 DE <TVAR2:14:01:G:\Loss Prevention\ACH\Mule Accounts.csv><TBOX4:F:6:000469000050000290000083:000:Find the SourceBrowse to the Source ACH file.><TVAR2:10:09:SOURCE File><TBCLOSE:Find the Source><TVAR2:15:01:%T10%><TMVAR2:21:15:01:001:000:.txt ><TVAR2:12:01:%T15% Match File.txt><TMVAR2:17:13:00:000:000:%T12%F><DT:h:mm:ss AMPMT:20:1:><TBOX4:F:6:000469000050000290000106:000:ACH CheckerThe macro is running. Started: %T20%><TVAR2:11:04:%T10%><ADFBEG:F10:001:000002:000000:%T14%><TVAR2:04:01:%T4% ><IFVAR2:4:11:7:T4><TVAR2:07:01:%T3%, %T4%, %T5%, %T6%><TMVAR2:20:07:00:000:000:%T12%T><NMVAR:08:01:0:0000001:0:0000000><ENDIF><ADFEND><TBCLOSE:ACH Checker><DT:h:mm:ss AMPMT:21:1:><TBOX4:T:1:000570Center000278000200:000:FinishedThe Checker has finished. Matches found: %N1% Started - %T20% Finished - %T21%> MEP Script Variable Set String %MuleLocation% to "G:\Loss Prevention\ACH\Mule Accounts.csv" Text Box Display: Find the Source Variable Set String %ACHSourceFile[1]%: Prompt for a filename Text Box Close: Find the Source Variable Set String %ACHSourceFile[2]% to "%ACHSourceFile[1]%" Variable Modify String: Replace ".txt" in %ACHSourceFile[2]% with " " Variable Set String %ACHMatchName% to "%ACHSourceFile[2]% Match File.txt" Variable Modify String: Save %ACHMatchFile% to "%ACHMatchName%" Date/Time: Set %Start% to the current date/time using "h:mm:ss AMPM" as the format Text Box Display: ACH Checker Variable Set String set %ACHTextContents% to the contents of %ACHSourceFile[1]% ASCII File Begin Process: "%MuleLocation%" (Comma Delimited Text (.csv)) Variable Modify Integer %Processed%: Increment Variable Set String %T[4]% to "%T[4]% " If Variable %ACHTextContents% Contains "%T[4]%" Variable Set String %MatchedClientInfo% to "%T[3]%, %T[4]%, %T[5]%, %T[6]%" Variable Modify String: Append %MatchedClientInfo% to text file, "%ACHMatchName%" Variable Modify Integer %MatchIncrement%: Increment End If Update Textbox: ACH Checker ASCII File End Process Text Box Close: ACH Checker Date/Time: Set %Finish% to the current date/time using "h:mm:ss AMPM" as the format Text Box Display: Finished MEP DE <VARIABLE SET STRING Option="\x00" Destination="%MuleLocation%" Value="G:\\Loss Prevention\\ACH\\Mule Accounts.csv"/> <TEXT BOX DISPLAY Title="Find the Source" Content="{\\rtf1\\ansi\\deff0{\\fonttbl{\\f0\\fnil Tahoma;}}\r\n{\\colortbl;\\red0\\green0\\blue255;}\r\n\\viewkind4\\uc1\\pard\\cf1\\lang1033\\b\\f0\\fs24 Browse to the Source ACH file.\\cf0\\b0\\fs16 \r\n\\par }\r\n" Left="469" Top="50" Width="295" Height="73" Monitor="0" OnTop="TRUE" Keep_Focus="FALSE" Mode="\x02" Delay="0"/> <VARIABLE SET STRING Option="\x08" Destination="%ACHSourceFile[1]%" Value="Browse to the ACH SOURCE .txt File"/> <TEXT BOX CLOSE Header="Find the Source"/> <VARIABLE SET STRING Option="\x00" Destination="%ACHSourceFile[2]%" Value="%ACHSourceFile[1]%"/> <VARIABLE MODIFY STRING Option="\x0F" Destination="%ACHSourceFile[2]%" ToReplace=".txt" ReplaceWith=" " All="TRUE" IgnoreCase="TRUE"/> <VARIABLE SET STRING Option="\x00" Destination="%ACHMatchName%" Value="%ACHSourceFile[2]% Match File.txt"/> <VARIABLE MODIFY STRING Option="\x11" Destination="%ACHMatchFile%" Filename="%ACHMatchName%" CRLF="FALSE"/> <DATE/TIME Format="h:mm:ss AMPM" Flags="\x80" Date="12/30/1899" Day_Offset="0" Month_Offset="0" Year_Offset="0" Hour_Offset="0" Second_Offset="0" Left="Center" Top="Center" Monitor="0" Variable="%Start%" IsDateVar="FALSE" _IGNORE="0x0002"/> <TEXT BOX DISPLAY Title="ACH Checker" Content="{\\rtf1\\ansi\\ansicpg1252\\deff0{\\fonttbl{\\f0\\fnil Tahoma;}{\\f1\\fnil\\fcharset0 Tahoma;}}\r\n{\\colortbl;\\red0\\green0\\blue255;\\red0\\green128\\blue0;}\r\n\\viewkind4\\uc1\\pard\\qc\\cf1\\lang1033\\b\\f0\\fs24 The macro is running.\\cf0\\b0\\fs16 \r\n\\par \\pard \r\n\\par \\pard\\qc\\f1 Items processed so far:\\i \\cf2 %Processed%\\i0\\f0 \r\n\\par \\pard\\cf0 \r\n\\par \\pard\\qc Started: \\b %Start%\r\n\\par }\r\n" Left="469" Top="50" Width="290" Height="128" Monitor="0" OnTop="TRUE" Keep_Focus="FALSE" Mode="\x02" Delay="0"/> <VARIABLE SET STRING Option="\x03" Destination="%ACHTextContents%" Filename="%ACHSourceFile[1]%" Strip="FALSE"/> <ASCII FILE BEGIN PROCESS Filename="%MuleLocation%" Format="CSV" Start_Record="2" Process_All="TRUE" Records="0" Variable="%T%" Start_Index="1"/> <VARIABLE MODIFY INTEGER Option="\x07" Destination="%Processed%"/> <VARIABLE SET STRING Option="\x00" Destination="%T[4]%" Value="%T[4]% "/> <IF VARIABLE Variable="%ACHTextContents%" Condition="\x06" Value="%T[4]%" IgnoreCase="FALSE"/> <VARIABLE SET STRING Option="\x00" Destination="%MatchedClientInfo%" Value="%T[3]%, %T[4]%, %T[5]%, %T[6]%"/> <VARIABLE MODIFY STRING Option="\x12" Destination="%MatchedClientInfo%" Filename="%ACHMatchName%" CRLF="TRUE"/> <VARIABLE MODIFY INTEGER Option="\x07" Destination="%MatchIncrement%"/> <END IF/> <UPDATE TEXTBOX Header="ACH Checker" Content="{\\rtf1\\ansi\\ansicpg1252\\deff0{\\fonttbl{\\f0\\fnil Tahoma;}{\\f1\\fnil\\fcharset0 Tahoma;}}\r\n{\\colortbl;\\red0\\green0\\blue255;\\red0\\green128\\blue0;}\r\n\\viewkind4\\uc1\\pard\\qc\\cf1\\lang1033\\b\\f0\\fs24 The macro is running.\\cf0\\b0\\fs16 \r\n\\par \\pard \r\n\\par \\pard\\qc\\f1 Items processed so far:\\i \\cf2 %Processed%\\i0\\f0 \r\n\\par \\pard\\cf0 \r\n\\par \\pard\\qc Started: \\b %Start%\r\n\\par }\r\n"/> <ASCII FILE END PROCESS/> <TEXT BOX CLOSE Header="ACH Checker"/> <DATE/TIME Format="h:mm:ss AMPM" Flags="\x80" Date="12/30/1899" Day_Offset="0" Month_Offset="0" Year_Offset="0" Hour_Offset="0" Second_Offset="0" Left="Center" Top="Center" Monitor="0" Variable="%Finish%" IsDateVar="FALSE" _IGNORE="0x0002"/> <TEXT BOX DISPLAY Title="Finished" Content="{\\rtf1\\ansi\\ansicpg1252\\deff0{\\fonttbl{\\f0\\fnil Tahoma;}{\\f1\\fnil\\fcharset0 Tahoma;}}\r\n{\\colortbl;\\red0\\green0\\blue255;\\red0\\green128\\blue0;\\red255\\green0\\blue0;}\r\n\\viewkind4\\uc1\\pard\\qc\\cf1\\lang1033\\b\\f0\\fs24 The Checker has finished.\r\n\\par \\cf0\\b0\\f1\\fs16 Items processed: \\cf2 %Processed%\\cf0\\f0 \r\n\\par Matches found: \\cf3\\b\\fs24 %MatchIncrement%\\cf0\\b0\\fs16 \r\n\\par \\pard \r\n\\par Started - %Start%\r\n\\par Finished - %Finish%\r\n\\par }\r\n" Left="570" Top="Center" Width="278" Height="200" Monitor="0" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/>

Ok, first of all, let me say that I love these forums and all the helpful people who monitor them and provide solutions to those of us with problems. Now, with that said, here come the water-works: In the past, when "code" or "codebox" tags were used, they didn't affect the text-wrapping for the rest of the post. In recent months, however, "codebox" hasn't worked correctly, and regardless of which tag you use, if your code reaches the edge of the page and beyond, the rest of your post is summarily screwed. This results in one of a couple of situations: 1) Readers have to scroll right and left over and over to get the full message (tedious) 2) The poster enters subjective carriage returns in order to keep the message within his/her browser, though this may not appear very clean on other users' machines. And in either case, the Edit buttons end up way off-screen. This problem then also extends to anybody responding to the message using the Quote function. I know this problem has been brought up in previous posts, and I know the forum hosts have been busy on other projects and whatnot... but I was feeling just a bit whiny and wanted to add my two cents on the matter. How do we make an official request to have this particular bug rectified? Just so I can get it off my chest? Thanks!

Hey MBone, My experience with the last build was buggy as heck. The current build couldn't come fast enough. However, the current build (as much as it fixed the bugs that were crashing my MEP several time every hour), does have a tendency to overwhelm my processor bringing all functionality (besides mouse movements) to a near halt. The only fix being a long and arduous Task Manager > End MacExp.exe approach, or outright hard-reboot of my system (when I'm not patient enough to take the Task Manager route). I don't know if there is an actual ISS ticket number for this, but there have been a lot of reports on the forums about it (see This topic before making your decision).