OnClick Handler

[Jim]

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.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

 

[MichaelC]

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

 

[Tim Jarvis]

You could. I disagree that it's the cleanest, most elegant approach.

How about making the array a List<PictureBox> instead and simply
doing...

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

Cheers Tim.

--

 

[MichaelC]

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

 

[MichaelC]

How about making the array a List<PictureBox> instead 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

 

[MichaelC]

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

 

[Tim Jarvis]

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 == (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.

--

 

[Chris Shepherd]

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.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.

 

[MichaelC]

Test...

Sent three replies so far which haven't appeared.

Michael