paul

Paul: I'm curious about that suggestion from you, which I've seen you make several times before. Why? If anything, it seems rather better IMO to use the full string. That avoids any ambiguity with other windows that might include the string 'notepad'. Such as this one I have on my desktop right now after testing Jace's macro: Macro Express Pro - Script Editor [Notepad problem]

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

When I create the more complex macros in MacExPro, I make one "main" macro that then calls a series of smaller macros to accomplish a series of tasks.

Good approach.

However this also seems to result in problems with variables. Even if you declare and type all your variables at the start of the "main" macro, the "child" macros know nothing about those variables (even if they have been explicitly typed as Global) so you have to declare them all over again in each macro that will use the variable, and try to avoid typos in the process! Helpfully, MacExPro does warn you if you forget to do this. But am I right that there is no way to get around this?

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

More generally, do the more experienced users on this forum agree that building a "modular" sequence of macros is the right way to go when addressing complex processes? Am I creating problems for myself by doing so?

Absolutely the right approach.

When I tried to stuff everything into a single macro, I was having quite a lot of trouble and in particular, it seemed that you cannot nest one "return" loop inside another. That seems rather unusual compared to other languages. Or perhaps I was doing something wrong.

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'm not quite sure how to implement the pseudocode, there is a "Repeat with Variable using %N1%" with a counter option, but I'm not sure how to use that, also since the entire script has to repeat will this throw it off?

 

Can you tell me how I would do this in the scripting editor?

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.

Hi Paul, actually that's what I tried to do originally but it didn't "take." I set a default value with "set string variable" in the Script window. I've just double checked and tried again, but no cigar.

 

Before pursuing this, it would help if you could answer a dumb question from me. You're posting examples of actual code. Where do you access that? So far, I've built my macros entirely using the "building blocks" provided by the Script Editor. It would actually help a lot if I could look at the code itself, and thereby figure out what I'm doing that's different from you.

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.

Thanks, I'll now be more careful in declaring variable types (I have gotten rather used to software that defines them on the fly if needed).

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

Edit: Might be on to something. Just found this in an export of my macro info:

D:\PGMFunctionsLibrary\PgmFL_Pro.mex

Looks like there are a bunch of references to D:\ in the PGM functions library.

 

Edit #2: There are 145 references in PGM Functions. Anyway to remove them all at once? Surely, I don't have to edit all the PGM macros and remove them individually.

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.

Thanks Paul, you've cracked it. I don't think I ever would have thought of that in a million years. If you manually type Ctrl-Shift-I it doesn't italicise but if you type Ctrl-I with Caps lock on it does. Much appreciated.

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

You may be pleased to know that we found the performance bottleneck. Apparently it was all in the variable processing routines. Specifically, there were more memory allocations and deallocations occurring than we really needed. This wasn't a problem in ME3 because the version of Delphi we used was for that version was faster at these memory allocations than the current version.

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

I actually just implemented a fix for this yesterday as we're finding that if a clipboard monitor is in place, the clipboard is not always "redrawn" properly. Apparently Microsoft's documentation concerning clipboard monitors is incorrect, so I've written up a slight modification to our monitor to "fix" it so that other programs aren't affected.

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.

Essentially, the idea is that a program should not come up into the foreground unless you started it from Explorer (i.e. the start menu, an explorer window, etc.). That way your workflow is not interrupted when a background program launches another program.

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.

Add to that fact, Vista and 7 added an additional quirk with the thumbnail previews of windows when you hover over their taskbar entries. In this case, the preview window is not marked as hidden and it has the same name as the window you're previewing. So, when we go to do our activation code, Windows will sometimes give us the preview window instead (most likely that's where your activations are going).

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!

Thanks. Just checking PGM library means Probabilistic Graphical Model library. How about ME3?

Is it hard to manage external .txt file for password?

It seems ME3 macros generate PW for individual target macros, how about ME3 macro which generating PW program, how is that protected?

Could you provide/attached a detailed sample?

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.