In a table, if a non-writable cell is clicked on, a "clicked" event is generated. However, if a writable cell is clicked on, no "clicked" event is generated. Only when another cell is clicked on, a "clicked" event is generated for the writable cell that was previously the current cell. In the case where a non-writable cell is the active cell, and then a writable cell is clicked on, no "clicked" event is generated at all.
This operation is inconsistent. Is this the intended operation, or an error? If intended, why? Shouldn't a click event be generated anytime a cell is clicked on, no matter the cell's configuration?
For my application, I want to know when a cell is clicked on, regardless of whether it is a writable or non-writable cell. I would expect the table "clicked" event to do this, but it does not for writable cells. I have tried some of the other table events such as KeyboardFocusIn/Out, MouseOver, and SelectionChanged but none of these provide the ability to know when a writable cell is clicked on in all circumstances. Is there a way to achieve this?
Table \"clicked\" event not consistent
- mkoller
- Posts:741
- Joined: Fri Sep 17, 2010 9:03 am
Re: Table \"clicked\" event not consistent
It is the way it's meant to be. The reason is simple: A writable cell gets the "clicked" event (the name "clicked" might be confusing here), which has the following arguments:
main(int row, string column, string value)
The idea is: the event gets triggered with the entered value, and your script can decide if the value entered is acceptable or not.
If it's not ok, this is your chance to set a corrected value.
So in fact it's not just a "the cell has been clicked" event.
What is your use case for needing a simple "cell has been clicked" event for writable cells ?
What are you trying to achieve just before the user changes the value ?
main(int row, string column, string value)
The idea is: the event gets triggered with the entered value, and your script can decide if the value entered is acceptable or not.
If it's not ok, this is your chance to set a corrected value.
So in fact it's not just a "the cell has been clicked" event.
What is your use case for needing a simple "cell has been clicked" event for writable cells ?
What are you trying to achieve just before the user changes the value ?
- tgdannemiller
- Posts:23
- Joined: Thu Apr 21, 2016 3:29 pm
Re: Table \"clicked\" event not consistent
It is confusing that the "Clicked" event is sometimes not really that. There could be a "CellChanged" event like there is a "TextChanged" event for a text field, then the "Clicked" event could always be what it is expected to be.
The reason I want to know when an editable cell is clicked into is so I can read it's present value before it gets edited. When the cell is edited or moved out of I can then tell if it's contents have changed. I could store a copy of the whole table to hold all present values, but that would require script code to keep the copy matching the table as the table is edited, rows are added/removed, etc. That is an unnecessary effort if I could just know when an editable cell is clicked into.
The reason I want to know when an editable cell is clicked into is so I can read it's present value before it gets edited. When the cell is edited or moved out of I can then tell if it's contents have changed. I could store a copy of the whole table to hold all present values, but that would require script code to keep the copy matching the table as the table is edited, rows are added/removed, etc. That is an unnecessary effort if I could just know when an editable cell is clicked into.
- mkoller
- Posts:741
- Joined: Fri Sep 17, 2010 9:03 am
Re: Table \"clicked\" event not consistent
Hmmm .. I really thought that you can still get the "old" value from the table inside the script and you need to set it explicitely back into the table - I think that was once the
designed functionality ... it seems my memories are either wrong or this feature has been lost in some transition ...
What might be a good solution for the product would be to pass the "old" value in addition to the script as last parameter.
I'll create a task for this.
A "clicked" event would not work since a script just starts a ctrl script thread but on click the table already shows the input editor. So effectively the script might already
be too late, since editing has already started (or already ended again).
designed functionality ... it seems my memories are either wrong or this feature has been lost in some transition ...
What might be a good solution for the product would be to pass the "old" value in addition to the script as last parameter.
I'll create a task for this.
A "clicked" event would not work since a script just starts a ctrl script thread but on click the table already shows the input editor. So effectively the script might already
be too late, since editing has already started (or already ended again).
- tgdannemiller
- Posts:23
- Joined: Thu Apr 21, 2016 3:29 pm
Re: Table \"clicked\" event not consistent
Thanks for considering this. Including the "old" value in the "Clicked" event parameters sounds like a good solution that doesn't break compatibility. Knowing the "old" value makes it possible to know if anything has changed in the table without keeping another copy of the table contents. Knowing if it has changed can be used to know whether or not the data in the table needs to be saved (or even knowing that line by line).
Of course this will not help for my present project, but I will find a work-around; keeping another copy of the table if necessary.
Of course this will not help for my present project, but I will find a work-around; keeping another copy of the table if necessary.