<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Slow response in document with many tables after Table tree is expanded in Navigator" href="https://bugs.documentfoundation.org/show_bug.cgi?id=143268#c34">Comment # 34</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Slow response in document with many tables after Table tree is expanded in Navigator" href="https://bugs.documentfoundation.org/show_bug.cgi?id=143268">bug 143268</a> from <a class="email" href="mailto:genericinet+libreoffice.org@gmail.com" title="David <genericinet+libreoffice.org@gmail.com>"> David</a> <pre>(In reply to Jim Raykowski from <a href="show_bug.cgi?id=143268#c33">comment #33</a>) > (In reply to Jim Raykowski from <a href="show_bug.cgi?id=143268#c32">comment #32</a>) > > An improvement in response can be seen if the second argument to > > SwEditShell::GetTableFrameFormat is changed from true to false in the member > > loop. > > > No good! Changing the second argument to false causes tables that are > deleted to show their name greyed out in the Tables list. I've been using my own compiled version for about a week now. I've added 'return false;' to the beginning of 'case RES_AUTOFMT_DOCNODE:' case in sw/source/core/table/swtable.cxx. So far I have not seen any negative ramifications. If these statements need to be executed for some reason (although why they need executed for every keystroke I'd have to have explained), the simplest work-around (though not the best solution IMO) to mitigate the affects of the table tracking would be to add a context menu to disable the table tracking (while still listing the tables and other targets). Yes, it's always been slow, but before 7.0 table tracking wasn't always happening and so the affects weren't always noticed.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>