473,464 Members | 1,693 Online
Bytes | Software Development & Data Engineering Community
Create Post

Home Posts Topics Members FAQ

OnClick Handler

In a C# project I have an array of PictureBoxes.
I form an event handler for each picturebox as it is created using i as an
index.
PictureBox1[i].Click += new System.EventHandler(ClickHandler);

In the event handler I would like to determine the index of the clicked box.
The code below does not return the index.

public void ClickHandler(Object sender, System.EventArgs e)
{
textBox1.Text = sender.ToString();
}

Any help would be appreciated.
Thanks,
Jim
Jun 27 '08 #1
13 1369
On Mon, 05 May 2008 20:45:00 -0700, Jim <Ji*@discussions.microsoft.com
wrote:
In a C# project I have an array of PictureBoxes.
I form an event handler for each picturebox as it is created using i as
an
index.
PictureBox1[i].Click += new System.EventHandler(ClickHandler);

In the event handler I would like to determine the index of the clicked
box.
There are at least two approaches I can think of that would be reasonable.

The first involves using the Tag property of the PictureBox control. You
can assign the index of the control to the Tag property, and then read it
back out later in the handler:

PictureBox1[i].Click += ClickHandler;
PictureBox1[i].Tag = i;

and...

public void ClickHandler(object sender, EventArgs e)
{
Control ctl = (Control)sender;
int i = (int)ctl.Tag;
}

Alternatively, you could use an anonymous method for the handler that
captures the index, and pass that to a method that actually does the work:

for (int i = 0; i < PictureBox1.Length; i++)
{
// Note that you need a local variable that
// is newly scoped for each iteration of the array,
// so that each anonymous method gets a new captured
// variable. Otherwise, they will all wind up using
// the same variable and thus the same value.

int iCaptured = i;

PictureBox1[i].Click += delegate(object sender, EventArgs e)
{ ClickHandler(sender, iCaptured); };
}

and...

public void ClickHandler(object sender, int i)
{
// do stuff with i
}

Either should work fine. Using the Tag is probably simpler and easier,
but if you're already using the Tag for something else, the anonymous
method approach should be a good alternative.

Pete
Jun 27 '08 #2
"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...
There are at least two approaches I can think of that would be reasonable.
You could just search the array.
The first involves using the Tag property of the PictureBox control. You
This sort of thing is generally best avoided as you now have a piece of data
stored in 2 locations that could report different results. Seeing that we're
just talking about the user clicking on a picturebox then searching the
array would be simplest and fast enough. If the array is modified in any way
then tags don't need to be updated.

Michael
Jun 27 '08 #3
On Mon, 05 May 2008 21:37:33 -0700, MichaelC <mi**@nospams.comwrote:
"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...
>There are at least two approaches I can think of that would be
reasonable.

You could just search the array.
You could. I disagree that it's the cleanest, most elegant approach.
>The first involves using the Tag property of the PictureBox control.
You

This sort of thing is generally best avoided as you now have a piece of
data
stored in 2 locations that could report different results.
First, the "piece of data" isn't "stored" in two locations. Arguably it's
represented in two places, but a) it's really only stored in one place,
and b) there's nothing fundamentally wrong with doing it that way.

After all, if your objection was legitimate, the whole Control hiearachy
implementation in the Forms namespace is flawed. It does basically the
same thing, as does any data structure that maintains a back-reference to
an element of a collection that refers to an item.
Seeing that we're
just talking about the user clicking on a picturebox then searching the
array would be simplest and fast enough. If the array is modified in any
way
then tags don't need to be updated.
Who said the array would ever be modified in any way?

I don't disagree that maintaining the Tag property if the containing
collection is changed is more complicated. However, that wasn't ever a
stated requirement and even if it was, it's not a problem to reiterate the
array and reset all the Tag properties if the array changes. As long as
the collection itself changes less frequently than an object in the
collection is clicked (which seems likely) you're theoretically better off
iterating the collection just when it changes, rather than every single
time a mouse click happens.

Granted, as long as the array is small (and it ought to be), it's not a
significant cost either way. But I strongly dispute your criticism that
the use of the Tag property is somehow an undesirable approach.

Pete
Jun 27 '08 #4
Peter Duniho wrote:
You could just search the array.

You could. I disagree that it's the cleanest, most elegant approach.
How about making the array a List<PictureBoxinstead and simply
doing...

int i = pictureBoxes.IndexOf((PictureBox)sender);

Cheers Tim.

--

Jun 27 '08 #5
"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...
You could. I disagree that it's the cleanest, most elegant approach.
I didn't expect you to agree, seeing as you didn't think of it. However, if
you've got a list of items and want to find the index of the item in that
list then the simplest method is to search the list. It might not be the
quickest but we don't need speed here.
First, the "piece of data" isn't "stored" in two locations.
Whatever, you know exactly what I meant and are just being argumentitive.
Arguably it's represented in two places, but a) it's really only stored
in one place, and b) there's nothing fundamentally wrong with doing it
that way.
There is most definately something wrong with storing the same thing twice
if you have no good to do so. This I thought was fairly well known.
After all, if your objection was legitimate, the whole Control hiearachy
implementation in the Forms namespace is flawed. It does basically the
same thing, as does any data structure that maintains a back-reference to
an element of a collection that refers to an item.
Possibly it is, possibly it isn't. You're drawing quite a long bow there
whatever the case.
Who said the array would ever be modified in any way?
No one, but in the case that it is there is zero chance of the index getting
messed up.
I don't disagree that maintaining the Tag property if the containing
collection is changed is more complicated. However, that wasn't ever a
stated requirement and even if it was, it's not a problem to reiterate the
array and reset all the Tag properties if the array changes.
Sure but it's one thing you don't need to do.
As long as the collection itself changes less frequently than an object
in the collection is clicked (which seems likely) you're theoretically
better off iterating the collection just when it changes, rather than
every single time a mouse click happens.
Speed is not an issue in this case.
Granted, as long as the array is small (and it ought to be), it's not a
significant cost either way. But I strongly dispute your criticism that
the use of the Tag property is somehow an undesirable approach.
Less desirable approach Peter.

Michael
Jun 27 '08 #6
"Tim Jarvis" <ti*@jarvis.com.auwrote in message
news:OX**************@TK2MSFTNGP03.phx.gbl...
How about making the array a List<PictureBoxinstead and simply
doing...

int i = pictureBoxes.IndexOf((PictureBox)sender);
Don't be silly. Peter's ideas are much simpler than that 1 line of code :-)

Michael
Jun 27 '08 #7
On Mon, 05 May 2008 22:09:51 -0700, Tim Jarvis <ti*@jarvis.com.auwrote:
How about making the array a List<PictureBoxinstead and simply
doing...

int i = pictureBoxes.IndexOf((PictureBox)sender);
How is that different from Michael's suggestion? You can do basically the
same thing with an Array.
Jun 27 '08 #8
On Mon, 05 May 2008 22:30:31 -0700, MichaelC <mi**@nospams.comwrote:
"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...
>You could. I disagree that it's the cleanest, most elegant approach.

I didn't expect you to agree, seeing as you didn't think of it.
Don't confuse not mentioning something with not thinking of it.
[...]
There is most definately something wrong with storing the same thing
twice
if you have no good to do so. This I thought was fairly well known.
I've never heard the phrase "if you have no good to do so", but assuming
you mean that you shouldn't store the same thing twice if there's no need,
then you are making a tautological argument. You've started with the
assumption that there's no need, so of course you come to the conclusion
that there's no need.

It's hardly a useful conclusion though.
>After all, if your objection was legitimate, the whole Control hiearachy
implementation in the Forms namespace is flawed. It does basically the
same thing, as does any data structure that maintains a back-reference
to
an element of a collection that refers to an item.

Possibly it is, possibly it isn't. You're drawing quite a long bow there
whatever the case.
I have no idea what you mean here. The phrase "possibly it is, possibly
it isn't" adds nothing, as it's a trivially true statement without any
actual meaning. You might as well write "it's either true or it's
false". The second sentence is a colloqualism I don't recognize. If it's
meant to add to the discussion, it's lost on me.
>Who said the array would ever be modified in any way?

No one, but in the case that it is there is zero chance of the index
getting
messed up.
There is zero chance of it getting messed up as long as the Tags are
updated any time the array is. So?
>I don't disagree that maintaining the Tag property if the containing
collection is changed is more complicated. However, that wasn't ever a
stated requirement and even if it was, it's not a problem to reiterate
the
array and reset all the Tag properties if the array changes.

Sure but it's one thing you don't need to do.
And iterating over the array every time the mouse is clicked is also one
thing you don't _need_ to do. So?
>As long as the collection itself changes less frequently than an object
in the collection is clicked (which seems likely) you're theoretically
better off iterating the collection just when it changes, rather than
every single time a mouse click happens.

Speed is not an issue in this case.
I did say "theoretically". But even if we are absolutely positive that
speed is not an issue...so what?
>Granted, as long as the array is small (and it ought to be), it's not a
significant cost either way. But I strongly dispute your criticism that
the use of the Tag property is somehow an undesirable approach.

Less desirable approach Peter.
Fine. I dispute that criticism as well.

There's nothing wrong with the approach you've suggested. However,
there's absolutely something wrong with the WAY you've suggested it.
You've got absolutely no basis for claiming that iterating the array is a
superior solution. It's a _different_ and _valid_ solution, to be sure.
But other than that, forget it. Any claim you might have regarding it
superiority is based solely on your subjective opinion, and like or not
your opinion is not a valid basis for claims of superiority.

Pete
Jun 27 '08 #9
"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...
Don't confuse not mentioning something with not thinking of it.
Fair enough although if you'd thought of the simplest easiest method I would
have thought you'd mention it.
I've never heard the phrase "if you have no good to do so", but assuming
you mean that you shouldn't store the same thing twice if there's no need,
then you are making a tautological argument. You've started with the
assumption that there's no need, so of course you come to the conclusion
that there's no need.
Hardly, my statement was that you would use an alternative method if speed
was an issue. As speed is clearly not an issue in this case there is no need
to store the same thing twice.
It's hardly a useful conclusion though.
That is wrong.
I have no idea what you mean here. The phrase "possibly it is, possibly
it isn't" adds nothing, as it's a trivially true statement without any
actual meaning.
That was the point silly!!! It was meant to be trivial to reflect your
trivial statement.
You might as well write "it's either true or it's false". The second
sentence is a colloqualism I don't recognize. If it's meant to add to
the discussion, it's lost on me.
Drawing a long bow means you're trying to associate 2 things that are really
quite different and drawing incorrect conclusions by doing that.
There is zero chance of it getting messed up as long as the Tags are
updated any time the array is. So?
So what you're saying is there's zero chance of it getting messed up if you
don't mess it up. The FACT is there is a possibility of it getting messed
up. That possibility might be small but it's not zero as you state. I prefer
to eliminate any potential sources of bugs. You could even have someone else
come along and decide to use the Tag property for something else.
And iterating over the array every time the mouse is clicked is also one
thing you don't _need_ to do. So?
As Jim stated you can get the framework to do it for you.
Fine. I dispute that criticism as well.
Of course you do, as usual.
There's nothing wrong with the approach you've suggested. However,
there's absolutely something wrong with the WAY you've suggested it.
You've got absolutely no basis for claiming that iterating the array is a
superior solution. It's a _different_ and _valid_ solution, to be sure.
But other than that, forget it. Any claim you might have regarding it
superiority is based solely on your subjective opinion, and like or not
your opinion is not a valid basis for claims of superiority.
No, I've provided some fairly significant reasons as to why it's superior,
you've just ignored them. (remember the joke "I haven't listed to a single
complaint" :-)

Michael

Jun 27 '08 #10
Peter Duniho wrote:
How is that different from Michael's suggestion? You can do
basically the same thing with an Array.
Well its not really :-)

I was just pointing out that a "search" need not necessarily be
something as onerous as...

for(int i = 0;i < pictureBoxes.Length();i++)
{
if ( pictureBoxes[i] == (PictureBox)sender)
{
index = i;
break;
}
}

However I also forgot that he could also just use the Array.IndexOf
static method so he doesn't even need to use a List or Collection.

Anyhoo, I wasn't actually dissing your approach either, I am on
nobody's "side" here. Its true that I am also not a particular fan of
using Tag properties for this kind of thing, but I am also pragmatic
enough to agree that in most cases it's no particular problem.

Cheers Tim.

--

Jun 27 '08 #11
On Mon, 05 May 2008 23:37:04 -0700, MichaelC <mi**@nospams.comwrote:
[...]
>I've never heard the phrase "if you have no good to do so", but assuming
you mean that you shouldn't store the same thing twice if there's no
need,
then you are making a tautological argument. You've started with the
assumption that there's no need, so of course you come to the conclusion
that there's no need.

Hardly, my statement was that you would use an alternative method if
speed
was an issue.
No, that wasn't your statement at all. You wrote: "There is most
definately [sic] something wrong with storing the same thing twice if you
have no good to do so. This I thought was fairly well known." That
contains no reference to "speed", nor is speed the only criteria here.
The fact is, in its way, using the Tag property is _simpler_ than your
proposal.
As speed is clearly not an issue in this case there is no need
to store the same thing twice.
Again with the tautology. You start with the unfounded assumption that
speed is the only advantage that using the Tag property has, as if it's
axiomatic. Well, it's not. You are simply taking as an assumption the
very thing you're trying to prove.
>I have no idea what you mean here. The phrase "possibly it is, possibly
it isn't" adds nothing, as it's a trivially true statement without any
actual meaning.

That was the point silly!!! It was meant to be trivial to reflect your
trivial statement.
What trivial statement? And why are you confusing the statement I
actually wrote, that the phrase is "trivially true", with a more general
statement that it's "trivial"?

You may well have intended your statement to be trivial, but that wasn't
the observation I was making.
>You might as well write "it's either true or it's false". The second
sentence is a colloqualism I don't recognize. If it's meant to add to
the discussion, it's lost on me.

Drawing a long bow means you're trying to associate 2 things that are
really
quite different and drawing incorrect conclusions by doing that.
In the context of your overly broad generalization, you claim these
examples are "really quite different"? That's rich.

The fact is, storing redundant information is a common technique.
Asserting that it's always the wrong thing to do flies the face of
timeless, useful engineering strategies.
>There is zero chance of it getting messed up as long as the Tags are
updated any time the array is. So?

So what you're saying is there's zero chance of it getting messed up if
you
don't mess it up.
No. My statement and your attempt to paraphrase it are quite different
from each other.
The FACT is there is a possibility of it getting messed
up.
It's possible to mess anything up, if you're careless enough, including
your own suggestion. There's nothing unduly complicated about using the
Tag property as a back-reference that would introduce some significant
risk of it being messed up.
[...]
>And iterating over the array every time the mouse is clicked is also one
thing you don't _need_ to do. So?

As Jim stated you can get the framework to do it for you.
Actually, since we're talking about an array here, _I_ stated that. Tim
(not Jim) stated that you can get the framework to do it if you use a
List<T>.

Regardless, whether the framework does it or not, it's not something you
_need_ to do. The question of whether you write the loop yourself or call
a .NET method that already has the loop is irrelevant.
>Fine. I dispute that criticism as well.

Of course you do, as usual.
You're right. It's quite common for me to dispute things that are
incorrect. What's your point?
>[...] Any claim you might have regarding it
superiority is based solely on your subjective opinion, and like or not
your opinion is not a valid basis for claims of superiority.

No, I've provided some fairly significant reasons as to why it's
superior,
I haven't seen a single "fairly significant reason" posted by you. Only
your inflated sense of the importance of the reasons you've stated causes
you to describe them as "fairly significant". You've failed to
demonstrate in any sort of logically sound way that the reasons are
"fairly significant". We have only your subjective assertion that they
are so.

Pete
Jun 27 '08 #12
Jim wrote:
In a C# project I have an array of PictureBoxes.
I form an event handler for each picturebox as it is created using i as an
index.
PictureBox1[i].Click += new System.EventHandler(ClickHandler);

In the event handler I would like to determine the index of the clicked box.
The code below does not return the index.

public void ClickHandler(Object sender, System.EventArgs e)
{
textBox1.Text = sender.ToString();
}

Any help would be appreciated.
The lengthy back and forth elsewhere in this thread aside, can I just ask why
you have this particular design? What are you attempting to solve with this?

Does the Array of PictureBoxes stick around after instantiation? If so, why?

PictureBox + click event makes me think slideshow.

Chris.
Jun 27 '08 #13
"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...
On Mon, 05 May 2008 23:37:04 -0700, MichaelC <mi**@nospams.comwrote:
Test...

Sent three replies so far which haven't appeared.

Michael
Jun 27 '08 #14

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Jim Mitchell | last post by:
I have some code behind that generates 10 imagebutton controls.... I can not seem to figure out how to trap the onclick event for each image and determine which image was clicked. Can someone...
2
by: Andy Goldstein | last post by:
I have a table where all the TRs have an onClick handler registered. One (and only one) of the rows has 2 text input boxes, where each textbox has an onChange handler registered. Both the onClick...
2
by: RobG | last post by:
I am trying to dynamically add an onclick to an element, however I just can't get the syntax right. consider the following function: function doClick (evt,x) { // do things with evt and x } ...
2
by: Peter | last post by:
I would like to use code like the following: this.onclick = function(e) { alert("I'm in the onclick handler"); } But I do not want to wipe out any existing onclick event code. I want to do...
9
by: Donius | last post by:
Hey everyone, i am doing some stuff where i'd like to pop up a little confirmation before a user clicks on a 'delete' link. Just trying to keep the markup clean, i added an attribute ...
4
by: sameergn | last post by:
Hi, I have an image in my HTML form which has onclick() handler. There is also a submit button and a text box. Whenever text box has focus and user presses enter, the onclick() event of...
10
by: Carlos Araya | last post by:
I have the following link on a web page <p class="menuitem"><a href="#" onclick="loadFragment('http://rivendellweb.net/fortress/home', 'index')" title="The Fortress Home">The Fortress...
17
by: yawnmoth | last post by:
http://www.frostjedi.com/terra/scripts/demo/this-alert.html http://www.frostjedi.com/terra/scripts/demo/this-alert2.html Why, when you click in the black box, do the alert boxes say different...
9
by: skultetc | last post by:
Hey all, I have a div displayed as a block with an onclick event that shows/ hides a different div underneath it. There is a link within the first div that takes the user to a different page. My...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
1
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
0
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
0
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The...
0
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.