IE functions not working unless running in second instance of IE

[JHARRIS]

Hello,

 

New to AutoIt and the forum, and having an odd issue with a script I'm hoping someone may be able to shed some light on.

 

I'm finding the IE functions within the script fail if the script is running in the first/only instance of IE (the functions are _IEFormGetObjByName, _IEFormElementGetObjByName, _IEFormElementOptionselect, _IELinkClickByText, _IEFormElementSetValue).  If I run the script and it fails, hence leaving the first instance of IE open and logged into the web app, I can run the script and it will then execute normally.

 

I've attached the trouble part of the script, as well as the console output.  I've even compared the source from both IE windows in a text editor and the only differences I found were not related to the specific objects I am referencing.

 

Any ideas?  I am stumped.  I can work around this by having the script bring up and log in to two different IE windows, but of course I'd rather find the real solution.  I hope I've provided enough information - thanks in advance for any advice!

consoleOutput.txt

scriptCode.txt

[Danp2]

Quote

IE.au3 T3.0-2 Warning from function _IEFormGetObjByName, $_IESTATUS_NoMatch

I haven't looked at your script, but you'll need to figure out why this error is occurring. Just a guess, but it is likely a timing issue where the web page hasn't completely loaded at the time this line is executed.

[JHARRIS]

52 minutes ago, Danp2 said:

I haven't looked at your script, but you'll need to figure out why this error is occurring. Just a guess, but it is likely a timing issue where the web page hasn't completely loaded at the time this line is executed.

I have a _IELoadWait before that step and even added a sleep up to 20 seconds to be sure the page had loaded, still with no luck

[Danp2]

My recommendation would be to eliminate the use of Send and MouseClick when interacting with a browser. There are _IE functions that should allow you to accomplish the desired action.

Have you checked to see if the site uses frames?

[Juvigy]

It fails on this line , right ?  

$oForm =  _IEFormGetObjByName($oIE, "j_id29:compForm")

I would put that in a While loop and execute that until $oForm is returned as an object by the function

 

[JHARRIS]

16 hours ago, Danp2 said:

My recommendation would be to eliminate the use of Send and MouseClick when interacting with a browser. There are _IE functions that should allow you to accomplish the desired action.

Have you checked to see if the site uses frames?

I have definitely tried to minimize the use of those functions, but there were some actions I wasn't able to make work with the _IE functions (but I am about as amateur as a "programmer" can get!)

I did check for frames after seeing that in a forum post after searching on the "_IEFormGetObjByName, $_IESTATUS_NoMatch" bit from the console, and this site does NOT use frames.

Edited January 10, 2017 by JHARRIS
misspelling

[JHARRIS]

6 hours ago, Juvigy said:

It fails on this line , right ?  

$oForm =  _IEFormGetObjByName($oIE, "j_id29:compForm")

I would put that in a While loop and execute that until $oForm is returned as an object by the function

 

Well, before that in the console is "Warning from function _IEFormGetObjByName, $_IESTATUS_NoMatch" which I don't know if that qualifies as an actual "error" or not, but obviously something up with it. 

So I tried a while loop with no success, but it may just be my code.  I'm sure it's really sloppy.  But here's what I did:

Local $oForm = _IEFormGetObjByName($oIE, "j_id29:compForm")
While $oForm <> _IEFormGetObjByName($oIE, "j_id29:compForm")
   $oForm = _IEFormGetObjByName($oIE, "j_id29:compForm")
WEnd

Local $oDocuments = _IEFormElementGetObjByName ($oForm, "j_id29:compForm:classMenu")
While $oDocuments <> _IEFormElementGetObjByName ($oForm, "j_id29:compForm:classMenu")
$oDocuments = _IEFormElementGetObjByName ($oForm, "j_id29:compForm:classMenu")
WEnd

This returned the same results as before - does not work if first instance of IE, but if second, third, etc, then it does.

Edited January 10, 2017 by JHARRIS
Update code

[Juvigy]

Your code is wrong. Change

Local $oForm = _IEFormGetObjByName($oIE, "j_id29:compForm")
While $oForm <> _IEFormGetObjByName($oIE, "j_id29:compForm")
   $oForm = _IEFormGetObjByName($oIE, "j_id29:compForm")
WEnd

TO:

Local $oForm = _IEFormGetObjByName($oIE, "j_id29:compForm")
While $oForm = 0
   $oForm = _IEFormGetObjByName($oIE, "j_id29:compForm")
WEnd

[BananaFish]

I've encountered this problem although only intermittently and not in a fixed pattern as yours where you can predict it on demand.

My solution may help you though. I found out that some of the elements and javascripts on the webpage that I was pointing my IE to can sometimes interfere with the IE window loading properly, specifically the problem was tied to the autoit IE function _IELoadWait. If the user that I was using was logged off for too long, it would log me out, and worse yet, it would only display the logging out message as the new instance of IE was trying to access the page. The script would run periodically, and sometimes the webpage likes to default to something else thus changing up the series of loading screens each with their own scripts on them. 

Once I deactivated _IELoadWait from the functions that incorporated them like IECreate or IENavigate, as well as replacing them with basic sleep functions, this problem was resolved for me.

For your problem, perhaps the first instance of IE is doing something like authentication which the website does by heading off to several other pages, or even a different page but with the same url and id specs, which the second IE window can simply skip allowing it to go ahead with the script and the first one seemingly can't run because some of the things are not there. 

If removing the _IELoadwaits functions in the script is too much trouble, I would say try detecting whether the script is running at all with some carefully placed echoprints/consolewrites in the script at vital points to see if it running or simply stopped. Going further, if it is indeed trying to run, try to grab some of the text on the page that it is running on to see what's going on.