ie6 AND ie7?

[Mr. Analog]

Well, don't fret, if you have problems that need solving I'm sure between Darren and myself we can make it work. I have a lot of experience overriding MSIEs stupidity (I wrote a frickin' fully featured customizable word processor for it in DHTML / XML).

[Tom]

Thanks, I appreciate it. I'm taking a break atm to get NX working on my second box (found mATX SocketA board for my 2600+ \o/, now I just need a case and another mATX board for my 2400+ )

So I'll post more probably tomorrow, depends on when I get back to fudging with this program

[Darren Dirt]

Sadly you need Office of some sort to have MSE. I don't and I'm not sure my VMs have enough disk space

I think the first few results for this search will allow you to download/install (without Office) the debugger for IE script. Although you'd also benefit, of course, by using Firefox/Mozilla as its "Javascript Console" is very helpful in identifying syntax/runtime errors that might be unclear even in IE's debugger.

I'm confused, why would a global onLoad() call resolve to document.onLoad ?

You can override an event handler in IE be redeclaring it, but if you use the HTML adornments for event handling MSIE doesn't play nice.

Code Select Expand

this.document.body.onload = function () { doFoo(); }

Generally speaking, for my script-dependent event-handling web apps I simply include the <script src=...> at the top, and have at the very end of the html (say, just before </body> ) this simple line:

init();

(notice it's NOT "onload=init;" -- that way I can still do document.write() if necessary, and for any "after the page is completely finished loading" stuff within init() I just use a setTimeout(xyz, 50).)

Inside my .JS files I have the all-important "function init(){}" which then loads up all the necessary global variables, objects, arrays or whatever, calls any one-time set up functions, and most importantly THERE it sets the various events for the appropriate form fields or DHTML ids or whatever (.onfocus() or .onchange() or .onclick() etc.)

Makes it easier to maintain and debug and turn on/off certain event handling, and bonus it makes it all the more separated ("display/layout" vs. "code/logic"), and also it makes the view-source look a lot smaller/less "messy" too (all those <input name="xyz" onchange="abc()"> revealing snippets etc.

And most importantly, inside the included .JS is where the various quirk-handling can take place (even something as simple as grabbing a DHTML object by its id -- testing for document.getElementById, and if not found then testing for document.all, and if that not found testing for (ugh) document.layers, and if not found then not returning a usable object. As an example. IE5 vs. 6 vs. 7 prolly has other quirks you would handle here. (I'm ignoring CSS differences, of course, double-yuck.)


Heck, sometimes I might even, to make it degrade nicely, add a "dummy" version of function init() just before the init; with perhaps a warning alert('JS files failed to load...'); -- that way if the .JS files somehow didn't get included, the visitor is made aware of the page's interactive broken-ness.

But IE5/6/7 quirks are a pain to program around. Mr. A might be helping you more than me