The IE Management Functions

Recommended Posts

Zach 0

Zach 0

Thats about the best thing I can come up with for a question. Just really curious as to why what seems to be a more complicated route for some things .. was the route taken... instead of the direct route which is already made available through the start of it all.

$oIE = _IECreateEmbedded ()

(or _IECreate .... same difference)

Thats cool - I like that kind of stuff. Simple, easy to remember - bam done.

Now I have not looked through much of it - just a very brief glance ... really the reason I noticed em was because I was using the CreateEmbedded example as a starting point for something else - but something else that I just wanted a browser to be sitting there for.

Now I am sure that some of the collections and such do make them easier to work with - which is cool - but I would think that for the basic things like the above it would be much wiser to go with the direct route ... if for nothing else it gives others that have no idea that is how it really works a good starting point.

I mean - by going that route - you have everything available... need the Explorer Window? (Parent of the Document - not the Windows Window)

$oIE.document.ParentWindow

Need to execute Javascript, VBScript, PHP, Perl, or any other language that can be used as an ActiveScript?

$oIE.document.Parentwindow.execScript ("alert(1)","JScript")

$oIE.document.Parentwindow.execScript ("MsgBox 1","VBScript")

(below would actually work for javascript - the second parameter is optional and defaults to js)

$oIE.document.Parentwindow.execScript "alert(1)"

... or better ...

$doc=$oIE.Document

$win=$doc.ParentWindow

$win.execScript

Then of course - you have easy access to other stuff

$body=$doc.Body

..... and every other thing you find in the MSHTML type library

Just curious as to why it was done the way it was done. I am one that thinks if it works - it works - am not one to be stuck on the "this is the right way" ... this is just a question of because I am curious.

Edited December 31, 2006 by Zach

Share this post

Link to post

Share on other sites

DaleHohm 59

DaleHohm 59

This is a fair question and I debate it regularly when I decide what goes into IE.au3 and what does not.

IE.au3 was created after months of watching what people were trying to do with IE and helping them accomplish it with the new COM interface in AutoIt. Most of the people had little or no experience with COM or OO programming and most of the time was spent explaining the same concepts and syntax over and over again. MSDN documentation is a intimidating to many and a puzzle to most -- you really need to spend time with it before you understand the organization and content. Most people were just not making it over the hump to do really interesting things with it.

1) By accessibility what I mean is flattening the learning curve -- making IE and DOM scripting available to more people, faster and with less up front time investment.

2) For simplicity my goal is to allow people to readily accomplish the basics without having to learn the OO syntax, figure out how to use external documentation like MSDN and convert syntax into AutoIt. I therefore created functions using the AutoIt UDF syntax that the AutoIt community is already familiar with.

3) Every IE.au3 function does a significant amount of common error management. They check to insure that parameters are of the correct datatype, that objects are of the correct object type and that the requested property or method applies to that object. If not, it displays a diagnostic message, returns an appropriate status and prevents abrupt script termination. There are some functions, particularly _IELoadWait, where transient errors are expected in some circumstances; in these cases I trap and retry without concerning the scripter.

4) There are many IE.au3 functions that fit this category - e.g. _IEAttach, _IELoadWait, _IETableWriteToArray - where some complex work is done in the background to accomplish a common task. _IENavigate and other functions also call _IELoadWait on your behalf to insure that the browser and document have quiesced before trying to access its contents.

So, is $oIE.GoBack easier than _IEAction($oIE, "back")? Yes, presuming you know that the correct method name is "GoBack" and not "Back" and you know that it applies to the InternetExplorer object and not to a window object or a document object. No, if you don't know the properties and methods of the objects and are uncomfortable with OO syntax or MSDN documentation.

You also call out _IEDocGetObj -- this is admittedly of limited value, but it allows you to pass in any document container or DOM element object (InternetExplorer, Window, Frame, Document or any document element down to a <DIV> or <TD>) and get the associated document object back. And if you pass in a Word.Application object by mistake you'll get a diagnostic message and return value back to help you debug.

The nice thing about all of this is that you can mix and match. You can use the OO syntax along with the _IE functions and either do the same things using the method you think is easiest or to use properties and methods not available in the _IE functions. The IE.au3 is also distributed in clear text with AutoIt so that anyone can open it up and learn from it, expand upon it or implement any or all functionality without using any of the IE.au3 functions.

SciTe Debug mode - it's magic: #AutoIt3Wrapper_run_debug_mode=YDoesn't work needs to be ripped out of the troubleshooting lexicon. It means that what you tried did not produce the results you expected. It begs the questions 1) what did you try?, 2) what did you expect? and 3) what happened instead?

Reproducer: a small (the smallest?) piece of stand-alone code that demonstrates your trouble

Side note - I read the function name __IEControlGetObjFromHWND ... and went.. hum - that should do what I need here. Its easy enough to get the hWnd ... so whatever he has going on there should do .... then I got down to the function and cussed

(I use the same exact thing in what I am working on ... though I had it a bit easier - I didnt have to convert it to another language )

SciTe Debug mode - it's magic: #AutoIt3Wrapper_run_debug_mode=YDoesn't work needs to be ripped out of the troubleshooting lexicon. It means that what you tried did not produce the results you expected. It begs the questions 1) what did you try?, 2) what did you expect? and 3) what happened instead?

Reproducer: a small (the smallest?) piece of stand-alone code that demonstrates your trouble