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 )

I assume you can use the #include in an included file right? .. which means - you could dynamically include includes by making the initial include file on the fly which includes the include files actually wanted.

HTML does nothing - its GUI only - thats it. Javascript can make it move around - change the DOM around - etc - as can Java and COM Objects (Flash, Real, and Media Player being the most common) Expect to do as much "programming" with HTML as you would do with the contents of your "My Pictures" folder. Javascript running in a webpage - is not going to interact directly with the server. Javascript can be used to do calls to a web address on the server - same as you can do in your browser. It can pass values back in a variety of ways - but it can not actually reach down into the server and do something. Something has to be running server side - that you will never actually see running (unless you have the server beside you) Also - I can not even pretend to understand what you are trying to do. Javascript can connect but you are missing one big important detail here I think. The javascript in the webpage is running on your computer - not on the server.

Oh - and about the sig of Mr Icekirby.... I have noticed it before ... editbin /NOLOGO /SUBSYSTEM:CONSOLE CompiledAU3.exe and you now have a console app

I really got to make a rule that I never use the word "handle" again. Its got way to many uses for way to many different things. To put it another way. What I was really looking for is a reference to the running script itself - or a reference that puts me into the same scope as the running script.

Only comment I have is that its something that at best it can only be used in a controlled environment. It depends on WMI - which you can not depend on being there. As far as the amount of processor its taking up --- 3% is not bad considering - again - its using WMI.

I dont think so. Unless the AutoItX dll also serves serves for activescripting I have a script I wrote a year or so ago that will take any php script and build a wsc file out of it - if there is any interest I will try to figure out exactly what dependencies it has and put it up where it can be used. ... though - I also have something a bit better that I will have useable outside of my stuff in the next week or so. Its a com dll that gives me two things I really wanted. 1) I can use any activescript language as if its a regular class - no wsc files - functions can be called directly - returns are direct - everything is direct. The source of the script that is compiled in is completely unreadable...(though depending on what interface one allows to be public - obviously one can get the source just from the interface if one wants .. but if its all kept internal - nobody would ever be able to read it) 2) Any program written in any language can communicate with any other program in any language directly - as if they are same program. You can call functions from one program to the other - pass data back and forth - etc - all as if its the same program ... obviously any programs would actually have this compiled into it and any other program trying to access it would have to be allowed. I have been playing around with AutoIt last day or so getting it to work with the 2nd option - the first option it already would with no adjustments. So far - and as far as I am going to worry about for now - from an AutoIt script, compiled or not - you can control any other program that you want it to. By "control" - I do not mean move it around and change its borders - I mean - internal full access - be it a vb program - it will have accesss to every single function in the vb program that is in the same scope (and of course are public)

Ditto

Why? It can be done... and be done well.

If your host does not offer ASP - then I am going to venture a guess that you have a linux server. Which in that case - unless I have missed something somewhere along the way - AutoIt is not going to work on that server. I would also venture a guess that PHP would. Which is what you would need to use on the server. HTML is text - it is as much a part of development as an image is. Its GUI only - you look at it - and thats about it (minus maybe button and forms - which will do something if asked - but that is only to hand data to something else) Javascript ... well - yes you can use it server side. On a windows or a linux box. But it would not be involved with HTML - unless it was making HTML to be displayed ... and either way - would be about the absolute worse form of scripting you could come up with to do server side simply because hardly anybody does it ... especially on linux... and information on it will not be that easy to find. PHP will do the stuff you want on the server..... that is - depending on if what you want to do requires security permissions higer than what the user that Apache runs as has... (which in a shared hosting environment.. I doubt that you actually can get any higher permissions anyway) ... No clue what you are trying to do - could not understand anything other than it looks like you are dramatically offbase on the tools you are trying to use.

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.

I am sure it exists and I am just missing it - but I can find anything that seems to give me the actual object handles. Not looking for the hwnd - want the object. $btn = GUICtrlCreateButton("Button", 10, 10, 100, 30) I thought - incorrectly - would give me the object as ... $btn but it does not seem to work if I try to pass it a static or a com dll ... Have not looked at it all that close yet - but just assuming that a variable that comes from AutoIt is going to have an AutoIt format or something to that extent. Now - if I use something like $oIE = _IECreateEmbedded () or $obj = ObjCreate("Shell32.WhatEver") The left hand variable in those cases is the object I would have expected to get from any of the GUICreate functions. I know there is ways to get it ... just wondering if there is a built in method I am missing?

<style> body { border:0 } </style> Will work if you have no declared doc type in the page (it works with some doctypes - HTML 4.01 Transitional - for one I believe - does not work with strict and/or xhtml doctypes if I believe)

It may not have a com interface to the browser itself as IE does... but it does have a com control.

I have something like this that I use - but it monitors where your mouse is - and kicks up whatever your mouse is over to high, and whatever you just left to idle You dont want to kick anything up to realtime - especially if you are developing anything - you get one thing to go bad on realtime - you aint getting it back - and will have to reboot.