AutoIt bot needs display

[pranaynanda]

I have an AutoIt bot that we use to perform "performance tests" on our commercial application using TimerDiff(). We run that bot on multiple systems across the globe. To monitor the tests, we use Remote Desktop Connection Manager. Why is it that when I expand a display or do not provide display at all, the tests start failing? A simple task such as ControlSend() or ControlFocus() fails that we use for login use case. Is my assumption true that AutoIt needs display to be there to be able to find an instance? Is there any alternative as it cannot be always possible to provide a display to those scripts.

EDIT: Also for reasons, I sometimes think that the scripts are unstable as they seem to pause at random places even if no condition relating to wait exists at that point.

Edited June 13, 2016 by pranaynanda

[TheDcoder]

It is tricky to automate things without a display... There might be alternatives to K&M (Keyboard and Mouse) automation to perform your "performance test" .

 

Can you please elaborate on what kind of performance tests?

[pranaynanda]

Just some clicks here and there to check how much time a particular use case takes. Opening this file in that module.... That kind of tests.

[TheDcoder]

Oh , I am afraid that, that kind of tests don't have an alternative... I was hoping for something which can be interacted programmatically (like commandline execution, COM API etc.)

[pranaynanda]

Yeah. That's the thing. So I should take that a display is a must?

Edited June 13, 2016 by pranaynanda

[TheDcoder]

I don't know, I am not very experienced with K&M automation . Someone more qualified than me will answer your question

[pranaynanda]

Sure. Thanks

[TheDcoder]

My pleasure

[orbs]

2 hours ago, pranaynanda said:

Is my assumption true that AutoIt needs display to be there to be able to find an instance?

@pranaynanda,

in general, that is a clear No. AutoIt does not need a display. however in specific, that depends on what you are doing. if you try to retrieve screen resolution without a display, you need not expect it to work. if you automate a GUI of another application, then that application may not present its GUI if there is no display.

fortunately, these are all issues which should be easy to eliminate. first, does your app have a GUI? write the result of WinExist to a file while you run your script with and without display, compare the results.

next, does your script uses commands or functions that imply a display is present? that is your script, you should know. if you are unsure as to a specific command or function, then ask here, or better - try for yourself.

B.T.W that should also give you a better insight on your last comment:

2 hours ago, pranaynanda said:

Also for reasons, I sometimes think that the scripts are unstable as they seem to pause at random places even if no condition relating to wait exists at that point.

and regarding:

2 hours ago, pranaynanda said:

A simple task such as ControlSend() or ControlFocus() fails that we use for login use case.

please explain. are you referring to Windows logon?

[pranaynanda]

17 hours ago, orbs said:

does your app have a GU

Yes it does.

 

17 hours ago, orbs said:

if you automate a GUI of another application, then that application may not present its GUI if there is no display.

I'm trying to automate to automate GUI of another application. The application presents its GUI if there is no display.

 

17 hours ago, orbs said:

does your script uses commands or functions that imply a display is present?

Yes. It frequently uses WinExists, WinActive, WinActivate, WinWaitActive, WinWait and other similar statements.

17 hours ago, orbs said:

B.T.W that should also give you a better insight on your last comment:

19 hours ago, pranaynanda said:

Also for reasons, I sometimes think that the scripts are unstable as they seem to pause at random places even if no condition relating to wait exists at that point.

There are some points where I use Send statements, but the script is paused and does not move further. There is nothing like WinExists, WinActive, WinActivate, WinWaitActive or WinWait at that point of code.

 

17 hours ago, orbs said:

and regarding:

19 hours ago, pranaynanda said:

A simple task such as ControlSend() or ControlFocus() fails that we use for login use case.

please explain. are you referring to Windows logon?

No. I'm not referring to Windows logon. It's the login screen on the application's GUI. I use ControlSend() and ControlFocus() to enter credentials.

[argumentum]

Run a CMD window. Run SET. look for SESSIONNAME, it should read SESSIONNAME=Console , otherwise, there is no desktop. So, remote in, shadow the console session and everything will be ok. No need for a physical monitor attached, just a console session.

[pranaynanda]

@argumentum SESSIONNAME=RDP-TCP#0. What do I make of it?

[TheSaint]

Hi pranaynanda.

Unless we have some code to work with, much is just conjecture, and trying to determine what is needed or what is maybe going wrong, is like extracting a tooth.

[orbs]

@pranaynanda,

On 6/14/2016 at 8:21 AM, pranaynanda said:

The application presents its GUI if there is no display.

how did you test for that? 

i'm asking, because one way to test for that would be to launch an AutoIt script to enumerate opened windows (and possibly determine which window belongs to the tested application). now, if it does detect the said window, then you can compare the properties of the window and of the controls in GUI mode vs. headless mode. if it does not, then either the application does not have an opened window, or your script runs in a different session. which leads us to:

is your tested application running completely in a user session? or is it composed of a back-end engine and a front-end GUI, which may alternate user sessions?

to answer that let's first answer this: how do you launch the tested application, and how do you launch the AutoIt script?

[pranaynanda]

2 minutes ago, orbs said:

how do you launch the tested application, and how do you launch the AutoIt script?

The AutoIt script is launched by a vbs which is called by a batch file. That is a batch file is executed which calls a vbs and the vbs calls a  series of different AutoIt use case scripts. The first AutoIt use case script is the launch script which works perfectly. I can say that because we log if the use case was successful or not. Then comes the login part which fails. The error produced is the one which is of a timeout.

9 minutes ago, orbs said:

On 6/14/2016 at 10:51 AM, pranaynanda said:

The application presents its GUI if there is no display.

how did you test for that? 

I know that because the launch is successful and it produces a GUI, sends some primitive information about what environment to log in to, hits an Enter button,  waits for the next screen, produces a messagebox and finally logs it. And we always have a successful launch case. The login case fails and therefore we cannot proceed further.

17 minutes ago, orbs said:

you can compare the properties of the window and of the controls in GUI mode vs. headless mode. if it does not

That is interesting. I'm willing to try that. Can you help me with that? Any ideas on how to retrieve the properties in headless mode?

[orbs]

2 minutes ago, pranaynanda said:

Any ideas on how to retrieve the properties in headless mode?

exactly like in GUI mode.

but first, let's see if i follow:

4 minutes ago, pranaynanda said:

... launch is successful and it produces a GUI, sends some primitive information about what environment to log in to, hits an Enter button,  waits for the next screen, produces a messagebox and finally logs it. And we always have a successful launch case. The login case fails ...

so the same AutoIt script can handle the "login" GUI (whether in display mode or headless mode), and can handle the "main" GUI when running in display mode, but fails the "main" GUI in headless mode?

[pranaynanda]

6 minutes ago, orbs said:

so the same AutoIt script can handle the "login" GUI (whether in display mode or headless mode), and can handle the "main" GUI when running in display mode, but fails the "main" GUI in headless mode?

YES!

Some correction to that is the same AutoIt script can handle the "launch" GUI (whether in display mode or headless mode). And those are two different scripts for launch and login but the same vbs which calls them both.

EDIT: The Options are same across all use cases.

Edited June 15, 2016 by pranaynanda

[orbs]

in headless mode, which is the last action that you know for a fact that works correctly?

1) the vbs launches the "login" script.

2) the "login" script starts.

3) the "login" script detects the application "login" window.

4) the "login" script detects the relevant controls in the application "login" window.

is this your process, or is there anything i missed in the middle?

EDIT: sorry, i replaced the "main" for the "login".

Edited June 15, 2016 by orbs

[pranaynanda]

I guess you're getting confused. There are two scripts here. "Launch" and "Login". The process you say is correct.

1) the vbs launches the "launch" script.

2) the "launch" script starts.

3) the "launch" script detects the application "login" window.

4a) the "launch" script detects the relevant control in the application "launch" window.

4b) the "launch" script enters primitive details about the environment and clicks the ok button.

Then a different window appears. The "launch" script has a WinActivate() and WinWaitActive() clause for detecting this different window. Once it detects this window and activates it, it gives a message and logs it. This case is always successful. And this is the last point that I'm aware of working correctly in headless mode.

Here the vbs is done with the launch script.  It starts the "login" script hereafter.

5a) the "login" script puts focus on the username field.

5b) the "login" script sends the username to the username field.

6a) the "login" script puts focus on the password field.

6b) the "login" script sends the password to the username field.

7a) the "login" script puts focus on the OK button.

7b) the "login" script send a click to the OK button.

Processes from 5a to 7b are successful with a display but fail without a display.

EDIT: I tried using CamStudio to record what exactly happens when there is no display. It was foolish of me to even try that as I soon learnt that screen recording applications need displays. Any alternative suggestions to do that?

Edited June 15, 2016 by pranaynanda

[orbs]

sorry, i was indeed a bit confused. but i did mention two steps that your description mentions as such:

7 minutes ago, pranaynanda said:

Here the vbs is done with the launch script.  It starts the "login" script hereafter.

i.e.,

1) the vbs launches the "login" script.

2) the "login" script starts.

are you certain these steps work correctly in headless mode?

specifically, does your "login" script have something like this at its top:

FileWriteLine($sLogFile, "Hi, i started!")

 

Edited June 15, 2016 by orbs