Changed values will in some cases not be sent to a DB

Tags: #<Tag:0x00007efc61e69970>
#1

Hi everyone,

after a row will be left I send the data set (row) via getDataAtRow() to a Database. This works fine for text, boolean and date values if the row will be left by pressing the Up or Down key. Changes of numeric values I get only if I first move to another column in the row and after this to the next or previous row. The same I have to do for text, numeric and date values if the row will be left with the PageUp/PageDown key or a mouse click in any other row. If not I get in this cases with getDataAtRow() only the old (last changed) value. Here is a demo.

This workaround catches the new value with the afterSetDataAtCell() hook and replaces the last changed value before I send the data set to the DB. This works now for numeric values too, but still not if I leave the row with PageUp, PageDown or a mouse click. Obviously I get in this cases the new values from afterSetDataAtCell() not soon enough to replace the old value. If anyone has a good idea for a solution, I would be interested :slight_smile:

#2

Hi @stelo

If I understand the idea and you need some code to work on a defined key or a combination of keys you can call it via the afterDocumentKeyDown callback.

Let me know if it solves the issue.

#3

Hi @aleksandra_budnik,

thank you for your advice! I use the afterSelection hook together with the latest_row variable to check, whether a new row is selected, this works fine.

The issue is, depending on the last data type which is changed and/or the way the row is left (Up/Down/PageUp/PageDown key or mouse click), the getSourceDataArray contains the last changed new or old value, as shown in my demo.

The question is, how can I secure only to get the new value? In my – not very peformant – workaround I can do this also for the numeric type, as long the user leaves the row with the Up or Down key, not with the PageUp/PageDown keys or a mouse click. In this cases I get, other then boolen type, the old value of the last changed cell.

#4

Can we create one scenario to test it?

Let’s say we change cell (0,0) from one to x and

  1. hit pageDown
    result: we get one in first result row and x in second
  2. hot down arrow
    result: we get one in first result row and x in second

It looks like it works the same for arrows and pageDown.
Please share an exact scenario to replicate the issue.

#5

Hi @aleksandra_budnik,

obviously my description was not clear, sorry!

If I do this like in your example, I get “one” in the first and “one” in the second result row. Maybe you hit [Enter] after the input and before [pageDown] – not all the people do this in that way. If you only type “x” and directly after this you hit [pageDown] or click with the mouse in another row, you will have the “x” in the cell (that’s what people see) but the old value as well in the second results. This only happens not with the boolean type.

The [up/down] key scenario with numeric values :slight_smile: If you change a numeric value and hit the [up] or [down] key – as I now noticed, even with the [Enter] key –, you will get as the second result (thats what I send to the DB) the old value though the new value is in the table.

I hope, you can replicate this with my – hopefully – better description.

#6

Hi @stelo

you’re right. I may press something else before, if I press PageDown I will get one as a result for both DB Action rows.

I guess it might be a bug.

#7

Hi @aleksandra_budnik,

I tried to find a workaround with different methods, as well with the new beta version, but failed. Because this is very important to me, can you foresee when this behaviour will be fixed?

#8

Sorry for keeping you waiting. I have tried to test it more, however, I did not find any workaround so I posted an issue on our Github board at https://github.com/handsontable/handsontable/issues/4264
Unfortunately, I do not now a fix date yet.

#9

Hi,

I have found that if you use the same logic and change afterSelection to afterSelectionEnd it works

#10

Hi @aleksandra_budnik,

nice find, thank you a lot! I have tested this solution and it looks very good. So I would say, this is solved.

#11

Great. I will then close the issue.

#12