ClientScriptManager.RegisterOnSubmitStatement(Type, String, String) Method
Registers an OnSubmit statement with the Page object using a type, a key, and a script literal. The statement executes when the HtmlForm is submitted.
RegisterStartupScript
Registers a startup script block with the ScriptManager control and adds the script block to the page.
Registers the startup script with the Page object.
这里的注册脚本,是会运行的。所以可以用来绑定事件。
private void RegisterSaveButtonSubmit() { string script = @" $('.blueimp-file-upload-submit').on('click',function() { alert('blueimp-file-upload-submit'); });"; var key = "RegisterSaveButtonSubmit"; var type = GetType(); var scriptManager = Page.ClientScript; if (!scriptManager.IsStartupScriptRegistered(key)) { scriptManager.RegisterStartupScript(type, key, script, true); } }
ScriptManager.RegisterPostBackControl
Registers a control as a trigger for a postback.
This method is used to configure postback controls inside an UpdatePanel control that would otherwise perform asynchronous postbacks.
RegisterClientScriptBlock
Registers the client script with the Page object.
Registers a client script block with the ScriptManager control for use with a control that is inside an UpdatePanel control, and then adds the script block to the page.
需要注意的是,这里注册的脚本是不会运行的。不能是jQuery的绑定事件,不会触发
the most important part is Control which control in html tags you want to register the script for example if you have user control and you want to run the script just for that use this line
ScriptManager.RegisterStartupScript(this, this.GetType(), "alertscript", "document.getElementById('userControl_h1TAG')", true);
but when you want to register the block and script to all part of that page use this line in CS code of user-control :
ScriptManager.RegisterStartupScript(this.Page, this.Page.GetType(), "alertscript", "document.getElementById('page_h1TAG')", true);
There a post on why this could lead to trouble, but I've never actually encountered this. It comes down to this: when you inherit from a control that has this piece of code, the GetType
will return something else. This way, the key will differ and the script will be added a second time if you have both controls on your page. This could potentially lead to javascript problems.
The solution would be to not use GetType
but typeof()
instead. In VB.Net:
Page.ClientScript.RegisterClientScriptBlock(GetType(MyClass), "key","scriptblock", True)
But again, this is an exceptional case.
When using RegisterClientScript do not use this.GetType() …
Quoted from: http://blogs.ipona.com/james/archive/2006/10/03/6710.aspx
Page.ClientScript.RegisterClientScriptBlock(this.GetType(), “Script”, scriptText);This is not good. Why not? Well, this.GetType() is a way of getting the runtime type of an object. That’s not necessarily the same type as the one in which this bit of code is being declared.So what? Does that actually make any difference? Well, yes, if anyone ever writes a control that inherits from your control.If I create a control called Widget that calls RegisterClientScriptBlock() passing this.GetType(), then whenever I put a few Widget controls on the page, the script block will be registered once, and only once. That’s great.Then later on, I develop a SpecialisedWidget control that inherits from Widget. I drop it onto the page, and suddenly, RegisterClientScriptBlock is getting called with the same script, but two different types – Widget, and SpecialisedWidget. The script block ends up appearing on the page twice. Cue tricky hard to track JavaScript bugs that take ages to find…Now, if Widget had originally registered that script block passing typeof (Widget) as the type argument instead of this.GetType(), the whole problem wouldn’t arise, because even when the SpecialisedWidgets are registering script on the page, the script is registered with the type qualifier of Widget. And as a side bonus, the IL will be more efficient, because typeof (Widget) is a kind of type literal, which the compiler can embed right into the code, rather than a runtime dispatched method call to a reflection API.