IfWindowOpen seems to run slower in version 12.0.5 vs. 11.x

[twardega]

It appears that IfWindowOpen call is taking a longer time when the code is compilied in v. 12 vs. 11. I use IfWindowOpen to check if another instance of the program is running. Please let me know if you can suggest a workaround.

// AcctType and Appl are passed as command-line arguments. Here: defined as variables to simplify code
Let>AcctType=1
Let>Appl=XYZ
// This section prevents having many instances of the program at the same time - this seems to cause performance delays
// in v. 12
If>{(%Appl%="XYZ") OR (%Appl%="")}
IfWindowOpen>LTAX Screen Selector
SetFocus>LTAX Screen Selector
Wait>0.2
GoTo>ExitProg
EndIf
EndIf
// Define dialog box for selecting target Application Screen
Dialog>Dialog1
Caption=LTAX Screen Selector
Width=210
Height=180
Resize=0
Top=%PosY%
Left=%PosX%
ListBox=msListBox1,0,0,201,148,
EndDialog>Dialog1

If>{(%AcctType%Dialog1.msListBox1.ITEMS.TEXT=Account Maintenance%CRLF%Account Cash and Liability%CRLF%Account Letter Request%CRLF%Collection Maintenance%CRLF%Legal Maintenance%CRLF%In%CRLF%Lunch%CRLF%Out
Else
Let>Dialog1.msListBox1.ITEMS.TEXT=In%CRLF%Lunch%CRLF%Out
EndIf
OnEvent>DIALOG_CHANGE,Dialog1,msListBox1,GetLTAXTargetScreen
ResetDialogAction>Dialog1

Show>Dialog1

Label>ActionLoop1
Wait>0.1
// Check for 'window closed' action (r=2) - in case user clicks the 'X' on the window
GetDialogAction>Dialog1,r
If>%r%=2,ExitProg
Goto>ActionLoop1
Label>LTAXScreenSelected
// ... here comes the code for handling contect sensitive app links ...
Label>ExitProg

SRT>GetLTAXTargetScreen
GetDialogAction>Dialog1,LTAXDest
Let>LTAXDest=%Dialog1.msListBox1%
CloseDialog>Dialog1
Let>IGNOREERRORS=1
Goto>LTAXScreenSelected
END>GetLTAXTargetScreen

[JRL]

No idea why IfWindowOpen> would run more slowly in v12 than it does in v11. But another method would be to detect the process. I've added to your code a script chunk from a Scripts and Tips post by Marcus that uses VBScript to detect how many instances of a process are running. If the number is greater than 1, this process quits.

Code: Select all

//Marcus code from:
//http://www.mjtnet.com/usergroup/viewtopic.php?t=2574

//Set next line to the name of your executable
Let>proc=NameToDetect.exe


VBSTART
'returns the number of copies of ProcessName that are running
'will return 0 if ProcessName is not running
Function IsProcessRunning(ProcessName)
    Set oWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\.\root\cimv2")
    Set colProcessList = oWMIService.ExecQuery ("Select Name from Win32_Process where Name='" & ProcessName & "'")
    IsProcessRunning = colProcessList.count
End Function
VBEND

VBEval>IsProcessRunning("%proc%"),numFTPs
If>numFTPs>1
  GoTo>ExitProg
EndIf

/*
// AcctType and Appl are passed as command-line arguments. Here: defined as variables to simplify code
Let>AcctType=1
Let>Appl=XYZ
// This section prevents having many instances of the program at the same time - this seems to cause performance delays
// in v. 12
If>{(%Appl%="XYZ") OR (%Appl%="")}
IfWindowOpen>LTAX Screen Selector
SetFocus>LTAX Screen Selector
Wait>0.2
GoTo>ExitProg
EndIf
EndIf
*/

// Define dialog box for selecting target Application Screen
Dialog>Dialog1
Caption=LTAX Screen Selector
Width=210
Height=180
Resize=0
Top=%PosY%
Left=%PosX%
ListBox=msListBox1,0,0,201,148,
EndDialog>Dialog1
If>{(%AcctType%<Let>Dialog1.msListBox1.ITEMS.TEXT=Account Maintenance%CRLF%Account Cash and Liability%CRLF%Account Letter Request%CRLF%Collection Maintenance%CRLF%Legal Maintenance%CRLF%In%CRLF%Lunch%CRLF%Out
Else
Let>Dialog1.msListBox1.ITEMS.TEXT=In%CRLF%Lunch%CRLF%Out
EndIf
OnEvent>DIALOG_CHANGE,Dialog1,msListBox1,GetLTAXTargetScreen
ResetDialogAction>Dialog1
Show>Dialog1
Label>ActionLoop1
Wait>0.1
// Check for 'window closed' action (r=2) - in case user clicks the 'X' on the window
GetDialogAction>Dialog1,r
If>%r%=2,ExitProg
Goto>ActionLoop1
Label>LTAXScreenSelected
// ... here comes the code for handling contect sensitive app links ...
Label>ExitProg
SRT>GetLTAXTargetScreen
GetDialogAction>Dialog1,LTAXDest
Let>LTAXDest=%Dialog1.msListBox1%
CloseDialog>Dialog1
Let>IGNOREERRORS=1
Goto>LTAXScreenSelected
END>GetLTAXTargetScreen

[bnc1]

I found something similar starting with MS 11.1.17
Check this thread http://www.mjtnet.com/forum/viewtopic.php?t=6300

Also the Help file for WaitWindowOpen contains notes on system variable WF_TYPE. I changed some of my scripts to use WF_TYPE=2 and was able to improve performance somewhat.

" It is possible to limit the type of windows this command affects using he WF_TYPE variable: "
Let>WF_TYPE=0 - No Child Windows
Let>WF_TYPE=1 - ALL Windows (Default)
Let>WF_TYPE=2 - Visible Windows Only
Let>WF_TYPE=3 - Child Windows Only

[twardega]

Thanks for your replies.

I tested suggestion for setting WF_TYPE=2 and the response is still noticeably slower than when compiled with version 11.1.10 (that I keep to do my production build...)

The process lookup fixes the issue at hand (but it does not make IfWindowOpen faster...)

[JRL]

I made a little test script last night to find out if there was anything to this thought that IfWindowOpen> is running slower than it used to. My home computer is a 2.4 Ghz single core with 512 meg RAM. Not exactly a screamer. I'm running Win XP SP2 and I have Macro Scheduler Version 12.0.2 installed. Each time I ran the test script below, whether compiled or uncompiled I got a result in the neighborhood of 0.04 seconds. If I compiled the script in version 11 I got about the same result.

Today when I run the same script in Version 12.0.5 on my work computer that is a 2.4 Ghz dual core with 2 gig RAM. I get a result that is consistently about 0.5 seconds. More than 10 times slower.

This suggested that a change occurred sometime between the release of version 12.0.2 and version 12.0.5. So I reinstalled version 12.0.4 and on my work computer the script below runs in 0.03 seconds. This would suggest to me that something changed with the release of version 12.0.5.

Hopefully this information will be useful.

Code: Select all

VBSTART
VBEND

Run>notepad.exe
VBEval>timer,StartTime
Label>Loop
IfWindowOpen>NotePad*
  VBEval>timer-%StartTime%,TotalTime
  Goto>Continue
Else
  Goto>Loop
EndIf

Label>Continue
SetFocus>NotePad*
Press ALT
Press F4
Release ALT
MDL>TotalTime

[Marcus Tettmar]

This is probably because of this:
http://www.mjtnet.com/forum/viewtopic.php?t=6300

In order to address the above we added a sleep to the loops in order to make the process hog the CPU less. Of course the downside of this is that it may now run slower. However, it also should mean other apps (i.e. the one being automated) might be more responsive, and therefore the overall automation may be quicker.

We're in a catch 22. So I think for a future release we'll add an option variable which will allow you to set whether the window functions should be tight (higher CPU usage but potentially faster) or loose (slower but less likely to hog the CPU).

[jpuziano]

We're in a catch 22. So I think for a future release we'll add an option variable which will allow you to set whether the window functions should be tight (higher CPU usage but potentially faster) or loose (slower but less likely to hog the CPU).

Thanks Marcus, that's great as it puts control back into the hands of the writer of the macro.

However instead of just a binary "loose" or "tight" switch, please consider giving us a System Variable we can set to the number of milliseconds of delay we want.

- You could set the default to a middle-ground value that provides a good compromise on most systems

- Help should say what the default value in milliseconds is

- You can offer advice in the help as to the practical range for the value

- Help could also mention the user might want to try different values to "tune" for best performance

Thanks for your consideration and take care...

[Marcus Tettmar]

No, there's no point in setting a number of milliseconds. No benefit at all. We're not talking about a delay, we're talking about making the loop yield, or not. Adding in a delay serves no purpose and has no benefit at all. If you want a delay use a Wait command.

[jpuziano]

We're not talking about a delay, we're talking about making the loop yield, or not.

Ahh... thanks for clarifying.

[twardega]

Thanks for all the posts and a new option in version 12.0.6 (WIN_SLEEP).

Currently I am using WaitWindowOpen in the code that does not have to perform fast. However, I started using a different approach in the code that must perform fast. Instead of using:

WaitWindowOpen>%WinTitle%

I am using the following:

Let>LoopCount=0
Label>WaitWindowLoop
Let>LoopCount=%LoopCount%+1
Wait>0.2
Let>WIN_USEHANDLE=1
GetActiveWindow>WinHandle,,,,
GetWindowText>%WinHandle%,WinText
Let>WIN_USEHANDLE=0
Position>Some unique text in the window,%WinText%,1,StartPos
If>{(%StartPos%=0) AND (%LoopCount%{(%StartPos%=0) AND (%LoopCount%>15)},EndWait
.... SOME CODE ....
Label>EndWait

Personally I was not able to reproduce the 'slowness' issues with WaitWindowOpen on my development PC, but I witnessed it on the PCs of the users of my macros. I am not getting any complaints after I replaced WaitWindowOpen with the code above.