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();
