Javascript debugger for Internet Explorer - Debug - Debugging

[Jeff]

Use the MS Script Editor included free with MS Office 2002 and above,
for debugging Internet Explorer (IE).

This subject is of great interest to many JS developers, as there is no
obvious, low cost way to do sophisticated debugging in
IE6 other than to use the debugger described below, which is horribly
documented otherwise. I feel debugging is an important aspect of
projecting the useability of the language and needs to be made more
clear for new users.
Jeff Papineau
yo**@mandala.com
<FAQENTRY>

This is a page that describes how to install and use the MS Script
Editor to debug Javascript in Internet Explorer ( IE ). It has a
powerful debugger built into it that works really well for developers
supporting IE5+. This debugger/editor included with most versions of
Microsoft Office.

http://www.mandala.com/javascript/debug_javascript.html

..NET programmers may have better tools (VStudio) but this comes in
really handy for anyone developing with JSP and PHP and other dynamic
scripting languages which embed javascript, as well as any HTML page
using Javascript in Internet Explorer that needs a (almost) free
debugging environment.

</FAQENTRY>

[Dr John Stockton]

JRS: In article <11**********************@g43g2000cwa.googlegroups .com>
, dated Sat, 2 Jul 2005 01:04:44, seen in news:comp.lang.javascript,
Jeff <su******@gmail.com> posted :

Use the MS Script Editor included free with MS Office 2002 and above,
for debugging Internet Explorer (IE). ... Jeff Papineau
yo**@mandala.com

When anyone puffs a product as repeatedly as you have done, it will be
wisely assumed that the puffer is an egomaniac, a complete prat, or
possessed of a financial interest.

Please, then, explain your behaviour.

--
© John Stockton, Surrey, UK. ??*@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.

[Jeff]

Hey Dr. John!

Well, anyone that's lurked around here knows you harbor an opinion or
two yourself! ;-)

In answer to your question, it's called Google page rank! No, actually,
do a search on Google and look at the results for "Javascript debug".

Oh my god. The backward solutions this community has been resorting to
for the last 10 years is just beyond hope, at least where IE developers
are concerned.

It's time for everyone to sing from the same page in the hymnal my
friend.

Using free MS tools to do IE web application debugging really makes a
lot of sense, because you can visualize the DOM structure of the page
AND the JS objects the developer adds to the page in a very robust
debugger.

Try this debugger and let us know what you think!

And I'll share a few more IE javascript debugging tips here as well:

http://www.fiddlertool.com/fiddler/

FIDDLER - Excellent and free HTTP proxy transport monitor, will show
you every time the client is hitting the server, and the server's
response if any. So much easier to use than Achilles! AJAX programmers
check it out, you need it.

http://www.cheztabor.com/IEDocMon/

IEDocMon - Excellent IE DOM visualization tool. If you are doing a lot
of AJAX style programming, this baby sure is nice to view the DOM in
real time and see it update itself. View the contents of your frames,
etc. Just amazing, and the price is right... FREE.

The above tools and the MS Script Editor debugging environment and you
can visualize the entire client ENCHILADA. No more black box...

Ciao,

Jeff Papineau
xx**@mandala.com
Dr John Stockton wrote:

JRS: In article <11**********************@g43g2000cwa.googlegroups .com>
, dated Sat, 2 Jul 2005 01:04:44, seen in news:comp.lang.javascript,
Jeff <su******@gmail.com> posted :

Use the MS Script Editor included free with MS Office 2002 and above,
for debugging Internet Explorer (IE).

...

Jeff Papineau
yo**@mandala.com

When anyone puffs a product as repeatedly as you have done, it will be
wisely assumed that the puffer is an egomaniac, a complete prat, or
possessed of a financial interest.

Please, then, explain your behaviour.

--
© John Stockton, Surrey, UK. ??*@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.

[steveH]

Jeff, you must have run into the following problem...you 're using ms
script debugger to step through code. All goes well for a certain
length of time. Suddenly, the debugger refuses to work anymore.
'debugger' statements don't cause the "do you want to debug"prompt,
attaching the debugger to your instance of IE does not give 'script' as
a checked option in the Attach To Process dialog and, if you persevere
and attach anyway, the running documents view is empty. It just won't
work anymore. If you reboot windows, all is ok again. I've lived with
this behaviour in Visual Interdev, MS Script Debugger, Visual
Studio.NET (the problem is rarer here, but too expensive for home use)
and the MS Script Editor. I've never seen an explanation, nor received
one from the many microsoft folk I've pestered in the past. I mostly
use Venkman nowadays, it may be slower, but it's very reliable.If you
know the cause of and solution to the above, I would be for ever in
your debt.

[Randy Webb]

Jeff wrote:

Hey Dr. John!

Well, anyone that's lurked around here knows you harbor an opinion or
two yourself! ;-)
That's human nature, even if John's opinions tend to be biased and
prejudiced at times.
In answer to your question, it's called Google page rank! No, actually,
do a search on Google and look at the results for "Javascript debug".
Oh my god. The backward solutions this community has been resorting to
for the last 10 years is just beyond hope, at least where IE developers
are concerned.
Huh? What is so backwards about plain common sense and a clue about what
you are doing? Besides, any scripter knows that IE is the worst place to
try to develop.
It's time for everyone to sing from the same page in the hymnal my
friend.

Then join the choir. But how does an IE debugger contribute to
cross-browser scripting?

Just for curiosity, what does the MS debugger have to say about the
following statement:

if (!someVar){
alert('It could be null or it could be false');
}

And please read the groups FAQ, thoroughly.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Answer:It destroys the order of the conversation
Question: Why?
Answer: Top-Posting.
Question: Whats the most annoying thing on Usenet?

[Jeff]

Steve,

I think if you look in the script editor installer file on my site it
might deal with some of this, but I'll explain further and possibly
update the file, as this is a very common problem and the solution is
simple once understood. I and my associates have installed this
debugger on many machines, and although it is possible to run into
problems, if you follow my instructions it should all work out ok.

I think this problem would be characterized as "auto-attach fails".
When you first start your browser, then encounter a bug in a script and
the debugger comes up, I would call that auto-attach. It is also
possible to manually attach to the browser once the debugger is opened,
and place a break point, but that should not be necessary and is
obviously, not as easy to use.

The way I have solved this, is to open a new browser window. Simply go
to NEW:WINDOW and that will open a new browser in the same session (if
you are doing JSP/ASP for instance) and then close the old window.
Notice now, the VIEW menu will now have the DEBUGGER option listed.

I think you will find that when auto-attach fails, the DEBUGGER option
is not listed under the VIEW menu, but when it is working correctly,
the DEBUGGER option is there. SO, a good way to figure out if
auto-attach is not currently enabled is just check for the DEBUGGER
option under the VIEW menu. If it's there, you are all set, if it's
not, open a new window, close the old one, and proceed. IT'S THAT
SIMPLE. TAKES TWO SECONDS! ;-) Hope this helps.

I have noticed that this bug goes away when MS Office 2003 is used,
rather than 2002 which I have. Some of the guys where I work got 2003
when they got new machines, and they don't seem to have this problem
with the debugger. This is anecdotal, I can't be sure, but I think the
newer scripting environment with XPSP2 does not have this problem with
MS Office 2003. IF ANYONE CAN CONFIRM THIS ON OFFICE 2003, PLEASE POST
BACK HERE AND WE WILL ALL KNOW FOR SURE.

Check the file on my site for other debugging procedures as well; there
are many ways to use the debugger, and I'll keep updating the file as I
find new features and tips to share.

Just to reiterate and expand for Dr. John a bit, the reason I find it
important to share this information is over the years, Javascript has
gotten a bad rap. C and Java developers have derided JS to no end, and
it's all become rather old in the face of modern realities. There are
now robust debugging environments for JS, the RegEx support is great,
the object oriented features of the language are second to none,
TRY/CATCH blocks and error handling are excellent. Javascript 1.5 is a
great language on almost any browser that supports it and it's time for
people to start giving this language the respect it deserves.

Anybody that doesn't agree can go talk to Mr. Douglas Crockford, who
does a great write-up on the object oriented features of JS and the
mythologies surrounding the language in general, here:
javascript: The World's Most Misunderstood Programming Language

http://crockford.com/
Have a great day,
Jeff Papineau
xx**@mandala.com

[Jeff]

Hey Randy,

I got a question for you; how come the bleeding faq has not been
updated in a year?

Seems like somebody ran out of gas...

Jeff-
Randy Webb wrote:

Jeff wrote:

Hey Dr. John!

Well, anyone that's lurked around here knows you harbor an opinion or
two yourself! ;-)

That's human nature, even if John's opinions tend to be biased and
prejudiced at times.

In answer to your question, it's called Google page rank! No, actually,
do a search on Google and look at the results for "Javascript debug".
Oh my god. The backward solutions this community has been resorting to
for the last 10 years is just beyond hope, at least where IE developers
are concerned.

Huh? What is so backwards about plain common sense and a clue about what
you are doing? Besides, any scripter knows that IE is the worst place to
try to develop.

It's time for everyone to sing from the same page in the hymnal my
friend.

Then join the choir. But how does an IE debugger contribute to
cross-browser scripting?

Just for curiosity, what does the MS debugger have to say about the
following statement:

if (!someVar){
alert('It could be null or it could be false');
}

And please read the groups FAQ, thoroughly.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Answer:It destroys the order of the conversation
Question: Why?
Answer: Top-Posting.
Question: Whats the most annoying thing on Usenet?

[Randy Webb]

Jeff wrote:

Hey Randy,

I got a question for you;
OK, I have an answer for you.
how come the bleeding faq has not been updated in a year?
If you would bother to read it, you would learn how/when it is updated.
It even tells you how to have something potentially added to it or modified.
Seems like somebody ran out of gas...

Not hardly.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Answer:It destroys the order of the conversation
Question: Why?
Answer: Top-Posting.
Question: Whats the most annoying thing on Usenet?

[Jeff]

I've read it several times, and it left me out in the cold every
time...

For instance:

<faq>

Venkman - Mozilla Visual JS debugger:-
http://www.mozilla.org/projects/venkman/

<faq/>

I'd like to read it more often but it's the same tired stuff I read a
year ago and it simply didn't help me much when I read it then either.

I'd really like to see the faq me a lot more dynamic, more like a wiki
page (see wikipedia) instead of some dusty document that I have to blow
off and put on a face mask before I consult. I do not get the
impression there are many contributors to it!

Perhaps it simply reflects the priesthood whom shepards it but I'd
really like to believe we could do a little better around here.
Randy Webb wrote:

Jeff wrote:

Hey Randy,

I got a question for you;

OK, I have an answer for you.

how come the bleeding faq has not been updated in a year?

If you would bother to read it, you would learn how/when it is updated.
It even tells you how to have something potentially added to it or modified.

Seems like somebody ran out of gas...

Not hardly.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Answer:It destroys the order of the conversation
Question: Why?
Answer: Top-Posting.
Question: Whats the most annoying thing on Usenet?

[steveH]

Jeff, thanks for the tip - bloody hell, you don't know how much
frustration this little issue has caused me over the years and the
solution is so simple, I should have experimented a bit more... I agree
there's been a dearth of information for years for anyone trying to do
serious development in JS, it's been every man for himself (with
notable exceptions such as Mr Crockford and a few others) . With the
current hype around AJAX and explosion of information on JS on the web,
it will be interesting to see if it's image amongst the
<chuckle>serious</chuckle> developers changes, as they scramble to
make their various server-side frameworks 'AJAX-Enabled'.

[Christopher J. Hahn]

steveH wrote:

Jeff, thanks for the tip - bloody hell, you don't know how much
frustration this little issue has caused me over the years and the
solution is so simple, I should have experimented a bit more... I agree
there's been a dearth of information for years for anyone trying to do
serious development in JS, it's been every man for himself (with
notable exceptions such as Mr Crockford and a few others) . With the
current hype around AJAX and explosion of information on JS on the web,
it will be interesting to see if it's image amongst the
<chuckle>serious</chuckle> developers changes, as they scramble to
make their various server-side frameworks 'AJAX-Enabled'.

I have to disagree about a dearth of information. JavaScript has had
massive online support since its initial release, including free script
archives, columns in technical publications, lively debates over
specifications and implementation details, constant development and
literally billions of examples. There've been thousands of tutorials
available for years, many of them excellent; tons of books on the
subject; dedicated support forums and newsgroups; and documentation out
the wazoo.

If anything, there's been too much information-- much of the advice
that one finds on the web is misguided, wrong, or just way out of date.

But despite that, it's still hard for a serious developer to really
take JavaScript seriously. There's simply too much that you can't do
with it. JS is pretty neat, but that's about as far as it goes. I love
the language myself, but I just can't see it as anything more than a
neat trick, and that's only partly the fault of the language itself.

Adding one object like XMLHTTPRequest will not elevate JS to the status
of Java or C.

But giving me the ability to add such objects myself would certainly
bring it closer. The closest thing I've seen to that is ActiveX, but...
well it just doesn't cut it.

For now, JavaScript remains a good way to add some helpful or cool
features to a webpage.

[Lasse Reichstein Nielsen]

"Christopher J. Hahn" <cj****@gmail.com> writes:

If anything, there's been too much information-- much of the advice
that one finds on the web is misguided, wrong, or just way out of date.
The problem could stem from having no central authority willing to set
guidelines for use. Neither Netscape nor Microsoft have lead the way
to quality scripting, probably because Netscape tanked before any
consensus about what's good and what's bad emerged, and Microsoft
wanted to encourage habits that were not compatible with other
browsers.
But despite that, it's still hard for a serious developer to really
take JavaScript seriously. There's simply too much that you can't do
with it.
Here you should distinguish the language (really ECMAScript these
days) and the environment it runs in (as diverse as browsers, servers
(Netscape and ASP), WSH, anything with Rhino or Spidermonkey embedded,
etc.).

The language is small, although larger than, e.g., C. It is general
purpose programming language, although not one designed for larger
systems (it doesn't allow for easy modularization and encapsulation,
which would make larger systems more easily combined from individual
components).
JS is pretty neat, but that's about as far as it goes. I love
the language myself, but I just can't see it as anything more than a
neat trick, and that's only partly the fault of the language itself.
Exactly :)
For now, JavaScript remains a good way to add some helpful or cool
features to a webpage.

When used in a browser, Javascript is the simplest way to enhance the
behavior of the page. That doesn't make a browser the best platform
for every application, XMLHTTPRequest or not :)

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Jeff]

While I certainly grant everyone their points, let's not forget that
XMLHttpRequest object does not change much, except make async
requests/browser DOM updates a little eaiser to do.

JSRS (Iframe pooling) has been around for a long time and works quite
well as an async transport, and is not disabled as soon as ActiveX is
disabled (IE only), which does happen in some enterprise IT settings.

http://www.ashleyit.com/rs/jsrs/test.htm

Where AJAX is really coming into play is that it is pushing the
dividing line in a client-server web application TOWARD THE CLIENT.
This is a very important distinction, because often times there are
many ways to skin the cat, and web clients are becoming more and more
sophisticated over time (see gmail, pump some data into it and see what
I mean).

The time has come to really expand upon and explore the depths and
capabilities in a client server web application and we have a very
robust toolkit with which to do it. And industry recognition of the
power of such at the same time...

We all recognize the a web application is not put together with just
Javascript. JS has it's limitations. So be it. Learn about 4-5
languages including JS and have at it.

Jeff-

Lasse Reichstein Nielsen wrote:

"Christopher J. Hahn" <cj****@gmail.com> writes:

If anything, there's been too much information-- much of the advice
that one finds on the web is misguided, wrong, or just way out of date.

The problem could stem from having no central authority willing to set
guidelines for use. Neither Netscape nor Microsoft have lead the way
to quality scripting, probably because Netscape tanked before any
consensus about what's good and what's bad emerged, and Microsoft
wanted to encourage habits that were not compatible with other
browsers.

But despite that, it's still hard for a serious developer to really
take JavaScript seriously. There's simply too much that you can't do
with it.

Here you should distinguish the language (really ECMAScript these
days) and the environment it runs in (as diverse as browsers, servers
(Netscape and ASP), WSH, anything with Rhino or Spidermonkey embedded,
etc.).

The language is small, although larger than, e.g., C. It is general
purpose programming language, although not one designed for larger
systems (it doesn't allow for easy modularization and encapsulation,
which would make larger systems more easily combined from individual
components).

JS is pretty neat, but that's about as far as it goes. I love
the language myself, but I just can't see it as anything more than a
neat trick, and that's only partly the fault of the language itself.

Exactly :)

For now, JavaScript remains a good way to add some helpful or cool
features to a webpage.

When used in a browser, Javascript is the simplest way to enhance the
behavior of the page. That doesn't make a browser the best platform
for every application, XMLHTTPRequest or not :)

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Dr John Stockton]

JRS: In article <11**********************@g14g2000cwa.googlegroups .com>
, dated Mon, 4 Jul 2005 16:46:15, seen in news:comp.lang.javascript,
Jeff <su******@gmail.com> posted :

Lines: 54
Hey Randy,

I got a question for you; how come the bleeding faq has not been
updated in a year?

Seems like somebody ran out of gas...

Jeff-
Randy Webb wrote:

Jeff wrote:

It seems that, even if you have read it, you have not actually been able
to understand parts of it; to suggest any other explanation for your
ill-formatted responses would be to accuse you of bad manners.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Jeff]

Dr John Stockton wrote:

It seems that, even if you have read it, you have not actually been able
to understand parts of it; to suggest any other explanation for your
ill-formatted responses would be to accuse you of bad manners.

Anyone care to decypher this cryptogram for me? I would be forever in
thier debt.

It's EXACTLY this kind of blather that makes this group so difficult to
enjoy in my estimation... we yanks don't appreciate this kind of
PRETENTIOUS crap.

[Jeff]

Randy Webb wrote:

Huh? What is so backwards about plain common sense and a clue about what
you are doing? Besides, any scripter knows that IE is the worst place to
try to develop. ....
Just for curiosity, what does the MS debugger have to say about the
following statement:

if (!someVar){
alert('It could be null or it could be false');
}

The MS Script Editor doesn't have much to say about a line of code that
executes normally... This line evalutes the same in Moz and IE so I
guess I don't get your point. What is your point?

Personally I've always found IE easier to develop scripts for in
general.

I like the fact IE allows more shorthand in DOM references (does not
require 'document.' notation in most cases) and supported Iframes and
innerHTML long before the other browsers. I spent years wishing the
other browsers would catch up in this regard and finally they did on
most counts.

So I guess "any scripter knows" is slightly inaccurate. You are of
course, entitled to your own opinion.

[Christopher J. Hahn]

Lasse Reichstein Nielsen wrote:

"Christopher J. Hahn" <cj****@gmail.com> writes:

If anything, there's been too much information-- much of the advice
that one finds on the web is misguided, wrong, or just way out of date.
The problem could stem from having no central authority willing to set
guidelines for use. Neither Netscape nor Microsoft have lead the way
to quality scripting, probably because Netscape tanked before any
consensus about what's good and what's bad emerged, and Microsoft
wanted to encourage habits that were not compatible with other
browsers.

I think we're getting away from that, though. As the language continues
to distinguish itself from other standards with which it was
traditionally equated (the DOM, et cetera), the development community
is learning more about what JavaScript really is. Microsoft's
incorrigible behavior aside, we're gradually getting closer to a real
scripting language with more consistent information being promulgated
in general.

But despite that, it's still hard for a serious developer to really
take JavaScript seriously. There's simply too much that you can't do
with it.

Here you should distinguish the language (really ECMAScript these
days) and the environment it runs in (as diverse as browsers, servers
(Netscape and ASP), WSH, anything with Rhino or Spidermonkey embedded,
etc.).

The language is small, although larger than, e.g., C. It is general
purpose programming language, although not one designed for larger
systems (it doesn't allow for easy modularization and encapsulation,
which would make larger systems more easily combined from individual
components).

For some examples of what I consider essential functionality missing
from the language itself:
Module importation must be provided for so that we can consistently and
reliably extend the functionality of the language, or the language spec
needs to cover a lot more.

Other lower-level features would also be really convenient, such as
operator overloading or functionality similar to it (valueOf and
setValueOf methods, et cetera).

Passing objects by value and primitives by reference would also be
nice.

Far too much of it is obfuscated from the developer, as well. See also
[native code]. That and we aren't allowed to modify the behavior of the
language itself, only of the objects therein. And even then the
internal behaviors of the objects provided by the environment are often
impossible to modify without breaking them, and usually impossible to
duplicate. (Make your own object that somehow manages to keep track of
its length such that I can say: x = new YourObject(); x[ 0 ] = 1; x[ 1
] = 1; alert( x.length ); Why would you want to when there's already an
Array object that does that? Well... what if I want to calculate the
length differently?)

It's impossible to do I/O in JavaScript. I can't create a socket, or
write to a file. The best one can do is to instantiate an object
provided by some other application written in some other language. The
closest thing to I/O in JS is the XMLHTTPRequest, which in the end is
nothing more than another implementation-dependency.

What's more, there's no way to write a library purely in JavaScript
that would let your JS app use I/O.

Like I said, there are some things the language just doesn't provide
for.

If there were some native API to the kernel, regardless of how
abstracted, JS would immediately become a viable "real" language and
good for more than making web pages do tricks.

[snip] When used in a browser, Javascript is the simplest way to enhance the
behavior of the page. That doesn't make a browser the best platform
for every application, XMLHTTPRequest or not :)
Unfortunately the browser remains the most robust,
universally-available application framework to date. So it goes.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

For the record, I'd love to be able to program exclusively in
JavaScript. If I could, for instance, import a DOM library and a common
controls library plus an HTML library and use that to make a webpage,
or import an I/O and process control module to build a server app....
well what would I need PERL for?

[Christopher J. Hahn]

Jeff wrote:

Randy Webb wrote:

Huh? What is so backwards about plain common sense and a clue about what
you are doing? Besides, any scripter knows that IE is the worst place to
try to develop. ...

Just for curiosity, what does the MS debugger have to say about the
following statement:

if (!someVar){
alert('It could be null or it could be false');
}

The MS Script Editor doesn't have much to say about a line of code that
executes normally... This line evalutes the same in Moz and IE so I
guess I don't get your point. What is your point?

Personally I've always found IE easier to develop scripts for in
general.

Agreed. I've actually hit upon more counter-intuitive quirks in
Moz-derivatives than in IE. But that may just be that I'm not using the
things that turn out to be quirkier in IE.

I like the fact IE allows more shorthand in DOM references (does not
require 'document.' notation in most cases) and supported Iframes and
innerHTML long before the other browsers. I spent years wishing the
other browsers would catch up in this regard and finally they did on
most counts.

Allowing the developer to skip document. notation is a major defect in
Microsoft's implementation. There should be no "default namespace"
other than the current. To assume that any unqualified reference even
*might* be intended to refer to a member of a member of the topmost
object, as opposed to the object nearest on the scope chain, is insane.
If I really wanted to avoid document. notation, I'd use with(
window.document ) and be explicit about it.

Though I won't argue about IE giving more scripting support over a
period of some years, I can't say that that support has always been
consistent with itself, the specs, or best practices.

[snip]

[bgulian]

>Unfortunately the browser remains the most robust,

universally-available application framework to date. So it goes.

You have hit upon the key problem and reason why relying on any
javascript debugger is naive, at best. There is no way to step through
the html rendering process in any debugger. We can use the .NET
debugger or Windows Scripting Debugger to step through javascript
functions but the larger part of the page loading process will always
be hidden from us. In my opinion, debuggers are just one small part of
the process of guessing what went wrong. Often, I'll go weeks without
using them at all.

What is really needed is a 'Browser debugger' but that is not likely
coming, especially from MS who have pretty much turned their backs on
client-side development. .NET is an incredible debugger when you're
using .NET but, as I said, fairly useless when you're debugging
client-side javascript.

It's obvious that we'd all like to see some big improvements in
javascript but that's not going to happen until one of the big browsers
decides to make rendering a transparent process with hooks for
debuggers, file i/o, etcetera. Don't look to MS. I'd say Mozilla must
have some client side plan they're brewing, we can only hope it has
something to do with javascript.

[Christopher J. Hahn]

bg*****@gmail.com wrote:

Unfortunately the browser remains the most robust,
universally-available application framework to date. So it goes.

You have hit upon the key problem and reason why relying on any
javascript debugger is naive, at best. There is no way to step through
the html rendering process in any debugger. We can use the .NET
debugger or Windows Scripting Debugger to step through javascript
functions but the larger part of the page loading process will always
be hidden from us. In my opinion, debuggers are just one small part of
the process of guessing what went wrong. Often, I'll go weeks without
using them at all.

What is really needed is a 'Browser debugger' but that is not likely
coming, especially from MS who have pretty much turned their backs on
client-side development. .NET is an incredible debugger when you're
using .NET but, as I said, fairly useless when you're debugging
client-side javascript.

It's obvious that we'd all like to see some big improvements in
javascript but that's not going to happen until one of the big browsers
decides to make rendering a transparent process with hooks for
debuggers, file i/o, etcetera. Don't look to MS. I'd say Mozilla must
have some client side plan they're brewing, we can only hope it has
something to do with javascript.

Check out the DOM Inspector, built into Moz (or at least FireFox). It's
not entirely what you're talking about, but it is incredibly useful as
a part of it.

[Thomas 'PointedEars' Lahn]

Dr John Stockton wrote:

When anyone puffs a product as repeatedly as you have done, it will be
wisely assumed that the puffer is an egomaniac, a complete prat, or
possessed of a financial interest.

Please, then, explain your behaviour.

It's a bloody spammer, simple as that. Try

| X-Complaints-To: gr**********@google.com

and don't feed it. Thanks in advance.
PointedEars
--
Microsoft has been doing a really bad job on their OS. -- Linus Torvalds

[Dr John Stockton]

JRS: In article <11****************@PointedEars.de>, dated Sat, 16 Jul
2005 15:39:00, seen in news:comp.lang.javascript, Thomas 'PointedEars'
Lahn <Po*********@web.de> posted :

Dr John Stockton wrote:

When anyone puffs a product as repeatedly as you have done, it will be
wisely assumed that the puffer is an egomaniac, a complete prat, or
possessed of a financial interest.

Please, then, explain your behaviour.

It's a bloody spammer, simple as that. Try

| X-Complaints-To: gr**********@google.com

and don't feed it. Thanks in advance.

The article quoted is nearly a fortnight old; the thread died about a
week ago. If you had a modicum of consideration for others, you would
either not bother with ancient threads, or at least give a clear
indication in the body of your pointless article as envisaged by USEFOR.

By reviving the thread, you are feeding it : your general stupidity is
quite impressive.

By the way, I expect you to confess your error in a self-abasing fashion
when you do eventually discover proof on the Web of the correctness of
my assertion of the introduction of clock-advancing on Sunday
1916-09-26.

Heil Thomas!

--
© John Stockton, Surrey, UK. ??*@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.

[Thomas 'PointedEars' Lahn]

Dr John Stockton wrote:

[...] Thomas 'PointedEars' Lahn [...] posted :

Dr John Stockton wrote:

When anyone puffs a product as repeatedly as you have done, it will be
wisely assumed that the puffer is an egomaniac, a complete prat, or
possessed of a financial interest.

Please, then, explain your behaviour.
It's a bloody spammer, simple as that. Try

| X-Complaints-To: gr**********@google.com

and don't feed it. Thanks in advance.

The article quoted is nearly a fortnight old; the thread died about a
week ago. If you had a modicum of consideration for others, you would
either not bother with ancient threads,

Usenet is not a real-time medium and nobody is obliged to ignore older
threads. Especially, since expiration settings differ from one news
server to another -- while an expiration setting of two months, the
so-called Usenet memory, is common --, there is no standard saying that
a posting can be considered too old so that it should not be commented
on; instead, if someone provides new information, he is free to do so
and use the old thread rather than create a new one. To state otherwise,
shows a great lack of understanding about the used communication medium.
or at least give a clear indication in the body of your pointless article
as envisaged by USEFOR.
Oh my, I thought we got through this.
USEFOR does NOT envisage or recommend anything of the kind:

,-<http://www.ietf.org/internet-drafts/draft-ietf-usefor-useage-01.txt>
|
| INTERNET-DRAFT Charles H. Lindsey
| Usenet Format Working Group University of Manchester
| March 2005
|
| Usenet Best Practice
| <draft-ietf-usefor-useage-01.txt>
| [...]
| Internet-Drafts are draft documents valid for a maximum of six
| months and may be updated, replaced, or obsoleted by other
| documents at any time. It is inappropriate to use Internet-Drafts
| as reference material or to cite them other than as "work in
| progress."
By reviving the thread, you are feeding it :
1. The thread could not be considered dead and so it could not be revived.
2. Yes, I fe(e)d it, for good reasons.
By the way, I expect you to confess your error in a self-abasing fashion
when you do eventually discover proof on the Web of the correctness of
my assertion of the introduction of clock-advancing on Sunday
1916-09-26.
You still don't get it? *You* made the claim, *you* have to prove it!
Heil Thomas!

Godwin's Law[1] again. How boring.
PointedEars
___________
[1] http://en.wikipedia.org/wiki/Godwin's_law

[Dr John Stockton]

JRS: In article <27****************@PointedEars.de>, dated Sun, 17 Jul
2005 08:18:46, seen in news:comp.lang.javascript, Thomas 'PointedEars'
Lahn <Po*********@web.de> posted :

Dr John Stockton wrote:

[...] Thomas 'PointedEars' Lahn [...] posted :

It's a bloody spammer, simple as that. Try

The article quoted is nearly a fortnight old; the thread died about a
week ago. If you had a modicum of consideration for others, you would
either not bother with ancient threads,

Usenet is not a real-time medium and nobody is obliged to ignore older
threads. Especially, since expiration settings differ from one news
server to another -- while an expiration setting of two months, the
so-called Usenet memory, is common --, there is no standard saying that
a posting can be considered too old so that it should not be commented
on; instead, if someone provides new information, he is free to do so
and use the old thread rather than create a new one. To state otherwise,
shows a great lack of understanding about the used communication medium.

You have an over-inflated sense of your own importance. A typical
technician's response, based on technical feasibility rather than on
common sense.

By the way, I expect you to confess your error in a self-abasing fashion
when you do eventually discover proof on the Web of the correctness of
my assertion of the introduction of clock-advancing on Sunday
1916-09-26.

You still don't get it? *You* made the claim, *you* have to prove it!

No, I do not. You can believe it or not, as you wish; but your own
inability to find out about Sunday 1915-09-26 on the Web or elsewhere is
of no importance. I have verified that the information that I provided
here earlier is sufficient for a search engine; in fact at least one
copy of the prime source is on the Web - well worth reading, if a
faithful copy of the book. However, for the basic facts, a search
engine is not needed.

You chose to allege falseness, based on your own search; it is for you
to acknowledge that you did not seek the information intelligently.

Heil Thomas!

Godwin's Law[1] again. How boring.

A juvenile response. Since you choose to post dictatorially, you must
expect to be likened to a dictator.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm uksumtim.htm etc.

[Doug No]

<i> (it doesn't allow for easy modularization and encapsulation, which
would make larger systems more easily combined from individual
components)</i>

Wrong. very wrong :-)

Encapsulation and modularization is actually quite easy.
See the project DynAPI at http://sourceforge.net/DynAPI
This is a cros-browser, cross-platform layers based javascript scripting
library.

Seperate functionality is contained in seperate files:
I.E. mouse events are seperated from layer rendering code ect.
ALSO the library DYNAMICALLY loads external js files as needed.

For instance, the Layer rendering and handling code is seperated into
induvidual files by browsers as is the mouse even handling code. The
Library object in DynAPI is used to dynamically load only that code
which applies to the current browser, as well as allowing the user to
choose which modules to load and which to not. (if you don't want/need
mouse events.. don't load them!)

I.E. mouse_ie.js is loaded for IE, and mouse_ns4.js is leaded for NS 4
and firefox/mozilla and basically any dom standard browser uses
mouse_dom.js.

If you want more information on how the dynamic file inclusion works, as
well as how to properly encapsulate code modules do drop us a line on
the DynAPI forums linked to from the above website.

Cheers

*** Sent via Developersdex http://www.developersdex.com ***

[Doug_Melvin]

QUOTE: (it doesn't allow for easy modularization and encapsulation,
which would make larger systems more easily combined from individual
components)

--------------

Wrong. Very wrong :-)

Encapsulation and modularization is actually quite easy.
See the project DynAPI at http://sourceforge.net/DynAPI
This is a cros-browser, cross-platform layers based javascript scripting
library.

Seperate functionality is contained in seperate files:
I.E. mouse events are seperated from layer rendering code ect.
ALSO the library DYNAMICALLY loads external js files as needed.

For instance, the Layer rendering and handling code is seperated into
induvidual files by browsers as is the mouse even handling code. The
Library object in DynAPI is used to dynamically load only that code
which applies to the current browser, as well as allowing the user to
choose which modules to load and which to not. (if you don't want/need
mouse events.. don't load them!)

I.E. mouse_ie.js is loaded for IE, and mouse_ns4.js is leaded for NS 4
and firefox/mozilla and basically any dom standard browser uses
mouse_dom.js.

If you want more information on how the dynamic file inclusion works, as
well as how to properly encapsulate code modules do drop us a line on
the DynAPI forums linked to from the above website.

Cheers

(i appologize if this get's posted twice, but i appears that the first
one got dumpped as spam due to my putting the quit in itallic.. teach me
to read the big red text before posting :-)
---
Reality is in the perception of the beholder (me.. 1997)

*** Sent via Developersdex http://www.developersdex.com ***