Click Events on TableLayout

Volker Bruhn

Hello,

I am going through some basics to create games like sudoku, kakuro and so on.

Before doing the algorithms I want the user interface to work fine.

For now I have a scalable TableLayout, the cells are filled with Panels (later on, these are filled with Labels).

The user is able to navigate through the cells using the arrow keys, and should be able to select a cell by clicking with the mouse on it.

Now here is my problem: I do not know which cell, panel, label has been clicked. The best I got, was getting the X,Y using a MouseClick-event.

As the TableLayout is very flexible, it is very ... hmmm ... unfunny ... to get the cell by calculating the coordinates.

Is there a way to get the Click-event to send the clicked origin?

I think that WPF does it, but I am not acquainted with it at all. So how can I do it on Windows Forms???

Regards,

Volker

4 Replies

Know the answer? Post it — somebody with the same question will find it here.

Sam Hobbs16y ago
Accepted answer
Either the answer is simply to use the sender parameter of the click event or I don't understand the question. Are you familiar with the sender parameter? If that won't help then it is possible to determine the control that contains a specified point.
0
Mayur Gujrathi16y ago
Dear friend
Table Layout out panel has cells in following ways
Suppose you have 4 rows and 4 columns then cells are
00 10 20 30
01 11 21 31
02 12 22 32
03 13 23 33
0
Volker Bruhn16y ago
@Zoran: I use a percentage SizeStyle. And I guess that sooner or later I will have to go for own controls.
@Sam: I am rather this algorithm guy who uses controls for merely data-output. Thus I was not familiar with the sender object, yet. Thanks for the hint, as a simple Label lbl = (Label)sender; does what I needed.
Have fun! :)
0
Zoran Horvat16y ago
Questions:
1. Why can't you handle mouse events on the contained controls?
2. Did you use SizeStyle.Absolute or some other? If Absolute, then it's quite simple to calculate which cell was clicked (don't forget to add cell borders to calculation).

On an unrelated note, I've stopped using controls inside controls when creating graphical user controls, like sudoku. That proves much slower than owner drawn, and also sooner or later you hit the limitations posed by the controls used, like panels for instance (like table layout or tab panel, which are full of limitations). Instead of doing so, I'm always deriving from Control class and always implementing OnPaint event in a completely custom way. In that way, many problems disappear. Like calculating the click origin, or handling keyboard events, or doing animation, transparency, shadows and other effects, or drawing borders on semi-3D objects (borders width and construction change on every new Windows or .NET Framework release), and many other... The only justifiable case in which controls inside controls are correct is when using GUI elements that are used in the rest of the application, and thus should look the same (e.g. buttons, text boxes, list boxes, etc.). In all graphical uses - draw your own controls.
0