The IE Management Functions

[Zach]

Why?

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.

Case $msg = $GUI_Button_Home
            _IENavigate ($oIE, "http://www.autoitscript.com")
        Case $msg = $GUI_Button_Back
            _IEAction ($oIE, "back")
        Case $msg = $GUI_Button_Forward
            _IEAction ($oIE, "forward")
        Case $msg = $GUI_Button_Stop
            _IEAction ($oIE, "stop")

Is what I see when I glanced down.

Then I look a bit deeper ... just at function names - and I see stuff like _IEDocGetObj ...

Well - would not

Case $msg = $GUI_Button_Home
            $oIE.GoHome
        Case $msg = $GUI_Button_Back
            $oIE.GoBack
        Case $msg = $GUI_Button_Forward
            $oIE.GoForward
        Case $msg = $GUI_Button_Stop
            $oIE.GoStop

.....
$oIE.Navigate2 "http://www.autoitscript.com"
$oIE.GoSearch
$oIE.Document (_IEDocGetObj)

Be a bit easier?

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

[DaleHohm]

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.

The design goals for IE.au3 are 1) accessibility, 2) simplicity, 3) common error management and 4) convenience routines.

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.

Regards,

Dale

[Valuater]

Great answer Dale

8)

[Zach]

Great answer Dale

8)

Ditto

[Zach]

Ok Dale - after looking at the code in IE.au3 (... and getting teased thinking I found something that would do what I wanted....)...

You mind taking a look at this question - http://www.autoitscript.com/forum/index.php?showtopic=38681

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 )

Edited January 1, 2007 by Zach

[DaleHohm]

I read the other thread and what you posted here and I have no idea what you are talking about.

In any case, please don't add unrelated topics to this post - I won't respond to it again.

Dale