ASP Debugging Text Editor

Discussion in 'ASP General' started by rn5a@rediffmail.com, Apr 10, 2007.

  1. Guest

    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, 2007
    #1
    1. Advertising

  2. Evertjan. Guest

    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)
     
    Evertjan., Apr 10, 2007
    #2
    1. Advertising

  3. "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)
     
    Mark J. McGinty, Apr 11, 2007
    #3
  4. Evertjan. Guest

    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)
     
    Evertjan., Apr 11, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stylus Studio
    Replies:
    0
    Views:
    764
    Stylus Studio
    Aug 3, 2004
  2. Hatem KNANI
    Replies:
    2
    Views:
    681
    Morphon Technologies
    Aug 4, 2003
  3. Stylus Studio
    Replies:
    0
    Views:
    522
    Stylus Studio
    Aug 3, 2004
  4. SyncRO Soft
    Replies:
    0
    Views:
    522
    SyncRO Soft
    Jul 21, 2005
  5. Mark Hahn
    Replies:
    0
    Views:
    368
    Mark Hahn
    Sep 1, 2003
Loading...

Share This Page