Body tag preventing 'window.open' from executing

Discussion in 'Javascript' started by alanstew, Apr 9, 2004.

  1. alanstew

    alanstew Guest

    With the body tag calling out 'window onload', a function with a
    'window.open' fails at the 'window.open' line. If I cut out the body
    tag, the function executes as normal.
    At first I thought it was the entire function failing, but I tested
    with alerts and found that it was only the 'window.open' that fails to
    execute.
    The function is being called by a link, and I suspected some problem
    with the body alink/vlink but after cutting that out I saw no
    improvement.
    There is also a form in the page, and I need the 'window onload' to
    set the focus to the proper control, thus I HAVE to have the Body tag,
    right?

    I have a workaround, but WHAT is causing this (seemingly) bizarre
    behavior?

    Thanks for any clues or outright explanations.
    Alan
     
    alanstew, Apr 9, 2004
    #1
    1. Advertising

  2. alanstew wrote:

    > With the body tag calling out 'window onload', a function with a
    > 'window.open' fails at the 'window.open' line. If I cut out the body
    > tag, the function executes as normal.
    > At first I thought it was the entire function failing, but I tested
    > with alerts and found that it was only the 'window.open' that fails to
    > execute.
    > The function is being called by a link, and I suspected some problem
    > with the body alink/vlink but after cutting that out I saw no
    > improvement.
    > There is also a form in the page, and I need the 'window onload' to
    > set the focus to the proper control, thus I HAVE to have the Body tag,
    > right?
    >
    > I have a workaround, but WHAT is causing this (seemingly) bizarre
    > behavior?
    >
    > Thanks for any clues or outright explanations.
    > Alan


    Perhaps including a URL or some of your code below might help someone to
    help you...

    randelld
     
    Reply Via Newsgroup, Apr 10, 2004
    #2
    1. Advertising

  3. alanstew

    alanstew Guest

    Re: Body tag preventing 'window.open' from executing (with code added)

    Reply Via Newsgroup <> wrote in message news:<wvJdc.63564$oR5.22093@pd7tw3no>...
    > alanstew wrote:
    >
    > > With the body tag calling out 'window onload', a function with a
    > > 'window.open' fails at the 'window.open' line. If I cut out the body
    > > tag, the function executes as normal.
    > > At first I thought it was the entire function failing, but I tested
    > > with alerts and found that it was only the 'window.open' that fails to
    > > execute.
    > > The function is being called by a link, and I suspected some problem
    > > with the body alink/vlink but after cutting that out I saw no
    > > improvement.
    > > There is also a form in the page, and I need the 'window onload' to
    > > set the focus to the proper control, thus I HAVE to have the Body tag,
    > > right?
    > >
    > > I have a workaround, but WHAT is causing this (seemingly) bizarre
    > > behavior?
    > >
    > > Thanks for any clues or outright explanations.
    > > Alan

    >
    > Perhaps including a URL or some of your code below might help someone to
    > help you...
    >
    > randelld


    OK, here is a summary of the page, once again, taking OUT the body
    tag, 'window.open' returns to life...putting it back, 'window.open'
    won't.
    Thanks...


    <SCRIPT ID=clientEventHandlersJS LANGUAGE=javascript>
    <!--
    function LogIn_onsubmit()
    {
    if ((document.LogIn.txtUser.value == "") ||
    (document.LogIn.txtPass.value == ""))
    {
    window.alert("Username AND Password must be entered!!");
    }
    }
    function window_onload()
    {
    //Save Browser values for future use.
    document.LogIn.hidBrowserName.value = strCsBrowser;

    //Set focus.
    document.LogIn.txtUser.focus();
    }
    -->
    </SCRIPT>
    <SCRIPT LANGUAGE="javascript">
    <!--
    function ContactUs()
    {
    window.location = "mailer.asp?Source=Login";
    }

    function PassHelp()
    {
    var w = 400;
    var h = 300;
    var x = Math.round((screen.availWidth - w) / 2);
    var y = Math.round((screen.availHeight - h) / 2);

    window.open('helpmailer.asp', 'windowName', 'left=' + x + ',top=' + y
    + ',width=' + (w - 5) + ',height=' + (h - 33));
    }
    -->
    </SCRIPT>

    <%%>
    <script>SetUp()</script>
    <%
    If Trim(Request.Form("txtPass")) <> "" And
    Trim(Request.Form("txtUser")) <> "" Then
    'Here where the log in validation code goes.
    End If
    %>

    <HTML>
    <title>Log In</title>
    <BODY leftmargin="70" bgColor=lightyellow LANGUAGE=javascript
    onload="return window_onload()">
    <FORM method="POST" name="LogIn" LANGUAGE=javascript onsubmit="return
    LogIn_onsubmit()">
    <font color=green style="font-size:16pt;font-family:Times"><I>Please
    Login</I></font><br><br>
    <font color=green style="font-size:10pt;font-family:Times">Username:
    </font><br>
    <INPUT TYPE=text style="font-size:9pt;font-family:Times" NAME=txtUser>
    <BR><BR>
    <font color=green style="font-size:10pt;font-family:Times">Password:
    </font><br>
    <INPUT TYPE=Password style="font-size:9pt;font-family:Times"
    NAME=txtPass>
    <BR><BR>
    <TABLE border=0>
    <TR>
    <TD align="center"><INPUT TYPE=submit style="Color:green" Value="
    Enter " Name="btnSubmit"></TD>
    <TD align="left" width=5></TD>
    <TD align="left"><INPUT TYPE=reset style="Color:green" Value=Reset
    Name="btnReset"></TD>
    </TR>
    </Table>
    </FORM>
    <INPUT TYPE=hidden NAME=hidBrowserName value="">
    <br>
    <font style="font-size:9pt;font-family:Times">
    <A HREF="javascript:passHelp()" title="Click to get help with
    forgotten username/password.">Username/Password Help</A></font>
    <br>
    <font style="font-size:9pt;font-family:Times">
    <A HREF="javascript:ContactUs()" title="Click to send us an email with
    questions or comments.">Contact Us</A></font>
    </BODY>
    </HTML>
     
    alanstew, Apr 11, 2004
    #3
  4. alanstew

    Ivo Guest

    Re: Body tag preventing 'window.open' from executing (with code added)

    > > alanstew wrote:
    > OK, here is a summary of the page, once again, taking OUT the body
    > tag, 'window.open' returns to life...putting it back, 'window.open'
    > won't.
    > Thanks...
    >
    >
    > <SCRIPT ID=clientEventHandlersJS LANGUAGE=javascript>

    <snip rest>
    That code is so full of bad habits that it is not possible to determine the
    actual fault producing the error you reported. Quite possibly, other
    problems become visible once this is solved.
    1. Scripts don't have id's.
    2. Scripts don't have languages.
    3. Scripts have types. Usually like this:
    <script type="text/javascript">

    In the code as posted, the script is located before the <HTML> opening tag.
    Then comes a <title> element, which really should be inside a <head>, and
    then this crazy body tag:
    > <BODY leftmargin="70" bgColor=lightyellow
    > LANGUAGE=javascript onload="return window_onload()">


    The leftmargin attribute is supported by less and less browsers, as is the
    bgcolor. They are being replaced by stylesheets. The onload event handler
    may run some javascript, but what would you like any return value to do?
    Btw, function window_onload() does not return anything.
    The language attribute is certainly confusing. The <body> element should NOT
    contain a language attribute, and if it ever did, it should not be a script.
    I am quite hopeful that lights will go green if you remove it.

    For reference:
    On html, head, title and body tags:
    <URL: http://www.w3.org/TR/REC-html40/struct/global.html >
    On scripts:
    <URL: http://www.w3.org/TR/REC-html40/interact/scripts.html >


    Also, unrelated to your current question, links like
    > <A HREF="javascript:ContactUs()" title="Click to send us an
    > email with questions or comments.">Contact Us</A></font>

    may look very inviting, but will lead nowhere for users without javascript
    (by restriction or choice). See the FAQ of this newsgroup:
    <URL: http://jibbering.com/faq/#FAQ4_24 >

    HTH
    Ivo
     
    Ivo, Apr 13, 2004
    #4
  5. alanstew

    alanstew Guest

    Re: Body tag preventing 'window.open' from executing (with code added)

    "Ivo" <> wrote in message news:<407b5012$0$64639$>...
    > > > alanstew wrote:

    > > OK, here is a summary of the page, once again, taking OUT the body
    > > tag, 'window.open' returns to life...putting it back, 'window.open'
    > > won't.
    > > Thanks...
    > >
    > >
    > > <SCRIPT ID=clientEventHandlersJS LANGUAGE=javascript>

    > <snip rest>
    > That code is so full of bad habits that it is not possible to determine the
    > actual fault producing the error you reported. Quite possibly, other
    > problems become visible once this is solved.
    > 1. Scripts don't have id's.
    > 2. Scripts don't have languages.
    > 3. Scripts have types. Usually like this:
    > <script type="text/javascript">


    OK, Ivo, I confess, I've been using Microsoft DevelopmentEnvironment
    and it puts those tags in, and I just, well, used them.

    > In the code as posted, the script is located before the <HTML> opening tag.
    > Then comes a <title> element, which really should be inside a <head>, and
    > then this crazy body tag:
    > > <BODY leftmargin="70" bgColor=lightyellow
    > > LANGUAGE=javascript onload="return window_onload()">


    That's what MDE does when you click to add a client object event. I
    never questioned it before, after all, Microsoft, right? They MUST
    know what they're doing.....and gosh durn it...it works. BUT, you're
    right, when I take those out, it still works....and the "<script
    type="text/javascript">" works also!

    > The leftmargin attribute is supported by less and less browsers, as is the
    > bgcolor. They are being replaced by stylesheets. The onload event handler
    > may run some javascript, but what would you like any return value to do?
    > Btw, function window_onload() does not return anything.


    I'm not really trying to return anything, just put the cursor in the
    right text box when the page loads...and since you've been right about
    everything else, does the onload HAVE to return something?

    > The language attribute is certainly confusing. The <body> element should NOT
    > contain a language attribute, and if it ever did, it should not be a script.
    > I am quite hopeful that lights will go green if you remove it.
    >


    > For reference:
    > On html, head, title and body tags:
    > <URL: http://www.w3.org/TR/REC-html40/struct/global.html >
    > On scripts:
    > <URL: http://www.w3.org/TR/REC-html40/interact/scripts.html >
    >

    Thanks for the informational urls, I've bookmarked them already.
    >
    > Also, unrelated to your current question, links like
    > > <A HREF="javascript:ContactUs()" title="Click to send us an
    > > email with questions or comments.">Contact Us</A></font>

    > may look very inviting, but will lead nowhere for users without javascript
    > (by restriction or choice). See the FAQ of this newsgroup:
    > <URL: http://jibbering.com/faq/#FAQ4_24 >
    >

    Sheesh, right again Ivo, I've reconstructed for the reasons you
    mention, but INSIDE the members area, we're requiring javascript be
    enabled, so I'll keep using that on the inside where I try to maintain
    my illusion of control.
    In summary, thanks very much....can you tell I'm a slash and burn
    type? That's why I need this newsgroup, cause I'm an undisciplined
    flailer, but I appreciate people like you who actually take the time
    to help us 'monkey see, monkey do' types.
    Finally, the REAL problem turned out to be that some dork enabled
    popup blocking on my machine. There was an interesting thread about
    it on this group just the other day....
    Alan

    > HTH
    > Ivo
     
    alanstew, Apr 13, 2004
    #5
  6. Re: Body tag preventing 'window.open' from executing (with code added)

    On 12 Apr 2004 22:55:20 -0700, alanstew <> wrote:

    > "Ivo" <> wrote in message
    > news:<407b5012$0$64639$>...


    [snip]

    >> In the code as posted, the script is located before the <HTML> opening
    >> tag.
    >> Then comes a <title> element, which really should be inside a <head>,
    >> and then this crazy body tag:
    >>
    >>>> alanstew wrote:
    >>>
    >>> <BODY leftmargin="70" bgColor=lightyellow
    >>> LANGUAGE=javascript onload="return window_onload()">

    >
    > That's what MDE does when you click to add a client object event. I
    > never questioned it before, after all, Microsoft, right? They MUST
    > know what they're doing.....and gosh durn it...it works.


    You'd hope that Microsoft knew what they were doing.

    Most of the things that Ivo singles out in your HTML are proprietary
    attributes that only IE understands and everything else ignores. It's
    actually invalid HTML as passing it though the World Wide Web Consortium's
    (W3C) validator will show you:

    <URL:http://validator.w3c.org/>

    > BUT, you're right, when I take those out, it still works....and the
    > "<script type="text/javascript">" works also!


    Though both may work, Ivo's suggestions are infinitely better.

    > [...] and since you've been right about everything else, does the onload
    > HAVE to return something?


    No. When intrinsic events return a value, that value is evaluated as a
    boolean. Some events can be cancelled, such as clicks, and the boolean
    decides whether cancellation should occur (false meaning to cancel). As
    you can't, and shouldn't be able to, cancel the load event, returning a
    value does nothing.

    [snip]

    Hope that helps,
    Mike

    --
    Michael Winter
    d (replace ".invalid" with ".uk" to reply)
     
    Michael Winter, Apr 14, 2004
    #6
  7. alanstew

    alanstew Guest

    Re: Body tag preventing 'window.open' from executing (with code added)

    Michael Winter <> wrote in message news:<>...
    > On 12 Apr 2004 22:55:20 -0700, alanstew <> wrote:
    >
    > > "Ivo" <> wrote in message
    > > news:<407b5012$0$64639$>...

    >
    > [snip]
    >
    > >> In the code as posted, the script is located before the <HTML> opening
    > >> tag.
    > >> Then comes a <title> element, which really should be inside a <head>,
    > >> and then this crazy body tag:
    > >>
    > >>>> alanstew wrote:
    > >>>
    > >>> <BODY leftmargin="70" bgColor=lightyellow
    > >>> LANGUAGE=javascript onload="return window_onload()">

    > >
    > > That's what MDE does when you click to add a client object event. I
    > > never questioned it before, after all, Microsoft, right? They MUST
    > > know what they're doing.....and gosh durn it...it works.

    >
    > You'd hope that Microsoft knew what they were doing.
    >
    > Most of the things that Ivo singles out in your HTML are proprietary
    > attributes that only IE understands and everything else ignores. It's
    > actually invalid HTML as passing it though the World Wide Web Consortium's
    > (W3C) validator will show you:
    >
    > <URL:http://validator.w3c.org/>
    >
    > > BUT, you're right, when I take those out, it still works....and the
    > > "<script type="text/javascript">" works also!

    >
    > Though both may work, Ivo's suggestions are infinitely better.
    >
    > > [...] and since you've been right about everything else, does the onload
    > > HAVE to return something?

    >
    > No. When intrinsic events return a value, that value is evaluated as a
    > boolean. Some events can be cancelled, such as clicks, and the boolean
    > decides whether cancellation should occur (false meaning to cancel). As
    > you can't, and shouldn't be able to, cancel the load event, returning a
    > value does nothing.
    >
    > [snip]
    >
    > Hope that helps,
    > Mike


    Mike,
    Thanks for the link, I'll check that out, when I have time. But I
    really am curious why Ivo's suggestions are "infinitely better". If
    two ways work, WHY does it MATTER which is used? Is this aesthetics,
    or is there a practical reason why I should stop doing things the way
    I've been doing them and spend the time to learn a different way? Not
    trying to start a war, but really, in my life, I need results not
    manners, if you get the way I'm driftin'
    Alan
     
    alanstew, Apr 14, 2004
    #7
  8. Re: Body tag preventing 'window.open' from executing (with code added)

    alanstew wrote:
    <snip>
    > Thanks for the link, I'll check that out, when I have time. But I
    > really am curious why Ivo's suggestions are "infinitely better".


    Ivo was presented with code that is structurally nonsense, filled with
    bogus attributes and deprecated mark-up (and perverse formulations of
    that deprecated mark-up); more a sequence of HTML-like mystical
    incantations than a hypertext document, and he proposed formally valid
    HTML 4 as an alternative.

    He also pointed out (as we all do on a regular basis) that javascript:
    HREFs cause problems and are completely unnecessary anyway (given that
    the oldest browsers in use are version 4 era browsers that support
    cancellable onclick attributes on links).

    The argument for formally valid HTML is quite simple: A browser
    presented with valid HTML can follow a clearly specified series of rules
    when creating a corresponding scriptable DOM from that mark-up, so they
    produce consistent results. Presented with nonsense HTML the browsers
    will make an attempt to error-correct that HTML and build a DOM with the
    results. But there are no public standards or specifications for error
    correcting, so each browser does it to the best of its abilities, but
    inevitably differently. The resulting DOMs are not necessarily
    consistent (indeed presented with particular formulations of common
    invalid HTML they have been demonstrated to diverge considerably in
    structure), and doing anything to provoke browsers into being any more
    inconsistent than they already are is asking for trouble.

    The javascript HREFs are another known troublemaker. Apart form their
    obvious non-functionality when scripting is not supported on the client,
    from the point of view of a web browser they represent navigation. And
    navigation implies that the current page is finished with and about to
    be replaced. Browsers (including IE) take the fact that the current page
    is about to be replace as an opportunity to stop maintaining activity on
    the current page that is considered costly. Again there are no formal
    rules so different browsers behave differently, but following the
    activation of a javascript HREF the consequences of the browser getting
    the impression that it has been navigated mean that all bets ore off as
    to what scriptable activity the browser will still be supporting.

    Javascript HREFs were introduced as a kludge that allowed browsers that
    had no link onclick event handlers to do things when a link was clicked
    that they could not otherwise do. Unfortunately scripting books,
    Internet tutorials and the like hang around suggesting particular
    practices long after those practices have become outdated and
    superfluous. They are now unnecessary, and they have harmful side
    effects. Two factors that, in combination, suggest that they should
    never be used.

    > If two ways work, WHY does it MATTER which is used?


    Define "work". If one practice is known to provoke problems, while an
    alternative avoids them, but an application of the first does not
    manifest problems (under the conditions in which it is tested) that does
    not render the two equivalent, it just means you got lucky (or are not
    testing adequately).

    > Is this aesthetics, or is there a practical reason why I should
    > stop doing things the way I've been doing them and spend the
    > time to learn a different way?


    From one point of view the history of the development of programming
    practices can be looked upon as the development of techniques for the
    management of complexity. Humans are limited in their ability to
    perceive complex systems and once complexity gets out of hand chaos
    ensues.

    Many of the tools used to manage complexity consist of nothing more than
    formal disciplines applied to the process of code design and authoring.
    They aren't hard and fast rules, or absolute truths, they are tools that
    contribute to making it easier to do a difficult task well. And
    conscientious programmers don't need much experience to appreciate the
    contribution of the application of appropriate formal disciplines to
    their work. So they will tent to seek out the disciplines that should be
    applied to particular tasks.

    In the authoring of HTML one of the obvious disciplines that can be
    applied is the creation of documents that conform to the specifications
    for HTML. And the results can be directly tested by exposing the
    documents to an HTML validator.

    As a stage in the development of HTML, validation does not tell you that
    the results are good HTML, optimum, ideal or anything beyond that it is
    valid, but that does rule out, at a stroke, any and all problems
    resulting from invalid HTML. Meaning that if any problems remain you
    know to look elsewhere for their cause (and ruling out causes is
    normally a huge aid in the solving of problems, because that means that
    the problems are less complex than they would be otherwise).

    > Not trying to start a war, but really,
    > in my life, I need results not manners,
    > if you get the way I'm driftin'


    Did you get results? Results don't usually prompt questions on
    newsgroups. But the application of appropriate formal disciplines to the
    process of creation is not about "manners" as such, it is about getting
    better quality results, quicker. These concepts don't arise from some
    sadistic desire to burden the world with pointless extra tasks, they are
    tools, they make life easier, and they are promoted for the benefit of
    the people involved.

    Richard.
     
    Richard Cornford, Apr 14, 2004
    #8
  9. alanstew

    alanstew Guest

    Re: Body tag preventing 'window.open' from executing (with code added)

    "Richard Cornford" <> wrote in message news:<c5jssd$km6$1$>...
    > alanstew wrote:
    > <snip>
    > > Thanks for the link, I'll check that out, when I have time. But I
    > > really am curious why Ivo's suggestions are "infinitely better".

    >
    > Ivo was presented with code that is structurally nonsense, filled with
    > bogus attributes and deprecated mark-up (and perverse formulations of
    > that deprecated mark-up); more a sequence of HTML-like mystical
    > incantations than a hypertext document, and he proposed formally valid
    > HTML 4 as an alternative.
    >
    > He also pointed out (as we all do on a regular basis) that javascript:
    > HREFs cause problems and are completely unnecessary anyway (given that
    > the oldest browsers in use are version 4 era browsers that support
    > cancellable onclick attributes on links).
    >
    > The argument for formally valid HTML is quite simple: A browser
    > presented with valid HTML can follow a clearly specified series of rules
    > when creating a corresponding scriptable DOM from that mark-up, so they
    > produce consistent results. Presented with nonsense HTML the browsers
    > will make an attempt to error-correct that HTML and build a DOM with the
    > results. But there are no public standards or specifications for error
    > correcting, so each browser does it to the best of its abilities, but
    > inevitably differently. The resulting DOMs are not necessarily
    > consistent (indeed presented with particular formulations of common
    > invalid HTML they have been demonstrated to diverge considerably in
    > structure), and doing anything to provoke browsers into being any more
    > inconsistent than they already are is asking for trouble.
    >
    > The javascript HREFs are another known troublemaker. Apart form their
    > obvious non-functionality when scripting is not supported on the client,
    > from the point of view of a web browser they represent navigation. And
    > navigation implies that the current page is finished with and about to
    > be replaced. Browsers (including IE) take the fact that the current page
    > is about to be replace as an opportunity to stop maintaining activity on
    > the current page that is considered costly. Again there are no formal
    > rules so different browsers behave differently, but following the
    > activation of a javascript HREF the consequences of the browser getting
    > the impression that it has been navigated mean that all bets ore off as
    > to what scriptable activity the browser will still be supporting.
    >
    > Javascript HREFs were introduced as a kludge that allowed browsers that
    > had no link onclick event handlers to do things when a link was clicked
    > that they could not otherwise do. Unfortunately scripting books,
    > Internet tutorials and the like hang around suggesting particular
    > practices long after those practices have become outdated and
    > superfluous. They are now unnecessary, and they have harmful side
    > effects. Two factors that, in combination, suggest that they should
    > never be used.
    >
    > > If two ways work, WHY does it MATTER which is used?

    >
    > Define "work". If one practice is known to provoke problems, while an
    > alternative avoids them, but an application of the first does not
    > manifest problems (under the conditions in which it is tested) that does
    > not render the two equivalent, it just means you got lucky (or are not
    > testing adequately).
    >
    > > Is this aesthetics, or is there a practical reason why I should
    > > stop doing things the way I've been doing them and spend the
    > > time to learn a different way?

    >
    > From one point of view the history of the development of programming
    > practices can be looked upon as the development of techniques for the
    > management of complexity. Humans are limited in their ability to
    > perceive complex systems and once complexity gets out of hand chaos
    > ensues.
    >
    > Many of the tools used to manage complexity consist of nothing more than
    > formal disciplines applied to the process of code design and authoring.
    > They aren't hard and fast rules, or absolute truths, they are tools that
    > contribute to making it easier to do a difficult task well. And
    > conscientious programmers don't need much experience to appreciate the
    > contribution of the application of appropriate formal disciplines to
    > their work. So they will tent to seek out the disciplines that should be
    > applied to particular tasks.
    >
    > In the authoring of HTML one of the obvious disciplines that can be
    > applied is the creation of documents that conform to the specifications
    > for HTML. And the results can be directly tested by exposing the
    > documents to an HTML validator.
    >
    > As a stage in the development of HTML, validation does not tell you that
    > the results are good HTML, optimum, ideal or anything beyond that it is
    > valid, but that does rule out, at a stroke, any and all problems
    > resulting from invalid HTML. Meaning that if any problems remain you
    > know to look elsewhere for their cause (and ruling out causes is
    > normally a huge aid in the solving of problems, because that means that
    > the problems are less complex than they would be otherwise).
    >
    > > Not trying to start a war, but really,
    > > in my life, I need results not manners,
    > > if you get the way I'm driftin'

    >
    > Did you get results? Results don't usually prompt questions on
    > newsgroups. But the application of appropriate formal disciplines to the
    > process of creation is not about "manners" as such, it is about getting
    > better quality results, quicker. These concepts don't arise from some
    > sadistic desire to burden the world with pointless extra tasks, they are
    > tools, they make life easier, and they are promoted for the benefit of
    > the people involved.
    >
    > Richard.


    Thanks Richard...very cogent....believe me, I take it all with more
    than a grain of salt...all of you guys are obviously intelligent and
    knowledgeable, but I'm driven back to two points: One) It turned out
    that the original problem was caused by a popup blocker preventing my
    window.open from executing, not by my sloppy code. Two) What should I
    do, throw away the Microsoft Developemnt Environment, and rewrite
    everything that it has inserted in my pages that is non-standard?
    What do you guys use to develop asps?

    That's it, even if anybody responds I'm not replying anymore...I've
    got too much work to do!!!
    Alan
     
    alanstew, Apr 14, 2004
    #9
    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. shruds
    Replies:
    1
    Views:
    834
    John C. Bollinger
    Jan 27, 2006
  2. Jon Turner

    Preventing DataGrid from executing

    Jon Turner, Dec 2, 2003, in forum: ASP .Net Web Controls
    Replies:
    0
    Views:
    106
    Jon Turner
    Dec 2, 2003
  3. Starry Gordon
    Replies:
    1
    Views:
    112
  4. Robert Karlsson
    Replies:
    1
    Views:
    129
  5. PC HUA
    Replies:
    2
    Views:
    421
    PC HUA
    May 19, 2004
Loading...

Share This Page