Window Activate

[Amerifax-Bob]

Window Activate: C:\Uty\Software\MacroExpressPro

Delay: 450 milliseconds

Wait for Window Title: *UltraEdit

Mouse Left Click

 

I have tried many different ways to activate the above Window. I tried several other windows all not workable. The above lines are just a few of the ways I try to execute line 1.

 

On Save

The macro's scope is set to Window/Program Specific and there are no programs or Windows assigned

 

Bob

[acantor]

The problem is probably in the "Window Activate" line. The line itself, under normal conditions, should be sufficient.

 

Double check that the words "C:\Uty\Software\MacroExpressPro" appear in the title bar of the window you want to bring to the fore.

 

Make sure you are using "Partial Match" or "Exact Match" appropriately.

 

Avoid the wildcard option for now, as it complicates matters. Simplify for debugging purposes.

 

Similarly, set the scope to "Global" for now. If it's set to Window or Program specific, it's harder to separate coding from scoping issues.

 

Instead of using Window Activate, you might also try Program Activate.

 

If all else fails, delete the macro and start from scratch. After monkeying around with a ME script over and over again, starting afresh can bring a new perspective.

[Samrae]

The macro's scope is set to Window/Program Specific and there are no programs or Windows assigned

This can happen when you create a new macro with a hotkey that is already in use in one of your other macros.

[Cory]

If you manually run just the first line does it activate the window?

 

One thing to watch for are hidden windows. They often appear before the visible window. Create a macro that uses the Repeat With Windows" command and log each window title in a file. Open that file and you can see all the hidden windows and possibly a clue why the Windows Activate is not working.

 

Also we would be able to help you better if you created a simple macro that demonstrates the problem with a simple common application like Notepad.

[jrgreenman]

I think I'm having a similar problem. I open an Outlook folder whose window title is "PubContacts - Business in Public Folders - Microsoft Outlook" and then attempt to "Activate" the window using "Partial Match" and the string "PubContacts - Business". But it fails consistently, even if I have just a one-line macro containing the Activate command.

 

In the past, this has been affected by the existence of hidden windows with conflicting titles. And sure enough, when I look at the hidden windows, I find two additinioal hidden with the same title.

 

So far, I've never had a need to access hidden windows. They have always just been something I have to work around.

 

Is there way to tell the Activate command to ignore hidden windows and just activate the visible window?

 

Jace

[paul]

I think I'm having a similar problem. I open an Outlook folder whose window title is "PubContacts - Business in Public Folders - Microsoft Outlook" and then attempt to "Activate" the window using "Partial Match" and the string "PubContacts - Business". But it fails consistently, even if I have just a one-line macro containing the Activate command.

 

In the past, this has been affected by the existence of hidden windows with conflicting titles. And sure enough, when I look at the hidden windows, I find two additinioal hidden with the same title.

 

So far, I've never had a need to access hidden windows. They have always just been something I have to work around.

 

Is there way to tell the Activate command to ignore hidden windows and just activate the visible window?

OK, please try this AutoIt code and let me know if it's successful (it works for me with UltraEdit, but I don't have Outlook, and its behaviour may be quite different).

Variable Set String %tWinTitle% to "PubContacts - Business"
External Script: AutoIt

<VARIABLE SET STRING Option="\x00" Destination="%tWinTitle%" Value="PubContacts - Business" NoEmbeddedVars="FALSE"/>
<EXTERNAL SCRIPT Language="AutoIt" Dest="%tOutput%" Script="$winnames = WinList($CmdLine[1])\r\nfor $i = 1 To $winnames[0][0]\r\n  $state = WinGetState($winnames[$i][1])\r\n  If 2 = BitAND(2, $state) Then ExitLoop\r\nNext\r\nWinActivate($winnames[$i][1])" Parameters="%tWinTitle%" Encoding="0"/>

How it works (if it does! ):

Set %tWinTitle% to the starting text of some visible window (note: it must already be visible, and there should only be one such visible window).

 

The AutoIt code retrieves all windows (titles and handles) starting with the specified string. It then examines each window (using the handle) to determine whether that window is visible. If it is, then it makes that window active.

 

I haven't included any error checking in this code - that can be done later.

[jrgreenman]

Paul, thanks for the tip. I can't use AutoIt at this point because I am sharing macros throughout my organization and installing AutoIt on all the employees' PCs so that this works for everyone creates a maintenance issue my IT folks won't sign up for.

 

But I was able to make use of Window Handles in order to overcome my current issue. As long as the issue doesn't become chronic, using MEP's Window Handle capability might do the trick.

 

But I do hope they update MEP at some point to address the underlying issue of not having a way to prevent hidden windows interfering with visible windows.

 

Thanks again for the input.

 

Jace

[paul]

I sympathise! It is possible to compile an AutoIt macro into so-called executable code, meaning AutoIt is no longer required to be installed (except on your machine of course). Then you'd have your macro running this .exe to activate the desired window. But, knowing IT departments as I do, I daresay they'd object.

 

How IT was ever allowed to take control of the PC to the extent they have is utterly beyond me (and I worked in IT for several years). I suppose PC should be renamed to IC!