Evertjan. said:
wrote on 10 apr 2007 in microsoft.public.inetserver.asp.general:
Is that a text editor?
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.
