By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,625 Members | 1,283 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,625 IT Pros & Developers. It's quick & easy.

ASP Debugging Text Editor

P: n/a
Can someone please suggest me a text editor especially for DEBUGGING
ASP scripts apart from Microsoft Visual Interdev?

I tried using Visual Interdev & created a project but Interdev
generates some error related to FrontPage extensions. I couldn't
exactly understand the error. I tried to create the project in C:
\Inetpub\wwwroot. If I just open a ASP file (by navigating to the
File-->Open File... menu), then Interdev doesn't give the option to
debug.

Please do not suggest using Response.Write, Response.End etc. I guess
I am aware of most of such debugging techniques that are globally used
by ASP developers :-)

Apr 10 '07 #1
Share this Question
Share on Google+
5 Replies


P: n/a
wrote on 10 apr 2007 in microsoft.public.inetserver.asp.general:
Can someone please suggest me a text editor especially for DEBUGGING
ASP scripts apart from Microsoft Visual Interdev?
Is that a text editor?
I tried using Visual Interdev & created a project but Interdev
generates some error related to FrontPage extensions. I couldn't
exactly understand the error. I tried to create the project in C:
\Inetpub\wwwroot. If I just open a ASP file (by navigating to the
File-->Open File... menu), then Interdev doesn't give the option to
debug.

Please do not suggest using Response.Write, Response.End etc. I guess
I am aware of most of such debugging techniques that are globally used
by ASP developers :-)
Your guess being as good as mine, I still would urge you to use that, as
ASP is just a platform, and you would have to debug either serverside
jscript or vbscript [or both together] and perhaps database sql, serverside
includes, coms, asp objects, COMBINED with the resulting html/xml/jpg/etc
stream with clientside code, DOM, crossbrowser incompatibilities.

A would-be debugging programme only would help you to find obvious little
mistakes, or help you to insert the dreaded [by you] Response.Write-
Response.End combinations.

btw, inserting more sophisticated "breakpoints" that do not break, but log
the state at several points is also possible. It all depends on the kind of
proramme you wrote and your abilities to understand your programme's
testing requirements.

A good start would be to write a modular ["black-boxes"] programme, if the
code holds more than a few lines, testing and debugging them seperately,
and often look at the resulting view-sourced html, while debugging.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Apr 10 '07 #2

P: n/a

"Evertjan." <ex**************@interxnl.netwrote in message
news:Xn*******************@194.109.133.242...
wrote on 10 apr 2007 in microsoft.public.inetserver.asp.general:
>Can someone please suggest me a text editor especially for DEBUGGING
ASP scripts apart from Microsoft Visual Interdev?

Is that a text editor?
>I tried using Visual Interdev & created a project but Interdev
generates some error related to FrontPage extensions. I couldn't
exactly understand the error. I tried to create the project in C:
\Inetpub\wwwroot. If I just open a ASP file (by navigating to the
File-->Open File... menu), then Interdev doesn't give the option to
debug.
Interdev's option to [start a script or document to] debug is so horribly
limited and contrived, that I've never tried very hard to make it work. I
don't even use Interdev project defintions much at all, they add a lot
meaningless depth to project directory trees, and tend to impose irritating
name/storage location restrictions.

otoh, I *do* use the hell out of Interdev's IDE-style object-level debugger,
it is top-notch, and I've seen nothing that compares. Ironically, the
weakest aspect of it far and away, is the difficulty involved in invoking it
(partly due to the ridiculous way the mechanisms that might intuitively seem
to do this, actually behave.)

Much more workable, the Debug->Processes dialog lets you attach to
debuggable script processes running on both the client and server sides
(given both are running on the same PC.) Once attached you can browse the
tree of running scripts, drill into them, set break points, etc.

Also effective is to hard-code strategic break points using Stop (vbs) or
debugger; (jscript) but realize that these will typically have no effect
unless you have already attached a debugger to the process.

If you're looking for edit-and-continue, a la VB6, I haven't seen it, and I
doubt (given the nature of ASP's script processing environment) that is
exists. You have to open a file separately to edit it, the debugger's
source code view won't allow you to do this. You can, however, have a given
file opened in an editor window at the same time it is displayed as source
in the debugger. You will of course need to cause the file to be
re-executed after you save your changes. (Hard-coded break points are real
handy if you need to repeat the save-reload cycle more than a few times.)

But you can manually assign values to variables, move the next line to
execute pointer to skip or re-execute lines of code, and do all sorts of
creative things in the immediate window. I find it very functional and
wouldn't be without it.

>Please do not suggest using Response.Write, Response.End etc. I guess
I am aware of most of such debugging techniques that are globally used
by ASP developers :-)

Your guess being as good as mine, I still would urge you to use that, as
ASP is just a platform, and you would have to debug either serverside
jscript or vbscript [or both together] and perhaps database sql,
serverside
includes, coms, asp objects, COMBINED with the resulting html/xml/jpg/etc
stream with clientside code, DOM, crossbrowser incompatibilities.
What? How could it be a.) intuitive, b.) advantageous or c.) even remotely
plausible to debug client and server sides combined? Note that Interdev
*can* debug both sides of the same document from within a single IDE, but
they are definitely not combined, they are separate debugging tasks,
separate script interpreter processes, obviously separate scopes --
typically, in real life, running on separate machines! (But software
development is a far cry from real life...)

In practice I can't recall ever even wanting to interactively debug both
sides at once. Even if it might be technically possible to dynamically
generate client-side script designed to run before its host document has
been completely downloaded and rendered, there's no feasible way that script
could influence the way the remainder of its doc was generated by the
server.

Client requests; server generates/sends; client [browser] receives/renders a
document -- very clean lines of separation, no blur of client<->server
interaction beyond the request. Server-side includes are inlined.
Graphics/binary content are downloaded in separate requests as the doc is
rendered. SQL is interpreted by yet another process, accessed via COM
interfaces. You know all of this, don't you?

A would-be debugging programme only would help you to find obvious little
mistakes, or help you to insert the dreaded [by you] Response.Write-
Response.End combinations.
I guess I have to assume you haven't had much luck with debuggers, because
if you had I sure you'd agree that's a really
uninformed/inexperienced/short-sighted point of view. Using a debugger is
by far the most efficient way to find subtle bugs and unexpected data and/or
flow. Your statement that a debugger will "only help to find obvious little
mistakes" is inaccurate, untrue, it's just plain wrong!

There is no substitute for being able to step through a program, line for
line, watching values of variables change, with the ability to navigate the
call stack, and set breakpoints based on expressions -- no substitute!

You could code-up log outputs until your fingers bleed, but even if you
logged the value of every single variable [in scope] after every single line
of script was executed, you still wouldn't have a significant fraction of
what real debugging has to offer.

You should've said, "a debugger will only help you [in any way] if you can
somehow manage to invoke it and figure out how to attach it to your running
code's context." That would've not only been perfectly accurate, it
would've better reflected the amount you actually know about modern-day
debuggers (which, I suspect, is practically nothing at all.)
-Mark

btw, inserting more sophisticated "breakpoints" that do not break, but log
the state at several points is also possible. It all depends on the kind
of
proramme you wrote and your abilities to understand your programme's
testing requirements.

A good start would be to write a modular ["black-boxes"] programme, if the
code holds more than a few lines, testing and debugging them seperately,
and often look at the resulting view-sourced html, while debugging.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Apr 11 '07 #3

P: n/a
Mark J. McGinty wrote on 11 apr 2007 in
microsoft.public.inetserver.asp.general:
You should've said, "a debugger will only help you [in any way] if you
can somehow manage to invoke it and figure out how to attach it to
your running code's context." That would've not only been perfectly
accurate, it would've better reflected the amount you actually know
about modern-day debuggers (which, I suspect, is practically nothing
at all.)
That can go both ways, and I could suggest you do not know how to
effectivly work without a hefty debugger, but I won't, because the
paragraph above is nonsense in itself, as why should it reflect what
you think I know about "modern-day debuggers", if you think I don't know
about them, and also be pefectly accurate?

The question asked many a time in this NG about ASP debugging is clearly,
clearly to me, that is, asked by those that have no experience with
effective hand debugging, sometimes having knowledge of compiler language
debugging, which is fairly different from the server/client script
debugging needed.

To deprive them from learning the art of debugging not only is bad for
their education, but also deprives them of the joy of seeing and
understanding their work coming to perfection.

btw, what is a "running code's context"?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Apr 11 '07 #4

P: n/a
try using "on error resume next" with error trapping

see here for example , google for more.

http://powerasp.com/content/new/on-e...esume-next.asp

<rn**@rediffmail.comwrote in message news:11**********************@n59g2000hsh.googlegr oups.com...
Can someone please suggest me a text editor especially for DEBUGGING
ASP scripts apart from Microsoft Visual Interdev?

I tried using Visual Interdev & created a project but Interdev
generates some error related to FrontPage extensions. I couldn't
exactly understand the error. I tried to create the project in C:
\Inetpub\wwwroot. If I just open a ASP file (by navigating to the
File-->Open File... menu), then Interdev doesn't give the option to
debug.

Please do not suggest using Response.Write, Response.End etc. I guess
I am aware of most of such debugging techniques that are globally used
by ASP developers :-)

Apr 11 '07 #5

P: n/a
another option, perhaps worth a look..

http://en.ewebxp.com/products/aspstudio/index.asp

"Jon Paal [MSMD]" <Jon nospam Paal @ everywhere dot comwrote in message news:13*************@corp.supernews.com...
try using "on error resume next" with error trapping

see here for example , google for more.

http://powerasp.com/content/new/on-e...esume-next.asp

<rn**@rediffmail.comwrote in message news:11**********************@n59g2000hsh.googlegr oups.com...
>Can someone please suggest me a text editor especially for DEBUGGING
ASP scripts apart from Microsoft Visual Interdev?

I tried using Visual Interdev & created a project but Interdev
generates some error related to FrontPage extensions. I couldn't
exactly understand the error. I tried to create the project in C:
\Inetpub\wwwroot. If I just open a ASP file (by navigating to the
File-->Open File... menu), then Interdev doesn't give the option to
debug.

Please do not suggest using Response.Write, Response.End etc. I guess
I am aware of most of such debugging techniques that are globally used
by ASP developers :-)


Jun 27 '07 #6

This discussion thread is closed

Replies have been disabled for this discussion.