[Libreoffice-commits] core.git: compilerplugins/clang toolkit/source

[Noel Grandin (via logerrit)]

 compilerplugins/clang/referencecasting.cxx   |    3 +++
 toolkit/source/controls/stdtabcontroller.cxx |   16 +++++++++-------
 2 files changed, 12 insertions(+), 7 deletions(-)

New commits:
commit d5e222cd86b82a429c28cb19583521d581efaf2b
Author:     Noel Grandin <noel.grandin at collabora.co.uk>
AuthorDate: Mon Jun 1 13:51:51 2020 +0200
Commit:     Noel Grandin <noel.grandin at collabora.co.uk>
CommitDate: Mon Jun 1 18:42:11 2020 +0200

    Revert "tdf#125609 toolkit: don't use XTabController::getControls"
    
    This reverts LO6.4 commit 5cf057c3365a0feafc8f2e4f4a9e24d69a581999,
    in order to fix tdf#133158.
    
    This commit is obsolete, but was left in place since it
    seemed to have fixed a problem (in =gtk3 anyway).
    But now SAL_USE_VCLPLUGIN=gen behaves differently,
    so obviously a fix in one place must have broken another.
    
    Better the problems you have always known than
    a new problem, especially since this patch
    isn't used to fix anything specific in gtk3 anymore
    (since those changes were also reverted).
    
    An earlier gerrit version of this revert (which
    didn't just have an ignore-this-clang-rule exception)
    half-worked, but failed if multiple documents
    were opened.
    
    Change-Id: Ie8ddb7b9669fa46067d04c35e157ea08701df0da
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95282
    Tested-by: Jenkins
    Reviewed-by: Noel Grandin <noel.grandin at collabora.co.uk>

diff --git a/compilerplugins/clang/referencecasting.cxx b/compilerplugins/clang/referencecasting.cxx
index 33997cdb458d..f23e2f6811cd 100644
--- a/compilerplugins/clang/referencecasting.cxx
+++ b/compilerplugins/clang/referencecasting.cxx
@@ -44,6 +44,9 @@ public:
         // macros
         if (fn == SRCDIR "/dbaccess/source/ui/browser/formadapter.cxx")
             return false;
+        // UNO aggregation
+        if (fn == SRCDIR "/toolkit/source/controls/stdtabcontroller.cxx")
+            return false;
         return true;
     }
 
diff --git a/toolkit/source/controls/stdtabcontroller.cxx b/toolkit/source/controls/stdtabcontroller.cxx
index b0c6142476b0..0fa0f96f965c 100644
--- a/toolkit/source/controls/stdtabcontroller.cxx
+++ b/toolkit/source/controls/stdtabcontroller.cxx
@@ -306,17 +306,19 @@ void StdTabController::activateTabOrder(  )
     if ( !xC.is() || !xVclContainerPeer.is() )
         return;
 
+    // This may return a TabController, which returns desired list of controls faster
+    // (the dreaded UNO aggregration, retrieve the thing that we are part of)
+    Reference<XTabController> xTabController( static_cast<XTabController*>(this), UNO_QUERY );
+
     // Get a flattened list of controls sequences
     Sequence< Reference< XControlModel > > aModels = mxModel->getControlModels();
     Sequence< Reference< XWindow > > aCompSeq;
     Sequence< Any> aTabSeq;
 
-    // Previously used aControls = xTabController->getControls() "for the sake of optimization",
-    // but that list isn't valid during the creation phase (missing last created control) because
-    // listenermultiplexer.cxx handles fmvwimp::elementinserted before formcontroller::elementInserted
-    // Perhaps other places using the same optimization need to be reviewed?  (tdf#125609)
-    Sequence< Reference< XControl > > aCachedControls = getControls();
-    Sequence< Reference< XControl > > aControls = aCachedControls;
+    // DG: For the sake of optimization, retrieve Controls from getControls(),
+    // this may sound counterproductive, but leads to performance improvements
+    // in practical scenarios (Forms)
+    Sequence< Reference< XControl > > aControls = xTabController->getControls();
 
     // #58317# Some Models may be missing from the Container. Plus there is a
     // autoTabOrder call later on.
@@ -334,7 +336,7 @@ void StdTabController::activateTabOrder(  )
     {
         mxModel->getGroup( nG, aThisGroupModels, aName );
 
-        aControls = aCachedControls;
+        aControls = xTabController->getControls();
             // ImplCreateComponentSequence has a really strange semantics regarding it's first parameter:
             // upon method entry, it expects a super set of the controls which it returns
             // this means we need to completely fill this sequence with all available controls before