paul

I downloaded a trial version of Textpad and was able to activate the window, which was titled "TextPad - Document1 *", using Window Activate: *ext*Document1 * OR Window Activate: *ext*Doc* with "The name contains wildcards" ticked. However, this next example didn't work, so it looks as if the trailing asterisk is important! Window Activate: *ext*Doc

Yes, but the problem is how to get stuff echoed to the screen from within an HTA. Pure VBS offers the Wscript.echo command, but the Wscript environment is not available in HTAs. It is even possible to create a Wscript object and access its methods from within an HTA, but unfortunately Wscript.echo won't work using this method either. And examining the Multiple Field Input Form sample code doesn't teach me how to echo stuff to the screen.

Do you know how to write the command to obtain the length of a variable? If not, then I don't think I know how to help you. Populating a text variable and obtaining its length gives you the number of characters contained by the text variable. %tVar% = "this is a rabbit" Length of %tvar% is 16 therefore %tVar% contains 16 characters.

I'm running Windows 7 professional x64. I created a shortcut to UltraEdit (no compatibility mode set). I then ran this macro: Window Activate: [Edit1] - UltraEdit Text Type (Simulate Keystrokes): x and, as expected, an x duly appeared in the UltraEdit window. I then changed the properties of the shortcut, forcing Windows XP (service pack 3) compatibility, reran the shortcut, and reran the macro. It continued to work! But I see you're running MEP v1, whereas the current version is 4.2.2.1. As a general principle, I think you should always run the latest version of software unless you have a specific reason not to. For MEP, I'd emphasize this advice even more.

Quite honestly, Cory, I have virtually given up on ISS! They show little interest in anything I have reported to them in the last 1-2 years, and I get no feedback from them apart from the problem registration email. And who knows whether my ability to replicate the problem most of the time is unique to my machine? If I were in tech. support and received a submission from a user along the lines of what I would report in this instance, I (the support guy) would throw up my hands in horror!

Have 2 copies of your macro file, 1 for ME3 and one for conversion to MEP. I don't see your problem.

I don't understand your question!

I have chosen to call my variable %tClip%. You can call it %T[1]% if you like, the difference being that your variable forms the 1st element of an array. Let me describe the process to you like this: On my clipboard is this text: The quick brown fox jumps over the lazy dog This text consists of 4 lines, each of which ends with 2 invisible characters (carriage return = ASCII 13, line feed = ASCII 10) So this text is exactly 48 characters long (35 non-space characters, 5 spaces, 4 carriage returns, 4 line feeds). If you store this text in a variable, its length will be 48 characters. If you now change all carriage return/line feed combinations to nothing, the length of the variable will become 40 (35 non-space characters, 5 spaces, 0 carriage returns, 0 line feeds). If you now subtract the new length of 40 from the original length of 48, you get 8. If you now divide 8 by 2 (2, because we removed 2 characters for each line), you get 4 - which is the answer to your original question "how many lines of text do I have?".

I can cause this problem to occur, almost on demand! In one window I have Directory Opus or Explorer open, and in another I have VideoRedo, which has just finished saving a video file in Mpeg 2 format. Now, in window one, I navigate to the next video file I want to edit, and the MEP freeze happens, 90% of the time, while moving the cursor. Note that MEP is not being used for anything, it's simply loaded (Windows 7 Professional, x64).

This question doesn't make sense! %tClip% is the name of a text variable, into which I have copied the contents of the clipboard (see 1st line of my suggestions).

What's wrong with taking a copy of your ME3 macro file before converting? My take on MEP differs from Cory's. Although there are many new features in MEP (some of which are, or ought to be, very powerful and useful), several of them require some effort to learn, and in all cases you'll have to rework/rewrite your macros to take advantage of them. And you can't miss what you've never used! If your ME3 macros are all satisfactory, then I'd be inclined not to upgrade - MEP is still very buggy and doesn't seem to receive the same degree of attention from Insight as ME3 certainly used to. Many of its operations are far slower than they are in ME3, and some simply don't work properly (the worst example of this is running a macro directly from a variable; if you make use of this feature in ME3, then you should forget MEP altogether). And many of us experience an ongoing problem where MEP causes the machine to go very slowly indeed until it's terminated and restarted (and this is one of many problems Insight seems to have no interest or ability to resolve). MEP is a very mixed bag.

- Save the contents of the clipboard to a variable, e.g. %tClip% - Save Ascii 13 to a variable, e.g. %tCr% - Save Ascii 10 to a variable, e.g. %tLf% - Save the length of %tClip% into a variable, e.g. %nLen% - Replace all %tCr%%tLf% with "" (i.e. a zero-length string) in %tClip% - Save the new length of %tClip% into a variable, e.g. %nLenNew% - Subtract %nLenNew% from %nLen% into a variable, e.g. %nDiff% - Divide %nDiff% by 2 - and this is your answer Beware of any final line in the clipboard - if it doesn't end with %tCr%%tLf%, then you'll need to allow for this (e.g. extract the last 2 characters of %tClip% and compare with %tCr%%tLf% - if unequal, append %tCr%%tLf% to %tClip%).

If I understand you correctly, then you have this calling hierarchy of macros: Macro A -- Macro B -- Macro C ---- Macro D I assume that a decimal variable %DTV% is declared in each macro, and that when one macro calls another, it always waits for the called macro to finish. I have created the following code, and it works as expected. In other words, the two display boxes of the value of %dtv% in both macros D and A show the same value of 0.5. My guess is that you may not have declared %dtv% in Macro A when you first tested your code, in which case it may be that MEP has got confused (MEP gets quite easily confused about variables if they're not declared right the first time). If I'm right, I suggest recreating the 4 macros, making sure you declare the relevant shared variables right the first time (you can easily copy the code from your existing macros to the new ones). MacroA ------ Macro Run: MacroB Macro Run: MacroC Text Box Display: MacroA MacroB ------ Variable Set Decimal dtv to 1.05 MacroC ------ Macro Run: MacroD MacroD ------ Variable Modify Decimal: %dtv% = %dtv% - .55 Text Box Display: MacroD MacroA ------ <MACRO RUN Use_ID="FALSE" Name="MacroB" ID="-1" Wait="TRUE"/> <MACRO RUN Use_ID="FALSE" Name="MacroC" ID="-1" Wait="TRUE"/> <TEXT BOX DISPLAY Title="MacroA" Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang3081{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs16 dtv = %dtv%\\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"/> MacroB ------ <VARIABLE SET DECIMAL Option="\x00" Destination="dtv" Value="1.05"/> MacroC ------ <MACRO RUN Use_ID="FALSE" Name="MacroD" ID="-1" Wait="TRUE"/> MacroD ------ <VARIABLE MODIFY DECIMAL Option="\x01" Destination="%dtv%" Value1="%dtv%" Value2=".55"/> <TEXT BOX DISPLAY Title="MacroD" Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang3081{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs16 dtv = %dtv%\\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"/>

Repeat 8 times Text Type <DELETE> End Repeat

I've tried this example: - Macro M1 global, Ctrl-Shift-K - Macro M2 notepad window specific, Ctrl-Shift-K - Macro M2 notepad program specific, Ctrl-Shift-K I am unable to get more than one of these macros to run when Ctrl-Shift-K is pressed: - if notepad is not running, M1 fires - if notepad is running and focused, m2 starts - in order for m3 to start, m2's scope is changed to, say, xnotepad If these observations are correct, then I think that answers your question. Do you experience the same sequence of events?

Suppose you have 2 macros, M1 and M2, where both run with ALt-E and where M1 is global, M2 is program specific. Remove M2's Alt-E activation, and put your If Window Focused test for the M2 window at the beginning of M1. If the window is focused, simply have M1 call M2 and exit M1. I don't think that's so complicated. When M1 calls M1, have M1 not wait for M2 to complete. You could even automate this. Instead of M1 and M2, call them M1 and M1 [xxx], where xxx is the name of the window you're checking for focus. Now, in M1, simply check for the existence of macro M1 [xxx] and call it if it exists, otherwise continue with M1. You could use this approach for all macros which have both specific window and global hotkey activation.

Redwards' suggestion about making the taskbar taller is a good one, and what I've done too. This does work most of the time - occasionally Forrest remains and I then close and restart ME to get rid of it.

Unfortunately, the only way reliably to see Forrest any time a macro is running is to force W7 to display all icons all the time. While this may be a bug in Macro Express (God knows there far too many of these in ME Pro, few of which seem to get fixed these days), I believe it's more likely to be a problem in W7. My tray currently has 17 icons on display, which isn't so bad considering I have 3 monitors.

Well, my congratulations to you in working your way towards a satisfactory solution based on a 3rd party suggestion! This is refreshingly different from so many participants in these forums, who simply expect someone else to do all the work. I'm glad it's all working well for you.

Have you thought about loading the ME macro into a variable and using the Run Macro In Variable command? In ME3, this command works exceedingly well, whereas be warned that it's almost completely useless in ME4 (ME Pro) because Insight never thought about the design of this feature and forgor to implement user variables correctly in this feature! I have loaded variables and run macros from them of considerable length and complexity in ME3 with great success.

For which part of this process do you need suggestions? None of this looks particularly difficult - as a last resort you could record the keystrokes you use when you do this manually. My advice is always to use menus if possible, e.g. to invoke the direct editor you could locate the icon and click on it, or (in Macro Express Pro) you can use the menu option View. I have written many macros that manipulate Macro Express itself, and most of these have been relatively straight-forward.

There is a way to achieve what you want, but it's slightly tricky! You need 2 macros for this: Macro1 Macro Run: Macro2 Window Activate: Notepad Delay: 1 seconds Repeat Until %n[1]% Does not Equal "%n[1]%" If Not Window "Respond Y or N" is running Repeat Exit End If End Repeat Macro2 Multiple Choice Menu: Respond Y or N code to process Accept or Undo - In my example, I'm activating Notepad rather than your open document - The window title in the Repeat loop must match the title of your multiple choice menu - It is essential that the macro run statement in Macro1 does not wait for Macro2 to terminate before proceeding - The multiple choice menu statement must be in a separate macro, otherwise you cannot return focus to your document window - The logic to process Accept or Undo is in Macro2, which is the only macro to know what the user response was; you either have to click on the menu choice you want, then press Enter, or, in my example, you can activate the menu window and press Alt-y or Alt-n followed by Enter. If you were happy to write a small amount of AutoIt code, then I imagine the whole thing could be made more elegant and less clunky. And here's the actual code: Macro1 <MACRO RUN Use_ID="FALSE" Name="Macro2" ID="-1" Wait="FALSE"/> <WINDOW ACTIVATE Title="Notepad" Exact_Match="FALSE" Wildcards="FALSE" _IGNORE="0x0006"/> <DELAY Flags="\x01" Time="1"/> <REPEAT UNTIL Variable="%n[1]%" Condition="\x01" Value="%n[1]%"/> <IF NOT WINDOW Option="\x01" Title="Respond Y or N" Partial="TRUE" Wildcards="FALSE"/> <REPEAT EXIT/> <END IF/> <END REPEAT/> Macro2 <MULTIPLE CHOICE MENU Style="\x00" Result="\x01" Dest="%tResponse%" Title="Respond Y or N" Prompt="Do you want to accept the result?" Options="&Yes\r\n&No" Left="Center" Top="Center" Monitor="0" Width="443" Height="296" OnTop="TRUE"/>

This works under Windows 7 too. If you use this approach, I'd also write a macro to re-enable the mouse, activated by a hotkey, just in case the originating macro crashes. Disable mouse

There are 2 main approaches to consider: - You can write a macro that is activated when you click your mouse to navigate to the next record. Each time the macro runs it needs to read in the record number last used (from the registry, or from a file, or from an environment variable), increment that counter by one, and then do whatever processing you have determined is needed. - Or you can write a macro that remains in control of the whole process of navigating your records; in this case it must navigate to the next record by clicking the mouse in the relevant area of your screen; you could trigger this next record activity by having the macro wait for a specified keystroke - e.g. N for Next record, or PgDn - and then take the appropriate action, or by presenting a menu - e.g. Next Record, Previous Record perhaps?, etc. The first method results in your macro running each time you navigate to the next record, while the second approach has your macro being run only once, remaining in control until you exit it, e.g. using the Esc key if you adopt the menu approach. In the second approach your macro can navigate to the relevant web page, etc.

Sorry, please can you repeat it? From your latest screenshot I now see you haven't got the Stop button anywhere on any toolbar. So it must be in your customize window - did you try scrolling down to the bottom (on my machine the Stop button, when not located on a toolbar, is the last button in the customize window). Yes, I always close FF before editing any user files. And I now see I wasn't addressing the userchrome.css file, but rather the usercontent.css file. And here are my screenshots for your enjoyment!