paul

In other words, you need to trim each line, then write it out (yes, we're back to processing text files!), rather than the entire file contents.

I believe there's a bug here, which I have reported.

It's even harder to believe that a long-time MEX user has failed to grasp such a fundamental concept.

MEP has, as far as I know, no Regex capabilities. So whatever solution you adopt has to be done via an external piece of software. AutoIt provides 2 regex built-in commands, StringRegExp and StringRegExpReplace. See RegEx in AutoIt for more details. In any case, you'll have to write the logic yourself.

MDI windows are more like controls than windows. It's difficult to handle MDI windows, even in AutoIt.

Unfortunately, the file processing commands in MEP (like so much else) are shockingly slow with larger files (unlike ME3 where they were astonsihingly quick). Here's some code to display the results of each row in your .csv file. You could also derive the maximum number of fields by first reading the file with the Text File commands and counting the number of commas in each row - prohibitively slow in MEP for large files! Variable Set to ASCII Char 13 to %tCr% Variable Set to ASCII Char 10 to %tLf% ASCII File Begin Process: "d:\temp\test.csv" (Comma Delimited Text (.csv)) Variable Set String %tData% to "" Variable Set Bool %bDataFound% to "False" Repeat Start (Repeat 100 times) If Variable %tDataIn[%nIndex%]% Equals "" And If Variable %bDataFound% Equals "False" Continue Else Variable Set Bool %bDataFound% to "True" Variable Set String %tData% to "Field %nIndex% = %tDataIn[%nIndex%]%%tCr%%tLf%%tData%" End If End Repeat Text Box Display: ASCII File End Process <VARIABLE SET TO ASCII CHAR Value="13" Destination="%tCr%"/> <VARIABLE SET TO ASCII CHAR Value="10" Destination="%tLf%"/> <ASCII FILE BEGIN PROCESS Filename="d:\\temp\\test.csv" Format="CSV" Start_Record="1" Process_All="TRUE" Records="1" Variable="%tDataIn%" Start_Index="1"/> <VARIABLE SET STRING Option="\x00" Destination="%tData%"/> <VARIABLE SET BOOL Destination="%bDataFound%" Command="263" Value="FALSE"/> <REPEAT START Start="100" Step="-1" Count="100" Save="TRUE" Variable="%nIndex%"/> <IF VARIABLE Variable="%tDataIn[%nIndex%]%" Condition="\x00" IgnoreCase="FALSE"/> <AND/> <IF VARIABLE Variable="%bDataFound%" Condition="\x00" Value="False" IgnoreCase="FALSE"/> <CONTINUE/> <ELSE/> <VARIABLE SET BOOL Destination="%bDataFound%" Command="263" Value="TRUE"/> <VARIABLE SET STRING Option="\x00" Destination="%tData%" Value="Field %nIndex% = %tDataIn[%nIndex%]%%tCr%%tLf%%tData%"/> <END IF/> <END REPEAT/> <TEXT BOX DISPLAY Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang3081{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\ul\\f0\\fs16 Current Result\r\n\\par \\ulnone %tData%\\ul\\f1 \r\n\\par }\r\n" Left="Center" Top="Center" Width="278" Height="200" Monitor="2" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/> <ASCII FILE END PROCESS/> Notes: - We process each record backwards so that we can locate the last field in each record (too bad if the last field contains no data!) - Even though we're processing backwards, we can still display forwards! - The boolean flag is needed to display any "empty" fields before the last field in the current record - Repeat 100 times is obviously an arbitrary guess at the likely longest record

Let's assume a comma-delimited file contains these values: abc,def,g 123,456,789,012,345 qwe,rty,uio,pqw The command <ASCII FILE BEGIN PROCESS Filename="YourFilePathAndName" Format="CSV" Start_Record="1" Process_All="TRUE" Records="1" Variable="%tData%" Start_Index="1"/> will place each comma-delimited value into %tData[1]%, %tData[2]%, etc. Obviously you must set up %tData% as an array containing at least as many elements as the row in your file with the most fields or columns (number of commas plus one) Once you have finished reading the file, then %tData% will contain these values: %tData[1]% qwe %tData[2]% rty %tData[3]% uio %tData[4]% pqw %tData[5]%

Just read the file; when the file is closed, your variable will contain the value of the last row. Text File Begin Process: YourFilePathAndName Text File End Process Text Box Display: <TEXT FILE BEGIN PROCESS Filename="YourFilePathAndName" Start_Record="1" Process_All="TRUE" Records="1" Variable="%tData%"/> <TEXT FILE END PROCESS/> <TEXT BOX DISPLAY Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang3081{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs16 This should be the last line of your file!\r\n\\par \r\n\\par %tData%\\f1 \r\n\\par }\r\n" Left="Center" Top="Center" Width="278" Height="200" Monitor="2" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/>

Just read the file; when the file is closed, your variable will contain the value of the last row. Text File Begin Process: YourFilePathAndName Text File End Process Text Box Display: <TEXT FILE BEGIN PROCESS Filename="YourFilePathAndName" Start_Record="1" Process_All="TRUE" Records="1" Variable="%tData%"/> <TEXT FILE END PROCESS/> <TEXT BOX DISPLAY Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang3081{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs16 This should be the last line of your file!\r\n\\par \r\n\\par %tData%\\f1 \r\n\\par }\r\n" Left="Center" Top="Center" Width="278" Height="200" Monitor="2" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/>

Here's a utility to view what scan codes are generated by any key on your keyboard. Keyboard Scan Codes

I've used Clipmate for years, and have never experienced any problems with the combination of MEP and Powerpaste. Note that in Windows 7 (x64?) Powerpaste doesn't work properly - it scrolls to the end of its list before I've had a chance to react to even the 1st entry!

With respect, these 2 MEP commands simply interrogate the display and set 2 variables with the current width and height; thsy have no impact at all on what the operating system sees. I don't really know what the Detect button does that Windows hasn't already been able to do for itself, but I imagine that under some circumstances, the Detect button might cause the displayed resolution to change if Windows has somehow become confused. If anything does change as a result of clicking Detect, then I imagine those changes will affect the entire operating system.

This can be much better written as follows (I know the supplied example was simply to illustrate the use of GoTos, but within professional ranks the use of GoTos is generally very strongly deprecated because it tends to make programs much harder to debug; if you're interested, read up on what Dijkstra (one of my heroes) had to say, and look up spaghetti code. I do not say that GoTos are always bad or wrong, but IMHO their use should be a last resort). Repeat until %N[1]% is greater than 3 Text Box Display: Message 1 Variable Modify Integer %N[1]%: Increment End Repeat Text Box Display: Final message I think this second piece of code is far easier to understand and is much more concise.

I've spotted a couple of problems with your macro! 1) Get Control won't work because the index settings will change from run to run. 2) Alt-C won't work because there's no underlined c in Detect (at least, not on my machine). So try this - it works perfectly for me: Move Mouse to Tray Icon to UltraMon Mouse Left Double Click Wait for Window Title: Screen Resolution Delay: 2 seconds Window Activate: Screen Resolution Text Type (Simulate Keystrokes): <SHIFT><TAB><SHIFT><TAB><ENTER> <MOVE MOUSE TO TRAY ICON Icon="UltraMon" Exact="TRUE" Center="TRUE"/> <MOUSE LEFT DOUBLE CLICK/> <WAIT FOR WINDOW TITLE Title="Screen Resolution" Partial="TRUE" Wildcards="FALSE" Indefinite="FALSE" Hours="0" Minutes="0" Seconds="10"/> <DELAY Flags="\x01" Time="2"/> <WINDOW ACTIVATE Title="Screen Resolution" Exact_Match="FALSE" Wildcards="FALSE" _IGNORE="0x0006"/> <TEXT TYPE Action="0" Text="<SHIFT><TAB><SHIFT><TAB><ENTER>"/>

If you create 4 folders in this sequence: - c:\mytest 4\folder - c:\mytest 3\folder - c:\mytest 2\folder - c:\mytest 1\folder then the short names (use dir c:\mytest* /x to find them) of these 4 folders are, respectively: - c:\mytest~1\folder - c:\mytest~2\folder - c:\mytest~3\folder - c:\mytest~4\folder Windows takes the first 6 characters, followed by tilde (~) followed by a sequential number starting at 1. But now add a 5th folder: - c:\mytest 5\folder Do another dir c:\mytest* /x, and you'll see that this 5th shortname is strange. It'll be C:\myxxxx~1\folder, where xxxx is an appartently random set of hex characters. Here's a more lengthy explanation.

You might want to take a look at NoClose - a free utility written in AHK (AutoHotkey) NoClose

Macros can be activated when the Maximize or Minimize icons are clicked, but I can't find any reference to the Close icon. ???

What you want to do is to persist the value of a variable. There is a number of ways to do this: - save a value in the registry and retrieve it each time you run the macro - write the value to a file (e.g. an .ini file) and read the value back in each time you run the macro If you want help with either of these techniques, simply ask.

I use T for the same reason as I use N - because MEP does (though I use lower-case). You've got T twice in your list - was that intentional? I do like your T for date/time though...

Yes, I originally used I for Integer variables. But since MEP uses N, I've switched to that. So, I use t (text), n (integer), d (decimal), b (boolean), c (control), h (handle) and I can't decide what to use for dates (whether dt, or a). And I've not used Large Integers - I suppose that should be N in contrast to n!!

But there's more to life than technical reasons! I think my best reason is For me, "First Name" should represent 2 things, not one. I find FirstName easier on the eye, but your prefererece is opposite to mine. In MEP I don't think it's a matter of technical reasons for preferring one method over another, e.g. variable names, IF vs CASE, etc., but more a matter of taste. And my taste is clearly superior to yours - just stop worrying about it!

Who was talking about machine code? Not I and not Cory. Another rant perhaps? Let me tell you a story James Martin used in his world-famous discourses in the 1980's. This illustrates the vitual impossibility of "verbally telling your computer what to do".

I disagree. The argument "because programmers do it" is not at all like people who buy lottery tickets. It's much more analagous to driving with a professional car driver, who will do things that we amateurs might question, but which we generally would do well to imitate.

Agreed. But then you have to read and understand the context, which requires time and effort. And opening the Variables tab doesn't work well when the macro is printed. I can't see any similarities here. Typing everything in caps makes the text considerably less readable. And I believe I advanced several valid reasons for my approach. As I recall, you simply asked me why I don't like spaces in variable names. And I told you. If you then want to feel defensive because you infer that I am criticizing you, then feel free. But when I gave you my answer, it was my answer; I was speaking for myself; I wasn't trying to convince you to change your practices; in truth, I wasn't thinking about you at all, and I certainly wasn't thinking about your methods. It's not only about you, you know! But I must say I don't know any programmer-type people who would ever want to include spaces in variable names. And in the enormous sample of such people I have polled , those who would make such a choice number less than 1.

Because, generically speaking, it's unprofessional! Most languages don't permit spaces in variable names - in fact I can't think of a single one, although I'm sure someone can correct me on this! I much prefer camel case, e.g. FirstName, StreetAddress, VariableName. Some languages permit spaces in some circumstances, but you then have to add additional characters to make it work, e.g. in Sql Server I can have column names with spaces, but then I must say: SELECT [First Name] instead of SELECT FirstName I find the second syntax more readable and it requires less typing. In writing, spaces are used to separate words. I want my variable names each to be apparent as a single word, because each of them represents a single thing. When naming files, I also avoid spaces because I can then refer to the file without quotation marks (though of course the path name often does contan one or more spaces). FWIW, software often adds stuff to the registry to enable right-click context menu items to address the selected file or files. So right-click on a text file and you can then open it with Notepad. But the registry entry is often (or even usually?) wrong because it references the selected file in its registry entry by %1 instead of "%1". Without those quote marks, the command won't work if the filename contains a space!