Cheap Q: How to execute Javascript on a LinkButton

[Matthias S.]

Hi,

I've got a LinkButton on my webform. The Button, once clicked by the
user, should perform some time consuming operation. When the user
actually clicks the Button, I'd like to execute some JavaScript at the
client asking, if he is really sure that he wants to do that. Only if
the user clicks OK, the form should be passed back to the server.

The LinkButton is part of a simple ascx I've written in order to wrap up
functionality. Can somebody please point me into the right direction?

Thanks in advance!

 

[Fernando Arámburu]

On the Page_Load of the Code Behind put

this.MyLinkButton.Attributes["OnClick"] = "javascript: return
yourJavascriptFunction();";

That javascript function does what you want on the client browser and if you
want to stop the postback event, because the user click "Cancel", just
return false on the function and this will stop it.

I hope this help

Fernando Arámburu

 

[Brock Allen]

In v1.1 you have to do this programitically. In v2.0 you can use the OnClientClick
property.

<form id="form1" runat="server">
<asp:LinkButton runat="server" ID="_foo" Text="DoWork"></asp:LinkButton>
</form>

protected void Page_Load(object sender, EventArgs e)
{
_foo.Attributes.Add("onclick", "return confirm('Yes?')");
}

 

[dgk]

In v1.1 you have to do this programitically. In v2.0 you can use the OnClientClick
property.

<form id="form1" runat="server">
<asp:LinkButton runat="server" ID="_foo" Text="DoWork"></asp:LinkButton>
</form>

protected void Page_Load(object sender, EventArgs e)
{
_foo.Attributes.Add("onclick", "return confirm('Yes?')");
}

So confirm is a function that will be downloaded from the .js file?

 

[Fernando Arámburu]

Me again, but in another question.
What a good advance in ASP.NET 2.0 OnClientClick
That´s good!!

Fernando Arámburu

 

[Matthias S.]

Thanks. That helped!

Matthias

In v1.1 you have to do this programitically. In v2.0 you can use the
OnClientClick property.

<form id="form1" runat="server">
<asp:LinkButton runat="server" ID="_foo"
Text="DoWork"></asp:LinkButton>
</form>

protected void Page_Load(object sender, EventArgs e)
{
_foo.Attributes.Add("onclick", "return confirm('Yes?')");
}

 

[Brock Allen]

confirm is an intrinsic javascript function -- you should be able to run
this sample "as-is".

 

[jasonkester]

In v1.1 you have to do this programitically. In v2.0 you can use the OnClientClick
property.

<form id="form1" runat="server">
<asp:LinkButton runat="server" ID="_foo"

</form>

protected void Page_Load(object sender, EventArgs e)
{
_foo.Attributes.Add("onclick", "return confirm('Yes?')");
}

[plus some AutoEventWireup magic to point that linkButton to _foo_Click()

No offence intended to the quoted author here, but does anybody
actually write code that looks like this? The code below is
functionally equivilant, yet is readable as HTML:

<form id="form1" runat="server">
<a ID="_foo" onserverclick="_foo_Click" onclick="return
confirm('Yes?')" runat="server">DoWork</a>
</form>

I cannot understand why anbody would choose to use <asp:LinkButton>
over <a>, <asp:TextBox> over <input type=text>, <asp:label> over
<span>, etc. Every HTML tag is capable of taking a runat=server
attribure and exposing its DOM properties to the server. Why then,
would we use Microsoft proprietary equivilants for these things, when
we get little or no added functionality from them?

Could it possibly be for cross-platform compatability? Is there
actually a case where <asp:LinkButton...> will render anything other
than <a href=...>? Somehow I doubt it.

The only explaination I can come up with is that since the Drag & Drop
designer uses the <asp:...> tags, developers just assume that they
cannot use HTML in their ASPXs anymore. Laziness and undereducation?
This hardly sounds possible in all cases. The quoted author being an
evidence disproof, as he is clearly a skilled and knowledgeable .NET
developer.

Any comment?


Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/

 

[JiangZemin]

Hi,
if you have several of these tags and need to handle a bunch of attributes
for each of them, i think its cleaner and easier to maintain if you can put
all that in one section, rather than scattered all around the HTML. This
advantage isnt apparent when looking at simplified sample code of course.
I used to feel the same way you did (why not just keep it in the tags) but
then i had to maintain someone's elses code who did it with Attributes.Add
and it was much more pleasant.

JMHO,
JiangZemin

In v1.1 you have to do this programitically. In v2.0 you can use the OnClientClick
property.

<form id="form1" runat="server">
<asp:LinkButton runat="server" ID="_foo"

</form>

protected void Page_Load(object sender, EventArgs e)
{
_foo.Attributes.Add("onclick", "return confirm('Yes?')");
}

[plus some AutoEventWireup magic to point that linkButton to _foo_Click()

No offence intended to the quoted author here, but does anybody
actually write code that looks like this? The code below is
functionally equivilant, yet is readable as HTML:

<form id="form1" runat="server">
<a ID="_foo" onserverclick="_foo_Click" onclick="return
confirm('Yes?')" runat="server">DoWork</a>
</form>

I cannot understand why anbody would choose to use <asp:LinkButton>
over <a>, <asp:TextBox> over <input type=text>, <asp:label> over
<span>, etc. Every HTML tag is capable of taking a runat=server
attribure and exposing its DOM properties to the server. Why then,
would we use Microsoft proprietary equivilants for these things, when
we get little or no added functionality from them?

Could it possibly be for cross-platform compatability? Is there
actually a case where <asp:LinkButton...> will render anything other
than <a href=...>? Somehow I doubt it.

The only explaination I can come up with is that since the Drag & Drop
designer uses the <asp:...> tags, developers just assume that they
cannot use HTML in their ASPXs anymore. Laziness and undereducation?
This hardly sounds possible in all cases. The quoted author being an
evidence disproof, as he is clearly a skilled and knowledgeable .NET
developer.

Any comment?


Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/

 

[Brock Allen]

No offence intended to the quoted author here, but does anybody

actually write code that looks like this? The code below is
functionally equivilant, yet is readable as HTML:

Well, for this situation, the question/sample was requested for a LinkButton.
There are times when the question asked is along the wrong path and thus
sometimes need readjusting. But then other times, for the sake of simplicity,
it is easier to accept the flawled lead and just answer the question to get
the dev up and running.

I cannot understand why anbody would choose to use <asp:LinkButton>
over <a>, <asp:TextBox> over <input type=text>, <asp:label> over
<span>, etc. Every HTML tag is capable of taking a runat=server
attribure and exposing its DOM properties to the server. Why then,
would we use Microsoft proprietary equivilants for these things, when
we get little or no added functionality from them?

There are times, though, when it is preferable to use a server side object
to do interesting work. Now of course, there are usually two choices between
HtmlControls and WebControls. WebControls, in my experience, tend to provide
a richer and more consistent API. Also, WebControls fire server side event
by default, so if I require a server event then these controls will be my
preference. When I am not interested in taking over tight control over the
client rendering/behavior, I go with WebControl. This is the majority of
the time I use server-side controls. The only time I choose HtmlControls
is when I need a server side object to initialize some data on the control
and I want control of the client side tag (with script typically) but then
from then on the control/tag will be client side only, meaning no postbacks.

Could it possibly be for cross-platform compatability? Is there
actually a case where <asp:LinkButton...> will render anything other
than <a href=...>? Somehow I doubt it.

But as you've noted, at the end of the day, these things need to render as
good old HTML. For a simple control, you're right, there's little cross browser
compatibility. For other controls there is some merit to that argument. I
imagine you're aware of those other controls (and benefits).

The only explaination I can come up with is that since the Drag & Drop
designer uses the <asp:...> tags, developers just assume that they
cannot use HTML in their ASPXs anymore. Laziness and undereducation?
This hardly sounds possible in all cases.

So I don't follow what you're getting at? Why does it matter which control
you use? We've agreed that they both render as HTML. Why is it such an issue?
Each provides its own pros and cons based upon the situation upon which it's
being used and what the dev's trying to accomplish. As I mentioned above,
I prefer to use WebControls as they facilitate and ease my development (in
general).

 

[Dave Fancher]

I think that you're being a little over-simplistic with this view. While I
won't argue that the code you have provided is functionally equivalent to
what Brock wrote, Brock was just providing a sample of what the original
poster is trying to do.

In all cases, one must consider the task to be accomplished. HtmlControls
are best suited for scenarios where little to no server interaction is
needed and most of the interaction with the object will occur on the client.
If some layout changes must be tweaked based on a certain condition
determined by the server or you just need to read/write some basic
properties, great, use an HtmlControl.

On the other hand, if your server-side program logic is driven by the
changing state(s) of a particular object then WebControls are typically the
better choice. Take a scenario where a particular page contains multiple
<SELECT>s. If the contents of one <SELECT> are dependent on the selection
of another <SELECT> and the page must automatically post back to retrieve
the correct data for populating the text box, WebControls GREATLY simplify
this task.

Being more specific to this case, I believe that your "equivalent" example
has misused a control. You're free to disagree but I interpret <a
href="..." runat="server">...</a> (an instance of HtmlAnchor) as an object
to be used for linking from one page to another. Typically, I would use
this control only when I needed to dynamically set the HRef or Disabled
property based on some server side condition (typically a value from a
database). I would not use this control as the "gateway" for triggering a
server side event. Sure, you can provide a handler for ServerClick but this
seems to defeat the intended purpose of seperating HtmlControls and
WebControls. The ServerClick event also does not provide the same level of
functionality that is accessible through a LinkButton. You should also
notice that specifying a handler for ServerClick can override the value for
the HRef property because the HRef property is used to call __doPostBack.
(<a href="javascript:__doPostBack(...);">...</a>)

<asp:LinkButton> (an instance of LinkButton) serves a completely different
purpose. The purpose of a LinkButton is to provide the functionality of a
"typical" push button but display with the format of a hyperlink. The
decision to use a LinkButton rather than a button is purely aesthetic and
dependent on the design of the user interface. The purpose of a button is
to respond to a click event by performing a programatic function via an
event handler. It is for this reason that the LinkButton class provides
properties for CommandArgument and CommandName along with a Command event
that uses CommandEventArgs rather than EventArgs.

In this case, using a LinkButton is a perfectly acceptable option and, to
me, is preferable to the HtmlAnchor option. Another thing to consider here
is that this doesn't appear to be a case where browser compatibility is
really an issue. While I agree that many applications do need to be
cross-browser compatible, keep in mind that the majority of ASP.NET
applications are intranet applications and browser usage is dictated by the
company so it really becomes a non-issue.

I'm sorry to end this with a cliche but if the only tool you have is a
hammer, everything looks like a nail. Consider the task and choose the
right tool for the job.

 

[Dave Fancher]

Oops, I accidentally referred to "text box" in the third paragraph when I
intended to write <SELECT>. Sorry for any confusion! I've corrected the
error below.

 

[Kevin Spencer]

Any comment?

No. We are not sheep. We are humans.

--
Ba-a-a-a-a,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

In v1.1 you have to do this programitically. In v2.0 you can use the OnClientClick
property.

<form id="form1" runat="server">
<asp:LinkButton runat="server" ID="_foo"

</form>

protected void Page_Load(object sender, EventArgs e)
{
_foo.Attributes.Add("onclick", "return confirm('Yes?')");
}

[plus some AutoEventWireup magic to point that linkButton to _foo_Click()

No offence intended to the quoted author here, but does anybody
actually write code that looks like this? The code below is
functionally equivilant, yet is readable as HTML:

<form id="form1" runat="server">
<a ID="_foo" onserverclick="_foo_Click" onclick="return
confirm('Yes?')" runat="server">DoWork</a>
</form>

I cannot understand why anbody would choose to use <asp:LinkButton>
over <a>, <asp:TextBox> over <input type=text>, <asp:label> over
<span>, etc. Every HTML tag is capable of taking a runat=server
attribure and exposing its DOM properties to the server. Why then,
would we use Microsoft proprietary equivilants for these things, when
we get little or no added functionality from them?

Could it possibly be for cross-platform compatability? Is there
actually a case where <asp:LinkButton...> will render anything other
than <a href=...>? Somehow I doubt it.

The only explaination I can come up with is that since the Drag & Drop
designer uses the <asp:...> tags, developers just assume that they
cannot use HTML in their ASPXs anymore. Laziness and undereducation?
This hardly sounds possible in all cases. The quoted author being an
evidence disproof, as he is clearly a skilled and knowledgeable .NET
developer.

Any comment?


Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/