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.

Thanks for the tip Cory! I do that as much i can. But sometimes a function in a program is only accessable by a shortcut i already use. I guess that happened to everybody once who uses MEX a lot, no?

 

It´s still hard to believe that MEX can´t distinguish between Keystrokes i type and Keystrokes it types itself, no?

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.

Thanks for the clarification, Cory. Although I still don't see why it doesn't work for such child windows, if they appear in the Browse list?

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

I'm following along here, to learn more about these text file commands, which I've rarely used.

.........

But, even assuming I knew that the maximimum number of fields in any record was 8, as I have above, this is obviously a very clumsy way of displaying all the data. I'm hoping you might point out a better method please?

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

Really? Am I incorrect in my belief that ASCII File processing needs to be fed an ARRAY variable?

 

Under the understanding that an array IS mandatory here:

If I process to %T%, it stores the FIRST value of the file in %T[1]%, second to %T[2]%, and so on...

... but I have no way of knowing how many values are in the text file... so how would I get the FINAL value?

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 use ClipMate v7 with MacroExpress Pro. The only time the two don't play well together is when I want to use a feature in ClipMate called PowerPaste. When I need the PowerPaste feature I disable MEP then re-enable after. But I use PowerPaste rarely. Other than that I run both together all the time.

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!

Take a look at command

Variable Set Interger [set Value from Screen Width] and

Variable Set Interger [set Value from Screen Height]

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.

Although I suppose it would mainly be used with IF routines, Goto can be used anywhere.

 

Here's a simple example to play with:

 

:Start

Text Box Display: Message 1

If Variable %N[1]% Is Greater Than "3"

Goto:Over3

Else

Text Box Display: Message 2

Variable Modify Integer %N[1]%: Increment

End If

Goto:Start

:Over3

Text Box Display: Final message

--

Terry, East Grinstead, UK

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 want to launch a macro every morning that opens the screen resolution page under Control Panel\Appearance and Personalization\Display\Screen Resolution.

Then I want it to "detect" the screen resolution. Then close the page.

 

The macro opens the screen resolution window.

It waits until the window is fully displayed.

Then I send these simulated key strokes.

Alt d to highlight the address

Tab Tab to move the focus to the detect button

Alt c to hit the detect button.

Then wait for it to do a detect.

Then alt f4 to close the window.

 

However, the macro breaks down when I start sending keystrokes to the window. When I actually do keystrokes it works fine. However, when ME Pro sends the window keystrokes something different happens or nothing happens at all.

 

Any settings I need to set up in ME or Windows 7 that will help this to happen?

 

Here is my macro...

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>"/>

also, do you know why the original has the ~1 in the shortened paths?

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.

Whereas the Win9x OSes use a simple decimal number in the numeric

tail, the WinNT family OSes follow the same pattern only in the

first four cases. After that, they start using a 4-digit

hexadecimal number in the middle of the 8.3 name as the

distinguishing part (only the first two letters remains the same).

 

The hexadecimal value is probably a hash value for the string to

supposedly shorten the filename matching operation which could be

very time consuming. Microsoft programmers chose to keep the first

four match done numerically for the sake of compatibility to the

Win9X systems. What they failed to realize is that they allowed

only the first four such names for compatibility.

Well thanks guys. It doesn't look like it's an easy thing to do. And sorry about misspelling the title, it should have read "Disable"

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

NoClose

It is possible, with Macro Express, to "appropriate" the three icons on the top-right corner of a window, as well as scroll bars, system menu, borders, menus, and so on. Create a new macro, choose "Mouse Event" as the activation, and then explore!

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 like N since I've always used that in science and math classes. Interesting you like T. I was thinking the other day that it's a misnomer to call text string. Any group of characters can be a string. But then again one can have a 'string' of binary data as well. For instance I can use string vars to process a BMP file. I can't resolve this one. But in most computer languages I see this variable type called "String". Should we not emulate real programmers? ;-) Going thru the list of vars in the help file I think it should be fairly intuitive.

• T Text (could be S alternatively)
  
• N Integer
  
• L Large integer
  
• D Decimal
  
• C Control
  
• T Date/Time. (to me it's all time)
  
• B Boolean
  
• H Handle
  

I think I'll adopt this list.

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...

I will admit however you do have me reconsidering adding a char for variables type though. But I'm thinking maybe at the end. I do like grouping my variables alphabetically sometimes. Like a source TSV file that contains strings and integers I might want to have them all "Source" so they all group together. But it would be cool then to have "Source CID S" and "Source CID I" next to each other. Hmmm...

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!!

My only challenge to you was to give me a technical reason why it's a bad idea in MEP. So far I haven't heard one that satisfies me. But I'm keeping an open mind.

But there's more to life than technical reasons!

I think my best reason is

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.

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!

verbally telling your computer what to do/needs to be done in any language or dialect is almost as good as it gets. We've moved on; who cares today about machine code other than a few people in the industry?

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.

At the entrance of a building site is a sign that reads "Hard hats must be worn". People entering the site therefore obtain a hard hat and wear it.

At the top of an escalator leading to underground trains is a notice that reads "Dogs must be carried". Does that mean it's someone's job to hand out dogs to those unfortunate people who don't have one?

This illustrates the vitual impossibility of "verbally telling your computer what to do".

But the argument 'because programmers do it' is flawed as most of those programmer are in an environment that doesn't allow spaces so of course they will not be in the habit. I write macros in MEP. Also just because a lot of people do something doesn't satisfy me as a valid reason to follow suit. Millions of people play the lottery but that doesn't mean it's a sound financial investment;-)

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.

Same for me are languages that are case sensitive.

Agreed.

Also I don't see the need for a prefix character to indicate variable type. Usually the context tells the tale and if not just open the Variables tab or group when using the Select Variables dialog.

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 guess to me it's like how I still to this day find old accountants who TYPE EVERYTHING IN CAPS. ALWAYS. EVEN EMAIL. Hello! you're not on that ancient Digital mainframe anymore that didn't support mixed case. But when I asked them why they do that there answer always is much like yours and something to the effect of "That's the way it's supposed to be done" without ever having a valid reason and ignoring how technological advances change the 'proper way'.

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.

I'm just a little defensive when you characterize my method as unprofessional.

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.

Paul, why don't you like spaces in variable names?

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!