Internet Explorer Automation UDF library

[mathew]

hi,

i tried to understand your functions. but as far as i understood i don't see the mistake in my script

there is a website with a form called "loginform" which has 2 inputs ("user" and "password")

and the handle of the browser is $o_b_login

Local $o_userlogin = $o_b_login.document.forms.item("loginform",1)

Local $o_user = $o_userlogin.elements.item("user",0)

Local $o_pass = $o_userlogin.elements.item("password",0)

$o_user.value = $db_login_user

$o_pass.value = $db_login_pass

why does this crash by getting $o_user and $o_pass ?

Mathew

[DaleHohm]

Things that will help you get help in the future: 1) include the exact messages returned by AutoIt -- "crash" is not a good description of what happens 2) indicate the verison of AutoIt you are using 3) try to create a reproducible example that we can examine or test using an internet-accessible location or a stand-alone code example.

Without any of that and realizing that you are not using IE.au3, I do see one curious line:

$o_b_login.document.forms.item("loginform",1)

Are there 2 forms on the page called "loginform"? This command will instantiate the 2nd one...

Dale

hi,

i tried to understand your functions. but as far as i understood i don't see the mistake in my script

there is a website with a form called "loginform" which has 2 inputs ("user" and "password")

and the handle of the browser is $o_b_login

Local $o_userlogin = $o_b_login.document.forms.item("loginform",1)

Local $o_user = $o_userlogin.elements.item("user",0)

Local $o_pass = $o_userlogin.elements.item("password",0)

$o_user.value = $db_login_user

$o_pass.value = $db_login_pass

why does this crash by getting $o_user and $o_pass ?

Mathew

[mathew]

Things that will help you get help in the future: 1) include the exact messages returned by AutoIt -- "crash" is not a good description of what happens 2) indicate the verison of AutoIt you are using 3) try to create a reproducible example that we can examine or test using an internet-accessible location or a stand-alone code example.

well i see that my post was not quiet usefull

but i found the mistake ; )

sometimes i cant see the easiest mistake -.-

in future i will look that my errors and questions are more clearly ^^

thanks

[LOULOU]

I have problem with INPUT TYPE="FILE"

I don't arrive to write something in the Edit ZOne.

How can I do witout using Send coomand ?

Thanks

[pingpong24]

is it possiable if we could modify the user agent using your UDF?

[DaleHohm]

I have problem with INPUT TYPE="FILE"

I don't arrive to write something in the Edit ZOne.

How can I do witout using Send coomand ?

Thanks

Unfortunately it is a security restriction and the .value property of INPUT TYPE="FILE" is read-only from the DOM.

There is a way to use ControlSend instead of Send however which may give you more flexability. Since the document area of the browser doesn't expose a ControlID, but does have a ClassNameNN of "Internet Explorer_Server1", the following will work:

ControlSend(title, "", "Internet Explorer_Server1", "TestControlSend")

Here is a full example that uses the HWND of the browser window instead of the title:

#include <IE.au3>

; Open browser and navigate to google
$oIE = _IECreate()
_IENavigate($oIE, "www.google.com")

; Explicitly give keyboard focus to the input field
$oForm = _IEFormGetObjByName($oIE, "f")
$oInput = _IEFormElementGetObjByName($oForm, "q")
$oInput.focus

; Get window handle of the IE window
$hIE = _IEGetProperty($oIE, "hwnd")
If Not IsHWND($hIE) Then $hIE = HWND($hIE)

; Use ControlSend to send value -- minimize and restore just to show that we can
WinSetState ( $hIE, "", @SW_MINIMIZE )
ControlSend($hIE, "", "Internet Explorer_Server1", "TestControlSend")
WinSetState ( $hIE, "", @SW_RESTORE)

Dale

Note: There seems to be a strange string capitalization issue here however... at least in my testing at the moment, it seems to be indeterminant what odd mixed case string will be displayed by ControlSend.

Edit: typo and comments

Edited December 24, 2005 by DaleHohm

[DaleHohm]

is it possiable if we could modify the user agent using your UDF?

Assuming you mean "can I substitute FireFox or Opera?", No.

Dale

[pingpong24]

Assuming you mean "can I substitute FireFox or Opera?", No.

Dale

No, i am saying when you sending a HTTP request to a webserver i.e. autoit.com it sends out what useragent you are using, in this case it will say mozilia compatiable (ie.6)... etc.

I want to change the useragent string, so that when i am sending the http request to a web page.. it doesnt know that i am using i.e.6.. instead i can modify it to what ever i want.

i read on the msdn developers page that this is possiable, but i dont have a clue to how.

[DaleHohm]

No, i am saying when you sending a HTTP request to a webserver i.e. autoit.com it sends out what useragent you are using, in this case it will say mozilia compatiable (ie.6)... etc.

I want to change the useragent string, so that when i am sending the http request to a web page.. it doesnt know that i am using i.e.6.. instead i can modify it to what ever i want.

i read on the msdn developers page that this is possiable, but i dont have a clue to how.

Ah, yes, that USER_AGENT

I don't see a way to do it in the DOM -- it appears to be read-only. There are likely other ways outside of the DOM however -- If you find some discussion of changing it, please provide a pointer.

Dale

[Valik]

Dale, your library doesn't pass "MustDeclareVars". You can check this by using Au3Check as follows:

au3check.exe -d IE.au3

I get 20 warnings about undeclared variables.

Edit: Fixed mistake.

Edited January 5, 2006 by Valik

[DaleHohm]

Dale, your library doesn't pass "MustDeclareVars". You can check this by using Au3Check as follows:

au3check.exe -d IE.au3

I get 20 warnings about undeclared variables.

Edit: Fixed mistake.

Thanks -- I hadn't noted the -d option in au3check , it will be helpful. Doing Local declarations of all my function variables is on my ToDo list for the next release.

Dale

[footswitch]

Hello Dale,

First of all, thank you for all your effort since the very beginning of your IE Automation project.

Now, the only problems I've found seem to have been discussed before, but never solved, so I'd like to know if things are getting to some point or not.

Remember this?

link to an earlier discussion between Whaouu and Dale

Line 1236 (File "C:\Documents and Settings\Administrator\Desktop\scripts\bancos\IE.au3"):

While ($o_object.document.readyState <> "complete") and ($o_object.document.readyState <> 4)

While ($o_object.document^ ERROR

Error: The requested action with this object has failed.

Well in fact I have the same sort of problem here, and this seems to occur independently of how many IE objects (IE windows) are open, of which URL we are working with, of how many frames exist in the site, of how many au3 instances are being executed... It seems almost random!!

So... is it just something obvious about _IELoadWait() that I'm missing?

Thanks a lot for your time and attention

[DaleHohm]

Hello Dale,

First of all, thank you for all your effort since the very beginning of your IE Automation project.

Now, the only problems I've found seem to have been discussed before, but never solved, so I'd like to know if things are getting to some point or not.

Remember this?

link to an earlier discussion between Whaouu and Dale

Well in fact I have the same sort of problem here, and this seems to occur independently of how many IE objects (IE windows) are open, of which URL we are working with, of how many frames exist in the site, of how many au3 instances are being executed... It seems almost random!!

So... is it just something obvious about _IELoadWait() that I'm missing?

Thanks a lot for your time and attention

I suggest you may want to jump into the discussion over here -- there is an issue with the same symptom being worked there. Perhaps with pooled information we can find the commonalities involved.

Dale

[Walkabout]

Hi All,

Thanks for such a useful UDF. I've been using it extensively recently and found it to be very helpful.

A quick question if I may?

When accessing many web pages, has anyone come across a problem with IE consuming more and more available memory until the system grinds to a halt? I think this is an IE problem, but I'm wondering if anyone has any ideas on how to 'band-aid' it using UDF.

Thanks

Walkabout

[Valik]

Thanks -- I hadn't noted the -d option in au3check , it will be helpful. Doing Local declarations of all my function variables is on my ToDo list for the next release.

Dale

Dale, a new Au3Check (1.49) is out and it detects unused variables. There were just a couple variables that were unused. However, you might want to wait on Au3Check 1.50 if you want those variables around for debugging purposes, it shouldn't detect them.

Also, when I was running Au3Check on the code, I noticed you used Dim in 3 places. These should probably be replaced with "Local" since Dim has the side-effect of re-using a global variable of the same name if it finds one.

[jdefockert]

I also encounter problems adding a path to a file input filed in a Web Form.

A trick that works in simple instances is setting the focus on the control and then pasting the path in there, with Send('^v').

Tthis does not work on the portal I have to work with now unfortunately. The focus does not stay on the control.

Is there a reliable way to press on the "Browse" button of the control because adding the the path to the Choose file window will be easy.

Thank you in advance for your ideas/replies.

Kind regards,

Jasper de Fockert

[DaleHohm]

Dale, a new Au3Check (1.49) is out and it detects unused variables. There were just a couple variables that were unused. However, you might want to wait on Au3Check 1.50 if you want those variables around for debugging purposes, it shouldn't detect them.

Also, when I was running Au3Check on the code, I noticed you used Dim in 3 places. These should probably be replaced with "Local" since Dim has the side-effect of re-using a global variable of the same name if it finds one.

Hmm... I don't recall purposefully having unused variables -- I'll weed them out.

I agree on the uncertainty of using Dim -- especially in UDFs. I'll correct them as well.

Thanks Valik

Dale

[DaleHohm]

I also encounter problems adding a path to a file input filed in a Web Form.

A trick that works in simple instances is setting the focus on the control and then pasting the path in there, with Send('^v').

Tthis does not work on the portal I have to work with now unfortunately. The focus does not stay on the control.

Is there a reliable way to press on the "Browse" button of the control because adding the the path to the Choose file window will be easy.

Thank you in advance for your ideas/replies.

Kind regards,

Jasper de Fockert

It appears that a click on the input type="file" element will give you what you are asking for. Here is a self-contained example:

#include <IE.au3>

$oIE = _IECreate()
_IEBodyWriteHTML($oIE, '<form METHOD=post ACTION="action.cgi" NAME="myform" ENCTYPE="multipart/form-data"><input TYPE="file" NAME="filename"></form>')
$oForm = _IEFormGetObjByName($oIE, "myform")
$oFN = _IEFormElementGetObjByName($oForm, 'filename')
$oFN.click
Exit

Dale

Edited January 11, 2006 by DaleHohm

[jdefockert]

It appears that a click on the input type="file" element will give you what you are asking for. Here is a self-contained example:

#include <IE.au3>

$oIE = _IECreate()
_IEBodyWriteHTML($oIE, '<form METHOD=post ACTION="action.cgi" NAME="myform" ENCTYPE="multipart/form-data"><input TYPE="file" NAME="filename"></form>')
$oForm = _IEFormGetObjByName($oIE, "myform")
$oFN = _IEFormElementGetObjByName($oForm, 'filename')
$oFN.click
Exit

Dale

Thank you Dale that indeed results in the Browse window to appear. Unfortunately the script pauses until the Browse window is closed again.

I solved this by starting an external (compiled) script that checks for this window to exist and that enters the correct path and closes the window. Then the main script resumes its work and the external script closes itself. I use the commandline parameters to pass the path to the external script.

In addition the <input type=file> of the portal I have to work with does not accept any commands, except keystrokes. So I had to use the Send('{TAB #}'), where # is number of TABs, command to put the focus to the Browse button and then Send('{SPACE}') to open the Browse window.

I think the <input type=file> is protected against scripting and automation by a Javascript, because when using the .click method the value is stored in the control, but on submitting the form nothing happens and the control is emptied (IE does report a Script error). Only if a user uses the browse button (ie with keystrokes) the form is submitted with the correct path.

I hope this will help solve similar issues.

Kind regards,

Jasper

[DaleHohm]

Yes, the input type=file element has lots of scripting restrictions due to security concerns. You need to use a hybrid of SEND() commands along with DOM commands to simulate interactive user input -- fortunately, AutoIt makes this possible.

I forgot about the DOM suspending execution while the file selection box is up -- there is an example working around this using similar methods in the example post (reply 3 of this thread). You should be able to accomplish your goal without having two scripts running though (unless I don't understand your situation).

Dale