 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / General / December 2007</script> in String Constant
I have an ASPX page with my C# code in a <script> block within the page itself (not a code-behind file). Within that code, the syntax highlighter indicates the following string constant ends just before the "</script>", and the line produces the error "Newline in constant." Changing that portion of the string to "<//script>" causes the syntax highlighter to indicate a normal string. string jScript = "<script>document.forms[0].submit();</script>"; Okay, so I would expect </script> to end my ASP.NET script block, but not when it appears within a string constant. Is this a bug, or am I prohibitted from having string constants that contain "</script>"? Thanks.  SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com Without any particular knowledge, I am just guessing. I guess it does make sense. How does the guy sitting behind your screen and compiling your scripts know where the script ends? He knows it by the </script> tag. How can he know that the tag is within some language-dependant element like a string? Probably he can't. Perhaps, he first defines where the script begins and ends and then passes the whole script for compiling. If it is true, he can't ignore the </script> tag inside a string simply because he doesn't know anything about c# strings at this stage. SignatureEliyahu Goldin, Software Developer Microsoft MVP [ASP.NET] http://msmvps.com/blogs/egoldin http://usableasp.net >I have an ASPX page with my C# code in a <script> block within the page >itself (not a code-behind file). [quoted text clipped - 13 lines] > > Thanks. Eliyahu, > Without any particular knowledge, I am just guessing. > [quoted text clipped - 6 lines] > inside a string simply because he doesn't know anything about c# strings > at this stage. Maybe, but it seems a bit limiting if you can put stuff like that even within a constant. SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com >>I have an ASPX page with my C# code in a <script> block within the page >>itself (not a code-behind file). [quoted text clipped - 13 lines] >> >> Thanks. > I guess it does make sense. How does the guy sitting behind your screen > and compiling your scripts know where the script ends? He knows it by the > </script> tag. unless that </script> tag is part of a string of characters enclosed within double quotes; in effect: ok, I'm looking for the end of the script block .. oh, some quotation marks here ... now let me look for the close quotation mark before I resume looking for the close of the script block ... no? what am I missing? > How can he know that the tag is within some language-dependant element > like a string? Probably he can't. Perhaps, he first defines where the > script begins and ends and then passes the whole script for compiling. > If it is true, he can't ignore the </script> tag inside a string simply > because he doesn't know anything about c# strings at this stage. why not? "he" is a C# compiler after all; I'm not understanding why "he" can't look at this: string jScript = "<script>document.forms[0].submit();</script>"; and know that we have a string assignment going on and </script> is not ending anything in this context ... or that <script> is not violating any nesting rules The more I think about this, the more I think "he" is NOT a C# compiler. I suspect what is happending is the ASPX parser first pulls out script code and then passes that script to the C# compiler. So it is the ASPX parser that determines where the end of the script is, not the compiler. Definitely a quirk, but my best assessment is that this is what is happening. SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com >> I guess it does make sense. How does the guy sitting behind your screen >> and compiling your scripts know where the script ends? He knows it by the [quoted text clipped - 21 lines] > ending anything in this context ... or that <script> is not violating any > nesting rules > The more I think about this, the more I think "he" is NOT a C# compiler. > [quoted text clipped - 4 lines] > Definitely a quirk, but my best assessment is that this is what is > happening. whatever ... the code you're writing should be parsable by *something* rather than erroring out is my point; I didn't think it was really the point which code was doing which work here ... or does someone disagree that it should be parsable without error ... the expression is not ambiguous the way I see it >>> I guess it does make sense. How does the guy sitting behind your screen >>> and compiling your scripts know where the script ends? He knows it by [quoted text clipped - 21 lines] >> ending anything in this context ... or that <script> is not violating any >> nesting rules Yes, this is what I wanted to say. SignatureEliyahu Goldin, Software Developer Microsoft MVP [ASP.NET] http://msmvps.com/blogs/egoldin http://usableasp.net > The more I think about this, the more I think "he" is NOT a C# compiler. > [quoted text clipped - 30 lines] >> ending anything in this context ... or that <script> is not violating any >> nesting rules Jonathan Wood pretended : > I have an ASPX page with my C# code in a <script> block within the page > itself (not a code-behind file). [quoted text clipped - 13 lines] > > Thanks. In old ASP the usual workaround was string jScript = "<script>document.forms[0].submit();</sc" + "ript>"; Hans Kesting Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.