Question

I have a custom control (ascx) which implements the IPostBackEventHandler interface for intercepting custom events triggered by custom rendered HTML links.

In this control I use an update panel and inside the update panel I use a literal control in which I render custom HTML links.

When I render the HTML links inside the literal control I use a StringBuilder with the following code:

sb.AppendFormat ("<a href=\"{0}\" id=\"custom_iterator_id\">Text</a>",
    this.Page.ClientScript.GetPostBackClientHyperlink(this, custom_string_param));

Hyperlinks are rendered fine, and when clicking on them an asynchronous postback is triggered and a partial update is fired (since all links are rendered inside the Update panel).

The problem is that I need to do some custom Javascript before firing the __doPostBack which is rendered with the above code. So here is a simplified version of the changed code:

sb.AppendFormat ("<a href=\"javascript:JSFunc{0}\" id=\"custom_iterator_id\">Text</a>",
    custom_string_param);

Also in the ascx markup I use the following code (inside or outside the Update panel):

<script language="javascript" type="text/javascript">
function JSFunc(param) {
// custom js code here .... 
__doPostBack('<%=this.ClientID%>', param);
}
</script>

The problem here is that when a link is clicked it performs a full postback and not a partial one. I also tested more simple versions of the above code and it seems that if you remove the __doPostBack from the href or the onclick events from the link ( tag) and move it to a custom js function which in turns you supply to the link, a full postback is triggered.

Note that there is no error on the page and in both cases the code work correctly. The page is rendering correctly depending on the parameters returned from the __doPostBack, but in the second case a full instead of partial postback is firing.

Any ideas?

Thanks in advance,

George

Était-ce utile?

La solution

I think you can't call __doPostBack with the ClientID. It actually uses UniqueIDWithDollars, but generally with ASP.NET Web Forms I say: you don't want to know.

Since calling this method is all about abstracting away the details of how post back works, you would be better off asking the framework for the code. Luckily, there's a special method just for that, which will take care of the details. In your code it would look like something like this:

<script language="javascript" type="text/javascript">
    function JSFunc(param) {
        // custom js code here .... 
        <%= Page.ClientScript.GetPostBackEventReference(this, custom_string_param) %>
    }
</script>

This let's the client script manager create the piece of JavaScript code, using a reference to your user control (this) and any custom event argument (custom_string_param).

There's one caveat though. When calling it this way, it will add javascript: to the beginning of the string.

To override this behaviour, you need to use an overload of GetPostBackEventReference that accepts an instance of PostBackOptions as its first argument, the instance having its RequiresJavaScriptProtocol property set to false.

PostBackOptions options = new PostBackOptions(this, custom_string_param)
options.RequiresJavaScriptProtocol = false;
Page.ClientScript.GetPostBackEventReference(options)
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top