Can you get both installed in some manner on XP? I need to do some testing with both, as well as firefox, and while it (the site) works fine in firefox, theres a Js error somewhere with IE7 (even thought I could swear it was all cross browser compatible).
I've heard from one person saying there is a hacked version of ie6 that can be installed alongside, but some things like conditional CSS statements are missing. I'd prefer to have it work the same as it normally would. And I don't have enough ram to run two vmware XP images simultaneously (at least not with 512MB to each, I'll try less, but It might not be enough to run xp :().
XP can run with 128MB of RAM - I know because that's all I could squeeze onto the motherboard of my Pentium 166Mhz machine. It was excuciatingly slow, but that's because it was a *very* old HDD (2.1GB). IE6 and IE7 do not live side-by-side natively. IE7 forces itself over IE6. If you have a hacked IE6 running, you have to ask yourself whether your JS is being interpreted by the IE6 or IE7 engine.
I recommend you run two boxes or two virtual machines. Since you're only testing web sites, you could easily run each image with only 256MB, or even 192MB. Now, if you were testing AutoCAD, there's no way I'd recommend you run the virtual machines with under 1.5GB each :P
Heh. Still, I don't like giving windows less than 512MB ;) Its like a rule or something. The fact that with 512MB ram set, it was using 300MB of Host ram...
Microsoft has snuck in some updates lately the stop some of the incompatibility issues, however some users of applications I support are having grief which is making it hard for them to work, to that I say...
(http://vger.homeip.net/images/Firefox_dock_icon.png)
GET FIREFOX
I guess I should make the menus work in Mozilla-based browsers for the next code release haha :D
Duel boot?
My primary development system is Linux, (I'm used to having all the tools I need ;)) Having to triple boot to test out every little change in the silly little ajax app would take forever and get quite annoying :(
Using two vmware sessions at once seems to be working ok, but IEs debugging sucks so bad its not funny.
Are you using the Microsoft Script Debugger?
http://blogs.msdn.com/ie/archive/2004/10/26/247912.aspx
Yup. It's much better than the default dialog, though I can't be sure if its even reliable information at all. I get two or three errors from two things:
1. /* multi line comments */
2. <tag onfoo="foo();">
I can only assume the second error is coming from the first one, but does IE not do /* comments */ ?
I haven't been able to find any information on IEs support for that style of js comment.
Sorry, I meant the Microsoft Script Editor (gotta read the page I'm linking to before posting the link :P).
http://www.jonathanboutelle.com/mt/archives/2006/01/howto_debug_jav.html
I don't recall IE's JScript having a problem with multi-line commenting, and in IE6 it's supposed to support all of ECMA-262. Can you provide a code snippet in context?
Sadly you need Office of some sort to have MSE. I don't and I'm not sure my VMs have enough disk space :o
But after taking a close look at the code, it SEEMS that IE just doesn't like the trailing , in:
{
foo: 123,
bar: 321,
}
Not even a warning in Firefox. yet it totally kills IE?
And now my other error:
<body onload="onLoad();"> I've also tried "return onLoad();", and "onLoad();return false;", etc. It keeps sayng "Expected identifier, string or number" for the text just after onload=" ..
Colour me confused.
edit: ok, that one too seems to have been a trailing ,...
Now I have an error in the "prototype" javascript library? yeeesh..
edit, yeah, its saying "this.initialize" isn't an object or function.. Not sure why. Seems its supposed to be a JS builtin of some form?
If you do this:
<html>
<script language="JavaScript">
function foo()
{
//TODO: ADD CODE HERE
}
function doFoo()
{
foo();
}
</script>
<body onBar="doFoo()">
<div>blah</div>
</body>
</html>
will work but...
<html>
<body onBar="doFoo()">
<script language="JavaScript">
function foo()
{
//TODO: ADD CODE HERE
}
function doFoo()
{
foo();
}
</script>
<div>blah</div>
</body>
</html>
...won't because IE will process script calls and look for script declarations while it is parsing the content mid-stream.
Ahh, also;
<body onload="onLoad();">
OnLoad is a pre-existing event handler for the MSIE document object class, try changing the name of your function call.
Look up the Document Object Model on MSDN DHTML Reference:
http://msdn2.microsoft.com/en-us/library/ms533050.aspx
I'm confused, why would a global onLoad() call resolve to document.onLoad ?
Quote from: Tom on April 26, 2007, 11:08:05 PM
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.
this.document.body.onload = function () { doFoo(); }
I really dislike IE :( Oh well. If I cant get it to work, theres a chance I don't get payed. woo.
I have to rework the silly tabview thing I wrote a little anyhow, since its complaining about an issue with that particular class/object.
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).
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 :)
Quote from: Tom on April 26, 2007, 09:25:06 PM
Sadly you need Office of some sort to have MSE. I don't and I'm not sure my VMs have enough disk space :o
I think the first few results for this search (http://www.google.com/search?q=download%20internet%20explorer%20debugger) 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.
Quote from: Mr. Analog on April 26, 2007, 11:13:38 PM
Quote from: Tom on April 26, 2007, 11:08:05 PM
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.
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 ;)