paul

I don't understand what the problem is. In your called macro simply reference the global variable from the calling macro by typing its name directly into the command you're using. For example, I have test1 and test2 macros, where test1 calls test2 after defining a global variable %tGlobal% as a 5-element string array. test2 simply addresses %tGlobal[1]% to access the 1st element of this array. here's the very simple code: test1 <VARIABLE SET STRING Option="\x00" Destination="%tGlobal[1]%" Value="This is a global variable" NoEmbeddedVars="FALSE"/> <MACRO RUN Use_ID="FALSE" Name="Test2" ID="-1" Wait="TRUE"/> test2 <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 show my global variable\r\n\\par \r\n\\par %tGlobal[1]%\\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"/> This works for me as expected.

Did you not read my response? While global variables declared in "parent" macros are indeed available to all called macros at runtime, that does not mean that called macros have any awareness at design time of global variables that may become available at runtime. Yes, you can use it in other variables - at runtime. What you are seeking is the ability to reference such a variable at design time. That's not possible, and I don't see how it ever could be.

Nor are they for me in a normal environment. If you think about it for a moment, how could they be? Let's suppose 3 macros m1, m2 and m3. m1 defines a global variable v1 and calls m3. m2 also defines a global variable v2 and calls m3. If I understand you correctly, you want to see v1 and/or v2 in m3's dropdown list of variables. How does m3 know which global variables it can see? Potentially that is all the variables ever defined by any macro since m3 cannot know what other macros will call it.

I would create a comma-delimited text file of the 2 columns of interest from the Excel spreadsheet. Then I'd write a macro: - read the comma delimited text file into a variable - split this variable into an array (declare this array in the variables tab and define 3000 elements), using comma for the "on" field - run through the 3000 image files; for each image file: - - extract its name - - locate its name in the array, searching every alternate value starting at 1 - - add 1 to the index of the located array value - this gives you your new name Note: If you sort the array on the before name, and have the image files in name sequence (NTFS does this for you automatically) then your loop does not need to return to 1 for each new search. There are many alternative approaches to this (I can think of at least 3), but this one should be reasonably easy to implement.

Private message please.

I think you're asking me to write the macro for you! If that's the case, I can happily oblige, but it will cost you. Send me a private message if you wish to continue down this path. BTW, I'm very familiar with Russian characters, having studied Russian at school for several years!

Well, given that there exists an error for a missing folder, it seems to me that it should generate an error. Report it anyway.

You'll have to do this manually. Read the file into a variable. Loop - Locate the start of each word by searching for separators like space, period, comma, etc. - Extract the 1st letter of each word - Find it in a string of all lower-case Russian letters - Extract the character from a string of all upper-case Russian letters using the index returned from the lower-case search

Agreed - no error condition is triggered. Therefore it follows that the Prompt for Action subcommand won't work.

I use a free program to insert a new top-level option called Menu. If I then select Menu, the ribbon disappears and the display reverts to your and my preferred look. If you want more details, please let me know.

Oh, you already know this! See http://pgmacros.invisionzone.com/topic/5013-how-to-activate-ms-word-reliably-fails-on-multiple-configurations-and-macro-coding-methods/?hl=handle#entry21543 !!!

Try this (Cory is mistaken when he says you cannot activate a window using its handle). Program Launch: "notepad.exe" (Normal) Parameters: Program Launch: "notepad.exe" (Normal) Parameters: Variable Set Handle %hWin% from all windows with the title of "Notepad" Text Box Display: Window Activate: %hWin[1]% Text Type (Simulate Keystrokes): <ENTER><ENTER><ENTER>This is the active notepad window Wait for Text Playback Window Activate: %hWin[2]% Text Type (Simulate Keystrokes): <ENTER><ENTER><ENTER>This is the active notepad window - should be different to the first notepad window activated Wait for Text Playback <PROGRAM LAUNCH Path="notepad.exe" Mode="\x00" Default_Path="TRUE" Wait="1" Get_Console="FALSE"/> <PROGRAM LAUNCH Path="notepad.exe" Mode="\x00" Default_Path="TRUE" Wait="1" Get_Console="FALSE"/> <VARIABLE SET HANDLE Option="\x00" Info="Notepad" Partial="TRUE" Wildcards="FALSE" Destination="%hWin%"/> <TEXT BOX DISPLAY Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang3081{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs16 Move one of the notepad windows to a different location so that you can see both (resize if desired), then press ENTER\\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"/> <WINDOW ACTIVATE Title="%hWin[1]%" Exact_Match="TRUE" Wildcards="FALSE" _IGNORE="0x0006"/> <TEXT TYPE Action="0" Text="<ENTER><ENTER><ENTER>This is the active notepad window"/> <WAIT FOR TEXT PLAYBACK Indefinite="FALSE" Hours="0" Minutes="0" Seconds="10"/> <WINDOW ACTIVATE Title="%hWin[2]%" Exact_Match="TRUE" Wildcards="FALSE" _IGNORE="0x0006"/> <TEXT TYPE Action="0" Text="<ENTER><ENTER><ENTER>This is the active notepad window - should be different to the first notepad window activated"/> <WAIT FOR TEXT PLAYBACK Indefinite="FALSE" Hours="0" Minutes="0" Seconds="10"/>

I presume you mean the log file "will look like this" rather than the macro? Your use of the phrase "last line" suggests that your file is not space delimited after all, but that each line has at its end a carriage return and linefeed (ascii 13 + ascii 10). If you really mean space delimited, then each of the 21 words in the text above would parse into a separate variable or record. So the last sentence "Since yesterday I got a new job." would be separated into 7 variables or records. How on earth could the macro relate these 7 words as a "sentence", as opposed to, say, "many pets. Since yesterday I got a new job."? Please explain better exactly what you mean.

And how would this third macro call the right macro, given that two or more macros share the same name (which, incidentally, I find is a really bad practice!).

I don't think so. AFAIK, Output Macro Information has only ever worked on all macros, so selecting one macro has no effect. Clearly selecting multiple macros should not affect this command one way or the other, but it's no big deal to select only one macro in order to "ungrey" the command.

You will need to create a new macro to increment the filename counter and save the file. This new macro will be activated by the appearance of the save dialog box window - Add Activation / Window Title / Window is Opened (or Window Gains Focus - whichever works more reliably). Assuming that your main macro is always active while this process is taking place, you may want to add some logic into this new macro to check that the main macro is running (you'll have to look after the logic here yourself since there is no If Macro Running command - use a "shared" variable, or the registry); the reason for this is that the same save dialog box window may appear in other contexts where you don't want to have it generate and save a file automatically. If you need more help, just ask (and perhaps provide details, or an image, of the save dialog box window).

I tried this a while back. I too had lots of ideas about encapsulating capabilities using AutoIt that MEP either cannot do, or does badly. But, like you, I discovered almost no interest. And it looks to me as if Macro Express is not being developed further, which doesn't bode well for the future.

Well, that's not really true. I have written a suite of 36 keypress macros (one for each numeric and alpha key, identical except for the keystroke being waited for), plus 3 menu and control macros. The net effect is that I can specify which keys I want to wait for, how long to wait, and report back to the originating macro which key, if any, was pressed. If you're interested, I can readily make them available to you.

Sounds like you're talking from experience! BTW, is it just me or does anyone else find it quite difficult to quote a previous message and successfully edit that response? I often see the name of the author disappear and all the quotation formatting too. I usually end up making several attempts to quote the message before I'm successful. For example, if you look carefully, you'll see that the single sentence quote from Cory is preceded by a space. Without that manually inserted space, all the formatting disappears.

Agreed.

My personal, not very strong, feeling is that if macro X is called by another macro, then macro X's last run time does not need to be updated. Macro Explorer is an interactive environment, and therefore its last run time column should be reserved for the last tme the macro was run interactively.

Macro Control / External Script Language: AutoIt Save console output to: %tOutput% In AutoIt, use consolewrite(variable) to return values to %tOutput%. Pass parameters to AutoIt using values in MEP's Script Language Parameters box, and read them in AutoIt with: $cmdline[0] = number of parameters passed $cmdline[1] = first parameter $cmdline[1] = second parameter, etc. Thus $cmdline[$cmdline[0]] is one way to get the last parameter. That for me is integration.

AutoIt integrates very well with MEP as an external script you can invoke from, and return results to, MEP. Starting MEP scripts from AutoIt is exactly the same as starting MEP scripts from any other language. There are 2 ways to do this: - run or call MeProc.exe with the /A parameter - see the section Windows API calls under Macro Activation in Help

Autohotkey's syntax is unique and highly non-standard. The 2 languages both spring from the same original source but now diverge widely. If you have some Basic experience, then I believe AutoIt is the better choice. Actually, although there are some keyboard-orientated things you can do in Autohotkey that you cannot easily do in AutoIt, for me AutoIt is overwhelmngly the better choice (and, unlike AutoIt, you cannot interface Autohotkey with MEP). There are also user-developed libraries in AutoIt, further extending its functionality (for example, there is a comprehensive library for Internet Explorer which allows you do do anything you want in IE).

Autohotkey's syntax is unique and highly non-standard. The 2 languages both spring from the same original source but now diverge widely. If you have some Basic experience, then I believe AutoIt is the better choice. Actually, although there are some keyboard-orientated things you can do in Autohotkey that you cannot easily do in AutoIt, for me AutoIt is overwhelmngly the better choice (and, unlike AutoIt, you cannot interface Autohotkey with MEP). There are also user-developed libraries in AutoIt, further extending its functionality (for example, there is a comprehensive library for Internet Explorer which allows you do do anything you want in IE).