paul

The string "Notepad - Untitled" (FYI, on my Windows 7 system, the window is called "Untitled - Notepad") names 2 different states, one of which I surmise you're not interested in: - "Notepad" is the name of the program or window you're interested in locating; all notepad windows contain this string - "untitled" happens to be the name used for Notepad's initial unused window. Once you give this window a name, or if you open Notepad using an existing file, the name "untitled" disappears. Do you really want to tie your macro to Notepad only when it is in its initial state? In other words, you're including something which is probably not relevant to your macro, and which could change one day; it's something you have no control over, and which is probably not relevant to what you're trying to do. IMHO, it simply removes a dependency you don't need - which therefore makes it better practice. It's a bit like using a variable type naming convention, e.g. tTextVar, nIntegerVar - it's not necessary, but it makes for more readable code. Who knows? One day they may decide to change the name of this initial Notepad window to something else. That would catch you out, wouldn't it?

Here in Oz that key doesn't exist. The left-most key is ~ when shifted and ` when not - and MEP doesn't allow it to be a hotkey (unless Alt or Ctrl or Shift is pressed). The | is in the 2nd row at the far right (it's shift+\). The other character is nowhere to be seen.

I just tried with the Computer Management window in Windows 7. I get the same results as you, i.e. nothing happens with Open, but it works with Focus (but very slowly).

Good approach. Try these 2 scripts - they work as I expected. xx1 initializes 3 variables, displays them, calls xx2, then redisplays them. xx2 displays the variables, then modifies them, then displays them again. xx2 displays the same values as xx1, and xx1's second display correctly displays the modified values. <VARIABLE SET INTEGER Option="\x00" Destination="%nVar1%" Value="125"/> <VARIABLE SET BOOL Destination="%bVar2%" Command="263" Value="TRUE"/> <VARIABLE SET STRING Option="\x00" Destination="%tVar3%" Value="This is some text"/> <TEXT BOX DISPLAY Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang3081{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs16 xx1 1\r\n\\par \r\n\\par nVar1=%nVar1%\r\n\\par bVar2=%bVar2%\r\n\\par tVar3=%tVar3%\\f1 \r\n\\par }\r\n" Left="Center" Top="Center" Width="278" Height="200" Monitor="0" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/> <MACRO RUN Use_ID="FALSE" Name="xx2" ID="-1" Wait="TRUE"/> <TEXT BOX DISPLAY Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang3081{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs16 xx1 2\r\n\\par \r\n\\par nVar1=%nVar1%\r\n\\par bVar2=%bVar2%\r\n\\par tVar3=%tVar3%\\f1 \r\n\\par }\r\n" Left="Center" Top="Center" Width="278" Height="200" Monitor="0" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/> <TEXT BOX DISPLAY Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang3081{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs16 xx2 1\r\n\\par \r\n\\par nVar1=%nVar1%\r\n\\par bVar2=%bVar2%\r\n\\par tVar3=%tVar3%\\f1 \r\n\\par }\r\n" Left="Center" Top="Center" Width="278" Height="200" Monitor="0" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/> <VARIABLE SET INTEGER Option="\x00" Destination="%nVar1%" Value="112255"/> <VARIABLE SET BOOL Destination="%bVar2%" Command="263" Value="FALSE"/> <VARIABLE SET STRING Option="\x00" Destination="%tVar3%" Value="This is some more text"/> <TEXT BOX DISPLAY Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang3081{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs16 xx2 2\r\n\\par \r\n\\par nVar1=%nVar1%\r\n\\par bVar2=%bVar2%\r\n\\par tVar3=%tVar3%\\f1 \r\n\\par }\r\n" Left="Center" Top="Center" Width="278" Height="200" Monitor="0" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/> Absolutely the right approach. I don't follow. You can have nested Repeat loops without any problems. What am I missing?

Well done for putting the effort in and having success. You've gained far more by doing it yourself than having us send you a completed script, don't you think?

Your code in no way resembles mine! - You haven't changed the Output Results of the Multiple Menu command to Item Text - Your output variable is T1, and you have failed to preset its value - For some reason best known to yourself, you append T1 to every permitted Multiple Menu choice - Your variable NaturalOffset is not being used at all in the Multiple Menu command

I think you need to read the online help and study the many examples provided. I believe that I've provided an outline of the logic required to answer your question, but the task of learning how to write macros lies outside the scope of this forum.

I almost never access "actual code"! If you want to do that, simply click on the Direct editor icon. All I do is compose my macro, then select the code and Copy It (this shows the XML view of the code). You can also copy the command text by right-clicking (which gives you that first view of the code in my reply to you). And check the variables tab to see what your variable type is. BTW, wherever possible (which is almost always), I always include the initial and final % when referencing variables.

Actually, for "real" languages, i.e. compiled ones, allowing the language to define your variables is not considered good practice. One reason is efficiency, because the default type for undeclared variables is usually the least efficient, e.g. Variant. Another is debugging: if you require all variables to be predefined, then this code Dim Cabbage as String Dim i as Integer Cabage = "Some text" i = Len(Cabbage) will throw an error (as it should), whereas the other approach will cause you problems at run-time which may not be easy to find!

In pseudocode (I leave the detailed code to you): Your Main Repeat Loop Your processing code -- Here's the logic to hit the Down key one additional time at the end of each loop Increment variable N1 (i.e. Set N1 = N1 + 1) Repeat N1 times Text Type DOWN End Repeat End of your Main Repeat Loop In the first repeat execution you'll get one DOWN arrow. In the second, you'll get two DOWN arrows, etc.

Suppose the variable you're going to save your result into is called %tChoice%, and that you're going to save the text, not the value. Then simply set %tChoice% to any valid response before you display the menu, and you'll find it becomes the default choice. E.g. Variable Set String %tChoice% to "Two" Multiple Choice Menu: My Title Text Box Display: %tChoice% <VARIABLE SET STRING Option="\x00" Destination="%tChoice%" Value="Two"/> <MULTIPLE CHOICE MENU Style="\x00" Result="\x01" Dest="%tChoice%" Title="My Title" Prompt="Select one choice" Options="One\r\nTwo\r\nThree" Left="Center" Top="Center" Monitor="0" Width="443" Height="296" OnTop="FALSE"/> <TEXT BOX DISPLAY Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang3081{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs16 My choice was %tChoice%\\f1 \r\n\\par }\r\n" Left="Center" Top="Center" Width="278" Height="200" Monitor="0" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/>

No, it's not a bug. This happens when the first mention of the variable in the script (i.e. the reference that causes the variable to be created) is such that MEP is unable to determine what kind of variable it is. For example, if the 1st reference to variable %myvar% is Variable Set String %myvar% to topmost window title then %myvar% will be created as a text variable. But if instead you say Text Box Display --%myvar% then %myvar% could be any type of variable, so MEP creates it as a text variable, which may, or may not, be correct. You can always change the type of any variable by editing its definition in the Variables tab.

Given your familiarity with VB, I'd recommend investigating using AutoIt. - Its capabilities exceed VB Script - It interfaces well with MEP - There is a free forms package addin that you can use to design very elegant screens - It's free! - It's still being developed - There are some very powerful "extensions" written in AutoIt (User Functions) - If you're interested in handling web pages properly and pretty well error-free, there's an Internet Explorer set of functionality beyond anything I've seen elsewhere Some of us now take the view that AutoIt is the tool of choice for all the "heavy lifting" that MEP is unable to accomplish. AutoIt

None of these references should be relevant to your problem - I've just checked them all. The If test you found is used to determine whether the user is me, in which case I do, or do not, invoke certain logic. It should not be causing your problem. In order to prove this, I wrote a simple macro to see if T:\myfilename exists (I don't have a drive T:). The macro worked correctly and did not complain about no disk in a drive. I'm running Windows 7 x64 Home Premium.

Using either Open Folder or Open Folder in Explorer behaves identically: the folder appears immediately, but the subsequent dialog box I use to indicate the command has finished takes an additional 1.5 seconds or so on my dual core laptop.

Actually, if you think about it, it's not possible to type Ctrl-Shift-I unless you have Caps Lock down! Assuming we're not using Caps Lock, the only way you can get I instead of i is by pressing the Shift key. So really it's a choice between Ctrl-I and Ctrl-Shift-i, which is probably what the computer "sees". When you type the combination in, you're typing Ctrl-Shift-i; when you TextType Ctrl-Shift-I, you're not asking MEP to do the same thing.

Ah, you gave us all the clue, and none of us spotted it! I think you'll find this works: <TEXTTYPE:<CTRL>i> Use a lower-case i, not an upper-case I!

Have you tried the simpler <TEXTTYPE:<CTRL>I>?

Do you think this will also solve the problem of reading large files into a text variable and doing a replace all?

Windows 7's use of the clipboard appears to have changed from previous versions. I use ClipMate, and it has a feature called PowerPaste which allows you to have ClipMate return the currently selected clip and automatically move up or down to cause the next clip in the list to become active. Thus I can select PowerPaste, then press Ctrl-V 3 times and paste 3 different values from the clipboard. However, in Windows 7 (X64), the moving up and down the list of clips happens as soon as I select PowerPaste and before I've had a chance to paste any clip. Chris Thornton of ClipMate says this is caused by the clipboard having been reserved by some program, i.e. Windows 7 itself in this case.

I don't understand what you mean here. Suppose I start MyProg.exe from a shortcut. Are you saying its future behaviour will differ from MyProg.exe started by double-clicking it from Explorer? I have written many, many programs and not once have I observed this behaviour. Please clarify. Would this problem be resolved if you captured the handle of a window when it was created, and if you then added the necessary commands to allow us to capture this id and use it to activate windows, etc.?

Read Registry Value "HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\Device" into %tDefaultPrinter% Text Box Display: <READ REGISTRY VALUE Key="HKEY_CURRENT_USER\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Device" Destination="%tDefaultPrinter%"/> <TEXT BOX DISPLAY Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang3081{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs16 The default printer is %tDefaultPrinter%\\f1 \r\n\\par }\r\n" Left="Center" Top="Center" Width="278" Height="200" Monitor="0" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/>

Using DOpus I started a 4Gb copy from one drive to another. This game me time to develop the macro and then run it. It worked perfectly! Here's my code: <REPEAT UNTIL Variable="%nPixelCol%" Condition="\x00" Value="6956042"/> <GET PIXEL COLOR Option="\x01" Rel_To_Screen="TRUE" X="580" Y="425" Destination="%nPixelCol%"/> <DELAY Flags="\x01" Time="5"/> <END REPEAT/> <TEXT BOX DISPLAY Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang3081{\\fonttbl{\\f0\\fnil\\fcharset0 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs16 Should be 6956042\r\n\\par PixelCol = %nPixelCol%\\f1 \r\n\\par }\r\n" Left="Center" Top="Center" Width="278" Height="200" Monitor="0" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/> I presume you haven't fallen into the trap your code might imply? Your 1st mention of %PixelCol% will cause MEP to assign a text variable because there's nothing in the Repeat command to indicate what type of variable should be assigned. Mind you, if that did occur I wouldn't expect the Get Pixel Color command to compile. Ah, wait a minute. If your %PixelCol% variable is indeed a text variable and you haven't attempted to save this macro (syntax error message is generated), then you won't see the error message. And running it does indeed produce the behaviour you describe. BTW, does your wave file play? If so, then my syntax error message diagnosis is wrong, since the macro continued running. But I'm almost prepared to lay odds that it didn't! There's confidence for you!

PGM Library is a product we developed for ME3, and which you may still be able to discover on Insight's web pages. The development of this facility was complex, and certainly can't be described in detail in a couple of paragraphs. Several hundred lines of macro code are involved!

When we were developing the PGM Library for ME3, I developed some ME3 macros to allocate randomly-generated passwords to all of our library macros prior to distribution. For each target macro, a new password would be generated, assigned to its macro and recorded in an external .txt file kept only by myself and Joe. There was a complementary macro to unscramble the passwords if we needed to modify any macros. It worked well and seamlessly.