Make onclick do more than one thing?

[Arch]

I have a datagrid with clickable rows. When a row is clicked, a button
column fires and takes my user to another page. My datagrid rows also
change text color with the onmouseover and onmouseout events.

Everything works great, but when my user clicks the back button to go
back to the page with the datagrid, the row they clicked on is still
highlighted unless my user passes the mouse over it again to trigger the
onmouseout event. It looks weird and I'm afraid it will confuse my users.

Is there a way to make an onclick event perform more than one function
at a time? I'd like it to not only trigger a button column, but also
turn the text color back to its original color - in other words, I'd
like my dopostback event to perform the onmouseout event as well as
trigger the button column.

Thanks for any help. Here is the sub I'm using to add the java:

Protected Sub DataGrid_ItemCreated(ByVal sender As Object, ByVal e As
System.Web.UI.WebControls.DataGridItemEventArgs)
if e.Item.ItemType = ListItemType.Item Or e.Item.ItemType =
ListItemType.AlternatingItem Then
e.Item.Attributes.Add("onmouseover", "this.style.color='blue'")
e.Item.Attributes.Add("onmouseout", "this.style.color='black'")
e.Item.Attributes.Add("onclick",
javascript:__doPostBack('dgrDataGrid$ctl" & _
(e.Item.ItemIndex.ToString() + 2) & _
"$ctl00','')")
end if
end sub

 

[Gregory A. Beamer]

Everything works great, but when my user clicks the back button to go
back to the page with the datagrid, the row they clicked on is still
highlighted unless my user passes the mouse over it again to trigger
the onmouseout event. It looks weird and I'm afraid it will confuse my
users.

The back button is the bane of web development.

Is there a way to make an onclick event perform more than one function
at a time? I'd like it to not only trigger a button column, but also
turn the text color back to its original color - in other words, I'd
like my dopostback event to perform the onmouseout event as well as
trigger the button column.

Yes, you can do this, but unless you do this step first, the back button
will still reveal the trickery.

One option is to use AJAX instead to update the page. With AJAX, you are
already working with JavaScript, so dinking a bit more is a bit easier.
This means retooling the page, however, which you have to weigh.

Another option is to add your own JavaScript handler. This may require
creating your own control inherited from GridView (DataGrid) that spits
out both the postback and the javascript to change colors back.

A third option is disable the freaking back button and place a button
that says "BACK" on the page. When the user clicks that button, refresh
their original state.

Back has always been a pain with web apps. It is a great feature for web
pages, so users become accustom to clicking the back button. Unless you
stop them, you will always have something, somewhere, that pukes.

I do not usually disable the back button. It really depends on my users.
If they are complaining about back not working properly, and refuse to
accept the answer, however, I have been known take away their super
power and leave them as mere mortals. ;-)

Peace and Grace,

--
Gregory A. Beamer (MVP)

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

 

[Arch]

Mark, not the answer I was after, but info I needed. I will explore the
Gridview control. I don't know enough to convert your code snippets from
C# to VB, but that's what Google is for.

Thanks very much for taking the time

Grateful Noob :|

There are several issues here:

I have a datagrid

The DataGrid control was superceded in ASP.NET v2 by the GridView control:
http://www.google.co.uk/search?sourceid=chrome&ie=UTF-8&q=DataGrid+GridView
The GridView is much more powerful and feature-rich than the DataGrid,
which only remains for backwards compatibility. I strongly suggest you
convert all instances of the DataGrid control to the GridView control.

Everything works great, but when my user clicks the back button to go
back to the page with the datagrid, the row they clicked on is still
highlighted unless my user passes the mouse over it again to trigger
the onmouseout event. It looks weird and I'm afraid it will confuse my
users.

This is completely standard and expected behaviour, and is one of the
(many) reasons why web applications try very hard to discourage users
from using the back and forward buttons. You will typically see warnings
on web applications which are e-commerce enabled telling users
absolutely not under any circumstances to click the "Checkout" button
more than once or, once payment has been taken, to click the back button
otherwise there is a strong possibility that payment will be taken more
than once. The reason for this is that the back button will return to
the previous page in the browser's history cache and open it in EXACTLY
the same way and state that it was previously opened. If this was as the
result of a postback, then clicking the back button will open the
previous button is if it is being opened as the result of a postback,
preserving ViewState etc. This is why the background colour of the row
which was clicked retains its changed colour when the page is opened as
a result of the user clicking the back button.

Fortunately, because you're changing the row's background colour with
client-side JavaScript, this isn't so much of an issue. Simply reset the
row's background colour to black as part of the code behind the
server-side click event.

Thanks for any help. Here is the sub I'm using to add the java:

You're adding JavaScript, not Java - they are not the same thing at all...

e.Item.Attributes.Add("onclick",
javascript:__doPostBack('dgrDataGrid$ctl" & _
(e.Item.ItemIndex.ToString() + 2) & _
"$ctl00','')")

Avoid that at all costs. For one thing, you're hard-coding the ASP.NET
munged control IDs which can change pretty much at any time e.g. if you
were to wrap the grid control in a Panel, etc.

Instead, once you've upgraded the DataGrid to a GridView, do this:

protected void gvGridView_RowDataBound(object sender,
GridViewRowEventArgs e)
{
if (e.Row.RowType == DataControlRowType.DataRow)
{
e.Row.Attributes.Add("onmouseover",
"this.style.backgroundColor=Blue");
e.Row.Style["cursor"] = "pointer";
e.Row.Attributes.Add("onclick",
ClientScript.GetPostBackEventReference(gvGridView, "Select$" +
e.Row.RowIndex.ToString()));
}
}

protected void gvGridView_SelectedIndexChanged(object sender, EventArgs e)
{
gvGridView.SelectedRow.BackColor = System.Drawing.Color.Black;
// rest of the code goes here...
}

Obviously the above server-side code is in C# (I never go anywhere near
VB.NET), but is easily converted...

 

[Arch]

So everybody struggles with the back button? I can't tell you how good
that makes me feel.

I'll try putting a 'return' button on my page. If my users have
problems, I'll take away their choice. I agree it's a shame to limit
users' options - they may be retarded, but that's why programmers have
jobs. God love 'em.

Thanks so much for taking the time to reply.

Grateful noob :|

 

[Gregory A. Beamer]

So everybody struggles with the back button? I can't tell you how good
that makes me feel.

And we all occasionally fire off a question only to realize how simple
the answer is just 2 seconds after we hit send.

The back button was designed with HTML in mind, not apps. As web
"applications" were an after thought (HTML/HTTP replaced Gopher (1993),
which was much like a linked document repository).

Since the original creators of the "web" missed out on the state issue,
we pounded mechanisms on top of the stateless model. The first "apps"
were form submits (POSTs) to CGI applications (PERL was very common
early on).

If you want more information, you can check this blog entry out:
http://tinyurl.com/yh4eq3y

There are some patterns you can employ that lessen the effect of the
back button, but it will eventually bite you.

I'll try putting a 'return' button on my page.

This helps, especially if you train the users. Some, however, are so
ingrained (and perhaps stupid?) that they will still hit "back".

If my users have
problems, I'll take away their choice.

I agree with you that this is a last ditch effort, but it is necessary
for certain apps as you do not have time to refactor to patterns where
back is not as damaging.

NOTE: You do have another option. Expire the page. When you add the meta
tag for it to not cache on the client, the back button yields an empty
page. When they call for help, you ask "did you use the back button like
I told you not to?" The next question is "would you like me to disable
the back button on this app so this does not happen to anyone."

If you want to be really clever, you can set up an error page for
expired page requests that states:

YOU HIT THE BACK BUTTON, DIDN'T YOU?

Only kidding, but I have been tempted.

I agree it's a shame to limit
users' options - they may be retarded, but that's why programmers have
jobs. God love 'em.

If you do your job well, the majority of users will get it. The ones who
are dumb as a board will never get it, so don't spend time on trying to
make an application idiot proof. When you do, the world just builds a
bigger idiot.

Aim for the 90% (plus) that have the potential of getting it and realize
that there is a Darwin award for the rest.

NOTE: You should aim for a high percentage, however. If the UI only
works for 50% of the people, you are the failure.

Thanks so much for taking the time to reply.

You are welcome.

Peace and Grace,

--
Gregory A. Beamer (MVP)

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************