Re: ASP Debugging Text Editor
am 10.04.2007 10:19:57 von exjxw.hannivoort
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)
Re: ASP Debugging Text Editor
am 11.04.2007 21:24:35 von mmcginty
"Evertjan." wrote in message
news:Xns990E68C40D84eejj99@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)
Re: ASP Debugging Text Editor
am 12.04.2007 00:01:22 von exjxw.hannivoort
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)