How can we stop/prevent initial cell blur?
How can we stop/prevent initial cell blur?
genydedx
Posts: 9Questions: 1Answers: 0
I am using the latest version of dataTables and keyTable. For the key-blur event, I would expect it to apply to the cell that is focused at the start of that event. But it seems to focus on the next cell and THEN apply the prevent.
How can we stop the current cell from blurring? Here is a link to an example http://live.datatables.net/daseyamu/3/edit
This question has an accepted answers - jump to answer
This discussion has been closed.
Answers
Do I really need to pay $500 to get some help with this?
You posted the question two hours ago. I looked at this earlier but it wasn't clear to me what you are trying to do. The developers are in the UK and probably won't look at it until tomorrow.
Please don't post duplicate threads.
Kevin
Thanks. I am trying to prevent/stop a cell blur (using https://datatables.net/reference/event/key-blur) in certain scenarios. But instead it seems to focus on the next cell and then suppress the blur form that cell instead of the original cell.
The duplicate post was due to my first time posting here and the 'Start Discussion' button being visible before the 'Ask Question' on the page. I wanted it to have the question tag, so I posted it again, but could not figure out how to delete the original.
Maybe you need to use the
key-focusevent and in the event usecell.blur(). Something like this maybe?http://live.datatables.net/daseyamu/4/edit
Kevin
Let me try to be a bit clearer...
A cell is focused. In certain situations, I want that cell to stay focused no matter what. Logic seems that e.preventDefault() on the blur event for that cell should keep the focus there, but it does not. Neither does stopPropagation or keys.disable. The current cell always blurs, the next cell gets the focus and THEN those suppressions kick in.
The docs (https://datatables.net/reference/event/key-blur) say the blur for the current cell should occur BEFORE the focus on the next cell (or paging if applicable), but that does not seem to be the case here.
Nope, as Kevin said, many people scan the forum responding to questions. I'd say the number of replies you've received within a day is a pretty good response.
That is the case, as seen by the console logging here. The problem would be that yep, you're disabling the keys in the blur, but by then the focus event would already be queued. The propagation would apply to the blur event, not the pending focus.
Would you be able to disable the keys when the focus occurs, rather than waiting for the blur, or does your flow prevent that?
Colin
I don't know yet... still trying to find the 'magic' combination here. This is the core scenario... There are a series of cells in a given row that are 'editable' (not using Editor, because they don't support out data structures). If the user changes a value in one of the editable fields for a given row, we only want that rows cells 'focusable' until all 'required editable cells in that row are filled in at which time, we'll save the row data and then the whole table becomes 'focusable' again.
We cannot do save on blur per cell (ideal) because this is a legacy app that is structured for all or nothing per row and we cannot change that. I know there has to be a way to get this working as needed. We'll just keep trying combos until we figure it out. Was just hoping maybe someone had a similar scenario and could shed some light on it.
Something like this https://datatables.net/reference/option/keys.columns but for rows instead of columns.
That description helps. As Colin mentioned it seems the focus to the next cell is queued when the
key-blurevent is fired. So there is no stopping the focus. I created a simplistic example that may give you some ideas:http://live.datatables.net/horageru/1/edit
It has a checkbox that you can simulate being in edit mode. It uses a global variable to keep track of the previously focused cell so it can be re-focused if in edit mode. When in edit mode it stays on the same row. Outside of edit mode it allows free movement through the table.
Kevin
Thanks! I think this gives us enough to figure it out.