views:

417

answers:

2

Seems to me it is a bit wierd that you can do..

Page.ClientScript.RegisterStartupScript(this.GetType(), "KeyName", "alert('changed my mind')", true);

And then later on you can't unregister or stop the javascript from being rendered programatically.

Why would Microsoft do this?

I don't like the work around here.. http://hemant-vikram.blogspot.com/2005/11/unregister-startup-script-workaround.html

And I don't like the option of just re-registering it and having it do nothing..

Thoughts?

+2  A: 

I assume that you'd want to "unregister" the script (which has already been registered) under some condition, like so:

Page.ClientScript.RegisterStartupScript(this.GetType(), "KeyName", "alert('changed my mind')", true);
...
if(condition)
    Page.ClientScript.UnregisterStartupScript(this.GetType(), "KeyName", "alert('changed my mind')", true);

Why can't this simply be changed to:

if(!condition)
    Page.ClientScript.RegisterStartupScript(this.GetType(), "KeyName", "alert('changed my mind')", true);
JoshJordan
You're right instead of fixing the code smell with refactoring I was looking for a faster solution.. naughty!
Lee Englestone
Done now works a treat.
Lee Englestone
If only it were as deliberate as protecting you from calling Unregister too late. It's actually safe right up to the Render stage, but RegisterStartupScript is quite happy to be called after Render when it's too late to actually include the script in the response.
stevemegson
Well, that is a shame. I'm going to edit that bit out.
JoshJordan
+2  A: 

It's actually worse than you think - "just re-registering it and having it do nothing" isn't an option either. The register method checks if a script is already registered with that key, and does nothing if it is. Once you call RegisterStartupScript, nothing you can do will stop that script being rendered.

As to why Microsoft did that, I'd guess that the possibility of changing or removing registered scripts was simply forgotten when RegisterStartupScript was first designed. The design choices happened to make it non-trivial to go back and create an unregister method, so they'd now need a good reason to do that.

When you register a script, it's stored in two places within the ClientScriptManager. A ListDictionary allows checks for whether a script is already registered, and an ArrayList stores the actual scripts as they will be rendered. I assume that the ArrayList is used to ensure that scripts are rendered in the order in which they were registered, but it also means that you can't tell which string in the ArrayList belongs to which key.

It wouldn't be terribly hard to equip your own page class with methods for MaybeAddStartupScript(key,script) and ChangedMyMindAboutThatStartupScript(key). Store the keys and scripts in your own dictionary and then in PreRender, register whichever scripts made it this far. It's certainly annoying to have to do it yourself, though.

stevemegson
The key point I took from this answer was registering scripts in Pre_Render rather than registering in Page_Load and then attempting to re-register based on an event on the page.
Brian Hinchey