Sign in to follow this  
Followers 0
samozaparola

Automation resistance problem

10 posts in this topic

#1 ·  Posted (edited)

I have a Borland Delphi 6.0 - 7.0 application which interacted pretty well with AutoIt (I used AutoIt to automate some form input) but upon a program update all control was lost (the name of the window, the controls ID's, etc. seem not to be changed). Strangely, I still can read info from the application, eg ControlGetText, but if I try to change anything, for instance with functions like MouseWheel, WinMove, ControlSend, ControlSetText, nothing happens. Any ideas what can be the reason and how can I overcome this problem?

Edited by samozaparola

Share this post


Link to post
Share on other sites



Thank you very much for your answer, Zedna!

Here is an excerpt from my code:

func GoDocCombo()
WinActivate("Хипократ", "")
MouseWheel("up", 10)
$iIndex = _GUICtrlComboBox_GetCurSel($DocCombo)
;msgbox (0, "Selected combobox item", $iIndex)
;Reg Nomer LZ
$pos = ControlGetPos("Хипократ", "", "[CLASS:TDBEdit; INSTANCE:37]")
MouseClick("primary", $pos[0]+5, $pos[1]+55, 1, 0)
ControlSetText("Хипократ", "", "[CLASS:TDBEdit; INSTANCE:37]", "")
Send ($arrDoctors[$iIndex][1])
;UIN
$pos = ControlGetPos("Хипократ", "", "[CLASS:TDBEdit; INSTANCE:36]")
MouseClick("primary", $pos[0]+5, $pos[1]+55, 1, 0)
ControlSetText("Хипократ", "", "[CLASS:TDBEdit; INSTANCE:36]", "")
Send ($arrDoctors[$iIndex][2])
;UIN 2
$pos = ControlGetPos("Хипократ", "", "[CLASS:TDBEdit; INSTANCE:35]")
MouseClick("primary", $pos[0]+5, $pos[1]+55, 1, 0)
ControlSetText("Хипократ", "", "[CLASS:TDBEdit; INSTANCE:35]", "")
Send ($arrDoctors[$iIndex][3])
EndFunc

I have an array that contains all the info needed to construct a combobox and to populate the form fields of the application (not included here for simplicity). The reason i didn't use only

ControlSetText("Хипократ", "", "[CLASS:TDBEdit; INSTANCE:37]", "1234567890")

was that the form field did not retain the newly set text data, though it appeared in the form field initially.

Anyway my script worked. So I'd like to receive a general explanation, if anyone knows, what could be the reason for this complete dissociation and loss of communication between my script and the app... So far, only WinActivate("Хипократ", "") seems to be still operational.

I tried not to use any references to the controls but just click over them and paste input from the clipboard, but again with no effect at all.

Here is the screenshot of the application with AutoIt Window Info next to it:

Posted Image

Share this post


Link to post
Share on other sites

What does @error contain after you do a ControlGetPos()?

You might need to implement some error checking.

Share this post


Link to post
Share on other sites
willichan, I suppose @error is a way to get some feedback if there is an error while trying to retrieve the position of a control in my case. I don't know how to inspect it, but finding the position or returning the text of a particular field is still working. It can read, but it cannot change anything...

Share this post


Link to post
Share on other sites

If the only change has been an application update, then you need to narrow down what changed in the application.

You can insert lines like

MsgBox(0, "debug line " & @ScriptLineNumber, "@error = " & @error)

following each ControlGetPos() statement so that you can see if any of them are producing errors. That might help narrow down at what point it is failing.

Do the same for your ControlSetText() statements.

You might also want to use the "AutoIt Window Info" tool, and check to make sure that none of the window information has changed.

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

Following willichan's advice I placed the "@error" message box after each function of the code excerpt I provided above, and all that was returned was 0:

@error = 0

The events that lead to my AutoIt malfunction were, I was told, Windows update, and updagte of the application being automated.

Edited by samozaparola

Share this post


Link to post
Share on other sites

If the new Delphi program is now using Delphi XE2 rather than Delphi 7 then it might be using the FireMonkey visual components, in which case I don't think you will get what you want. It might be worth asking the producer of the program what it is written in. If it's still D7 then you can ignore this post.


Serial port communications UDF Includes functions for binary transmission and reception.printing UDF Useful for graphs, forms, labels, reports etc.Add User Call Tips to SciTE for functions in UDFs not included with AutoIt and for your own scripts.Functions with parameters in OnEvent mode and for Hot Keys One function replaces GuiSetOnEvent, GuiCtrlSetOnEvent and HotKeySet.UDF IsConnected2 for notification of status of connected state of many urls or IPs, without slowing the script.

Share this post


Link to post
Share on other sites

Did you try looking at the controls using the "AutoIt Window Info" tool?

Share this post


Link to post
Share on other sites

martin, do you know why a Delphi XE2 and the FireMonkey visual components should make a difference? I don't see any conspicuous change in the interface; the Delphi 6.0 - 7.0 info came from a program I used to pull out any compilation details from the application I tried to automate. Do you know of another way in which I can find out what environment was used to develop the application?

willichan, at the screenshot I posted above, I'm retreiving control info from the editbox enclosed by the black border with the help of the AutoIt v3 Window Info.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0