sc/source/ui/view/tabcont.cxx | 5 +++++ 1 file changed, 5 insertions(+)
New commits: commit 83d0f2eebae41d431d9a5bfd1a918523977752d0 Author: Justin Luth <justin_l...@sil.org> AuthorDate: Wed Dec 8 07:06:45 2021 +0200 Commit: Eike Rathke <er...@redhat.com> CommitDate: Thu Apr 28 23:50:39 2022 +0200 tdf#137899 sc: accept any unfinished editing before adding sheet There might be a more general place where this belongs, to cover other similar kinds of situations. However, putting it here is very targetted, and shouldn't get me into unanticipated trouble. Any changes made in the "top view" need to be accepted before they are committed. In this case, the user switched gears and added a new sheet while in the process of editing. So what should happen here? Should we commit the change before changing task? Perhaps. Certainly it should NOT show up on the new sheet - but that is what was happening. Accepting the change when the user gets side-tracked is the norm in cases like print-preview, switching to another soffice app, or simply clicking on a different cell or switching tabs. So auto-accepting in this situation is consistent behaviour. Change-Id: I4f3f0103ad4fcc1aa8a0c6118383b63ace07ff5e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126501 Tested-by: Jenkins Reviewed-by: Justin Luth <jl...@mail.com> Reviewed-by: Eike Rathke <er...@redhat.com> diff --git a/sc/source/ui/view/tabcont.cxx b/sc/source/ui/view/tabcont.cxx index a95df55b98d8..a15b1c20e54b 100644 --- a/sc/source/ui/view/tabcont.cxx +++ b/sc/source/ui/view/tabcont.cxx @@ -234,6 +234,11 @@ void ScTabControl::AddTabClick() ScModule* pScMod = SC_MOD(); if (!rDoc.IsDocEditable() || pScMod->IsTableLocked()) return; + + // auto-accept any in-process input - which would otherwise end up on the new sheet + if (!pScMod->IsFormulaMode()) + pScMod->InputEnterHandler(); + OUString aName; rDoc.CreateValidTabName(aName); SCTAB nTabCount = rDoc.GetTableCount();