Build 220/VS2005 ... still some ascx parsing issues

I have some admittedly weird code that Resharper isn't parsing correctly,
but which compiles correctly. It looks something like this:

At the top of the ascx page, there's a client side script block, but note
that it has an asp:Literal definition embedded in it:

var dirty = true; function finish() { if (dirty && window.opener) { var buttonId = ''; var button = window.opener.document.getElementById(buttonId); if (button == null && window.opener.dialogWin.args != null) { button = window.opener.document.getElementById(window.opener.dialogWin.args); } if (button != null) button.click(); window.close(); } } In the code-behind *.ascx.cs file, the identifier "ButtonId" is comming up as undefined and colored in red. The compiler compiles it fine, however, so it's NOT undefined. I think the Resharper parser is balking at the idea of the ]]> definition being inside the script block, and
further, inside quotes of a variable assignment. This doesn't matter to the
ASP.NET parser, and it shouldn't matter to Resharper either. That line
still defines an asp page element, and thus should still be parsed and
recognized and properly colored.

Just FYI.


8 comments
Comment actions Permalink

Does this code work?
It looks like you are mixing client side and server tags. strange...
And I wouldn't relay on R# to parse JavaScript since it is not supported.
"Paul Bradshaw" <pbradshaw@advsol.com> wrote in message
news:duhvj6$7g9$1@is.intellij.net...
>I have some admittedly weird code that Resharper isn't parsing correctly,
>but which compiles correctly. It looks something like this:
>

At the top of the ascx page, there's a client side script block, but note
that it has an asp:Literal definition embedded in it:

>

<script language=javascript>
var dirty = true;

>

function finish()
{
if (dirty && window.opener)
{
var buttonId = '<asp:Literal id="ButtonId"
runat="server"></asp:Literal>';
var button = window.opener.document.getElementById(buttonId);

>

if (button == null && window.opener.dialogWin.args != null)
{
button =
window.opener.document.getElementById(window.opener.dialogWin.args);
}

>

if (button != null)
button.click();
window.close();
}
}

>

In the code-behind *.ascx.cs file, the identifier "ButtonId" is comming up
as undefined and colored in red. The compiler compiles it fine, however,
so it's NOT undefined. I think the Resharper parser is balking at the
idea of the <asp:Literal ..../> definition being inside the script block,
and further, inside quotes of a variable assignment. This doesn't matter
to the ASP.NET parser, and it shouldn't matter to Resharper either. That
line still defines an asp page element, and thus should still be parsed
and recognized and properly colored.

>

Just FYI.



0
Comment actions Permalink

Yes, it works. The ASP.NET parser replaces the tagged text between the
angle brackets before it is sent down to the client.

It's basically sending the id of a button created on the server side down to
the client for handling in a javascript function.

(I didn't write this code, and barely understand it, but the point is, it
compiles and works and Resharper doesn't understand it)


"Shimon Sim" <shimonsim048@community.nospam> wrote in message
news:dui3dd$psh$1@is.intellij.net...

Does this code work?
It looks like you are mixing client side and server tags. strange...
And I wouldn't relay on R# to parse JavaScript since it is not supported.
"Paul Bradshaw" <pbradshaw@advsol.com> wrote in message
news:duhvj6$7g9$1@is.intellij.net...

>>I have some admittedly weird code that Resharper isn't parsing correctly,
>>but which compiles correctly. It looks something like this:
>>
>> At the top of the ascx page, there's a client side script block, but note
>> that it has an asp:Literal definition embedded in it:
>>
>> >> var dirty = true; >> >> function finish() >> { >> if (dirty && window.opener) >> { >> var buttonId = '> runat="server">'; >> var button = window.opener.document.getElementById(buttonId); >> >> if (button == null && window.opener.dialogWin.args != null) >> { >> button = >> window.opener.document.getElementById(window.opener.dialogWin.args); >> } >> >> if (button != null) >> button.click(); >> window.close(); >> } >> } >> >> In the code-behind *.ascx.cs file, the identifier "ButtonId" is comming >> up as undefined and colored in red. The compiler compiles it fine, >> however, so it's NOT undefined. I think the Resharper parser is balking >> at the idea of the definition being inside the script >> block, and further, inside quotes of a variable assignment. This doesn't >> matter to the ASP.NET parser, and it shouldn't matter to Resharper >> either. That line still defines an asp page element, and thus should >> still be parsed and recognized and properly colored. >> >> Just FYI. >> >]]>



0
Comment actions Permalink

I think I got the idea of the code.
Never mind.

"Paul Bradshaw" <pbradshaw@advsol.com> wrote in message
news:dui42j$sqp$1@is.intellij.net...

Yes, it works. The ASP.NET parser replaces the tagged text between the
angle brackets before it is sent down to the client.

>

It's basically sending the id of a button created on the server side down
to the client for handling in a javascript function.

>

(I didn't write this code, and barely understand it, but the point is, it
compiles and works and Resharper doesn't understand it)

>
>

"Shimon Sim" <shimonsim048@community.nospam> wrote in message
news:dui3dd$psh$1@is.intellij.net...

>> Does this code work?
>> It looks like you are mixing client side and server tags. strange...
>> And I wouldn't relay on R# to parse JavaScript since it is not supported.
>> "Paul Bradshaw" wrote in message >> news:duhvj6$7g9$1@is.intellij.net... >>>I have some admittedly weird code that Resharper isn't parsing correctly, >>>but which compiles correctly. It looks something like this: >>> >>> At the top of the ascx page, there's a client side script block, but >>> note that it has an asp:Literal definition embedded in it: >>> >>> >>> var dirty = true; >>> >>> function finish() >>> { >>> if (dirty && window.opener) >>> { >>> var buttonId = '<asp:Literal id="ButtonId" >>> runat="server"></asp:Literal>'; >>> var button = window.opener.document.getElementById(buttonId); >>> >>> if (button == null && window.opener.dialogWin.args != null) >>> { >>> button = >>> window.opener.document.getElementById(window.opener.dialogWin.args); >>> } >>> >>> if (button != null) >>> button.click(); >>> window.close(); >>> } >>> } >>> >>> In the code-behind *.ascx.cs file, the identifier "ButtonId" is comming >>> up as undefined and colored in red. The compiler compiles it fine, >>> however, so it's NOT undefined. I think the Resharper parser is balking >>> at the idea of the <asp:Literal ....></asp:Literal> definition being inside the >>> script block, and further, inside quotes of a variable assignment. This >>> doesn't matter to the ASP.NET parser, and it shouldn't matter to >>> Resharper either. That line still defines an asp page element, and thus >>> should still be parsed and recognized and properly colored. >>> >>> Just FYI. >>> >> >> >]]></span></p><blockquote level="1"></blockquote><p><br/><br/></p>

0
Comment actions Permalink

Paul,

Submit this to the tracker, please. I do not think we could support it by
release, but we'll have to but 2.ax.

PS I'm just curious, what is the idea of writing such a hard-to-understand
code?
--
Sergey V. Coox
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink


"Sergey V. Coox (JetBrains)" <qx@intellij.com> wrote in message
news:dujofp$3nk$1@is.intellij.net...

Paul,

>

Submit this to the tracker, please. I do not think we could support it by
release, but we'll have to but 2.ax.

>

PS I'm just curious, what is the idea of writing such a hard-to-understand
code?
--
Sergey V. Coox
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

>

lets the ASCX render a control with a server-side-determined ID to allow the
ASCX to be used in multiple instances on the page - like, say, in a
repeater.
(As an aside, I would probably recommend changing this so the control used
ClientScript to register the script block with the Control.ClientId or
Control.UniqueId embedded in it from control you want the jscript to
manipulate....)

Jon


0
Comment actions Permalink

Will do, but I wouldn't think it'd be that difficult to slip in, since
finding these declarations is basically just a regex search...

As for why this code is written this way, I have no idea, as I didn't write
it and I'm not a big ASP.NET guy, but Johnathan's explaination sounds good
to me :) I'm just trying to ensure that our code works with Resharper, so
I can get people to actually convert to it. Marking things as errors that
compile fine is going to be a road-bump to getting some people to switch
(slow startup is already a roadbump for those that startup/shutdown several
times during the day). The fewer barriers to entry, the better.


"Sergey V. Coox (JetBrains)" <qx@intellij.com> wrote in message
news:dujofp$3nk$1@is.intellij.net...

Paul,

>

Submit this to the tracker, please. I do not think we could support it by
release, but we'll have to but 2.ax.

>

PS I'm just curious, what is the idea of writing such a hard-to-understand
code?
--
Sergey V. Coox
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"



0
Comment actions Permalink

Paul,
Unfortunately, It's not that easy as writing a rage, I'll think it over, how
to overcome the problem. Jonathan's explanation sounds reasonable, but the
same could be written in more readable way....
Anyway, I'll do my best.

--
Sergey V. Coox
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

That's all I can ask :)


"Sergey V. Coox (JetBrains)" <qx@intellij.com> wrote in message
news:dumfo2$k4h$1@is.intellij.net...

Paul,
Unfortunately, It's not that easy as writing a rage, I'll think it over,
how to overcome the problem. Jonathan's explanation sounds reasonable, but
the same could be written in more readable way....
Anyway, I'll do my best.

>

--
Sergey V. Coox
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"



0

Please sign in to leave a comment.