paul

AND "Wait for this macro to terminate before proceeding" is ticked.

My aim here is to provoke thought and some thinking "outside the box", not to provide prebuilt solutions for others to use "out the box". I'm trying to show people how to make a hamburger (with a little effort) rather than providing a hamburger for others to eat.

Here's some sample code that does what you want. After the split has been done, it loops backwards through the text array, e.g. T, to find the first %T[n]% variable with a length > 0. Why backwards? If your string were "This is" "" "an awesome" "sample text" then looping forward would stop after the first line. Variable Set to ASCII Char 13 to %tCr% Variable Set to ASCII Char 10 to %tLf% Variable Set String %tCrLf% to "%tCr%%tLf%" Variable Set String %tString% to "This is an awesome sample text" Split String "%tString%" on "%tCrLf%" into %T%, starting at 1 Repeat Start (Repeat 99 times) Variable Set Integer %iLen% to the length of variable %t[%iCounter%]% If Variable %iLen% Is Greater Than "0" Repeat Exit End If End Repeat Text Box Display: <VARIABLE SET TO ASCII CHAR Value="13" Destination="%tCr%"/> <VARIABLE SET TO ASCII CHAR Value="10" Destination="%tLf%"/> <VARIABLE SET STRING Option="\x00" Destination="%tCrLf%" Value="%tCr%%tLf%"/> <VARIABLE SET STRING Option="\x00" Destination="%tString%" Value="This is\r\n\r\nan awesome\r\nsample text"/> <SPLIT STRING Source="%tString%" SplitChar="%tCrLf%" Dest="%T%" Index="1"/> <REPEAT START Start="99" Step="-1" Count="99" Save="TRUE" Variable="%iCounter%"/> <VARIABLE SET INTEGER Option="\x0D" Destination="%iLen%" Text_Variable="%t[%iCounter%]%"/> <IF VARIABLE Variable="%iLen%" Condition="\x03" Value="0" IgnoreCase="FALSE"/> <REPEAT EXIT/> <END IF/> <END REPEAT/> <TEXT BOX DISPLAY Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang1033{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\lang3081\\f0\\fs16 Number of variables used is %iCounter%\\lang1033\\f1 \r\n\\par }\r\n" Left="Center" Top="Center" Width="278" Height="200" Monitor="1" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/>

I've implemented this exact requirement - please refer to my earlier post in Wait for a single key

If Variable %t[1]% Equals "" Which you achieve by: - Logic/If Variable - typing a text variable name into Variable, e.g. %t[1]% - selecting Equals - clicking on OK

Take a look at this message, which I posted earlier this week. Passing parameters

Tthe scripting language AutoIt has a comprehensive and reliable set of functions for handling Internet Explorer usage (including waiting for pages to finish loading). FYI, Macro Express 4 is able to drive AutoIt scripts directly (including the ability to pass and receive parameters).

If my macro uses the Variable Restore command or the alternative approach I described earlier, then the macro doesn't need to "know" anything specific. In other words, it performs a process (Variable Restore or the read of that generic C:\MacrosPro\MacroParameters.txt file); and the logic of the process remains static across all macros. Whether the process causes variables to become initialized with specific values is determined by the calling process, i.e. whether any values have been passed in with the /VT parameters, or if the C:\MacrosPro\MacroParameters.txt file exists - nothing more. Forcing a macro to know how many parameters to read and where from introduces dependencies where none existed before. I prefer my macros to be as robustly independent as possible.

Yes,the Variable Restore command is indeed a disaster in the current version of MEP. I described this in a message last week and put forward an alternative method of saving and restoring variables.

When running a macro with MeProc.exe, parameters must be passed using the /A and /V arguments, as in: "C:\Program Files\Macro Express Pro\MeProc.exe", /AMyMacro /VT99:abc /VT98:def The macro MyMacro must, in this case, do a Restore Text Variables in order to set %t[98]% to "def" and %t[99]% to "abc". Unfortunately the Restore Text Variables command in the latest release of MEP is very slow, at least on my machine. It has always operated more or less instantaneously, but now takes 4 seconds! I have therefore decided to adopt a new approach (I have never much liked the Restore Variable commands anyway because of how they affect other unrelated macros - unless you go to the trouble of clearing all text variables and then saving them). For those macros that require parameters I shall store one text file for each macro (using the macro name as part of the text file name): nn,tt where nn is the index number of the %t% array into which I store the value tt. First I copy the relevant macro text file to "C:\MacrosPro\MacroParameters.txt", then: If File Exists: "C:\MacrosPro\MacroParameters.txt" ASCII File Begin Process: "C:\MacrosPro\MacroParameters.txt" (Comma Delimited Text (.csv)) -- into array %tContents% Variable Set String %t[%tContents[1]%]% to "%tContents[2]%" ASCII File End Process Delete File/Files: "C:\MacrosPro\MacroParameters.txt" End If This works very well, requires no Restore or Save commands , and leaves no side-effects.

I scanned the changes in the latest release, hoping to find that my mouse would now work in ME's Explorer window. I found no mention of a fix, but when I tried it my mouse now scrolls properly. Wonderful! Until you have experienced a non-scrolling mouse, you can have no idea how awkward the ME interface is to navigate. Thank you. And I really like the new debug floating window (which you can activate with F5).

MEP has the ability to run a script in JScript, VBScript, HTA/HTML and AutoIt. You can pass parameters and save console output. I'd recommend VBScript or (even better, but possibly a little more work) AutoIt for your requirement. See Macro Control / External Script.

In launching a macro from Excel, you need to consider whether or not you want to wait until the macro has finished before continuing in Excel. If you need to d0 this often - i.e. several times a minute - then there's a better way of launching your macro. If you do this only infrequently then Shell (or its wait variation) is OK.

Doesn't a message have an attachment property where you could either check whether the message has an attachment or count the number of attachments belonging to a message? For example, I'd have thought this code might provide a useful start? For Each Item In Inbox.Items For Each Atmt In Item.Attachments ........... Next Atmt Next Item Obviously Inbox is wrong.

Once you've created your password, check for each illegal combination. When you find one then: - generate a random number between 1 and the length of the illegal string into N1 - generate a new random character into T1 (make sure it's different to the character in position N1 of the illegal string) - replace the N1th character of the illegal string with your new character - the string will then no longer be illegal Keep checking for illegal combinations (and replacing as per the above method) until there are none left.

It wouldn't be difficult to write such a password generator in ME. You'd need to specify how long, or between what lengths, you want the password to be. Using the function to generate a random integer number between 2 values, I would: - generate a random number N1 - generate a random number N2 - generate a random number N3 - generate a random number N4 - generate N1 random upper case letters into T1 - generate N2 random lower case letters into T2 - generate N3 random single-digit numbers into T3 - merge T1, T2 and T3 in some random way into T4 - create and display (or copy to the clipboard) a password of N4 characters by creating a string from T4 using a new random number in each pass until I'd got enough characters

No, actually, you should!

Try this: Text Type: <END> Delay 500ms Text Type: .csv Does that work?

I've just come across this setup, which might solve your problem in a more generic way. Scheduling a remote interactive session

I don't understand your point 2 above when taken in conjunction with your last sentence! How do you get a sequence of keystrokes or mouse movements if the machine is unattended or logged off. Are we writing a macro for ghosts here?

Shutdown Schdule this macro: Write Registry Value "%T[1]%" into HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon -- T1 contains 1 Write Registry Value "%T[99]%" into HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword -- T99 contains your login password Program Launch: "shutdown.exe" (Normal) Parameters: -s reboot -f -l 1 Once rebooted, schedule this macro to run on startup: Write Registry Value "%T[1]%" into HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon -- T1 contains 0 Delete Registry Value: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword

The error message you're seeing implies to me some sort of network lock rather than a password problem. Do you have the network sharing settings disabled? It's possible that Insight have changed this capability, but when I used ME3 I regularly deleted macros using code, even when the macro was password-protected, and I never knew any passwords because I generated the passwords via code from randomly-generated strings.

But what you can do is this: - Schedule a macro to allow Windows to boot without requiring a password this requires that you download a small free utility, and have your macro change 2 registry settings, run this utility and reboot - Schedule a startup macro to change the 2 registry settings above back to what they were this means that your computer is unprotected for only as long as it takes your computer to reboot - Run the macro you refer to in your message as the final step in your startup macro This macro is triggered only when the 2 registry settings were in the unprotected state - Lock your desktop when your macro is finished I have used this scenario for several years with great success.

If you want to have a folder containing 600 .ini files, then don't let us stop you! I'm quite interested to know why you need this as it's somewhat unusual. But there's no technical reason why you shouldn't adopt this approach.

In addition to Kevin's suggestion, you can also delete password-protected macros with another macro!