LibreOffice Calc (not responding) in Title Bar for several seconds after an unremarkable edit

English
#1

This is not a question but rather a shared piece of learning from the school of hard knocks and silly mistakes…

Seemingly out of the blue a truly trivial edit in a cell that did nothing more than provide a blank/vacant/empty column partition or divider between adjacent tables of data … and suddenly I can’t get any response out of Calc for countable seconds. Certainly long enough to be an annoyance!

LibreOffice Calc (not responding) 480x270

You may recognize the symptoms:

  1. No matter how many times you press Enter you cannot advance out of the editing of this mystery cell
  2. When you do try a mouse click to any other cell in the sheet you can’t click away from that mystery cell
  3. The (not responding) message appears in the far left of the Window Title bar
  4. The X (for closing the application) in the far right of the Title Bar acquires a RED background
  5. The animated blue circle icon appears
  6. The entire window develops a translucent white fog
  7. You may even hear your computer’s fan kick in because something is going on and no … it really is not an unsolicited Windows Update running in the background. (… just for a change!)

After carefully peeling back the layers of the onion it became evident to me that I had carelessly defined a named Database Range to be an entire row where Headings of a very wide table were being created. It was a lazy, sloppy careless mistake and in the interim I have learned (just a little) more about the difference between a plain old Named Range of cells and a named Database Range.

The attached
Test case unresponsive.ods|attachment (34.4 KB)
file will walk you through step by step how to reproduce the careless error and experience the unresponsive behaviour.

I hope this helps someone else recover more quickly than I did from the same (or a similar) case of a (not responding) application.

Looking for a Libre expert in my postcode RG120XL (spreadsheet freezes constantly - having to recover it every session)
#3

You may want to file a bug report and attach the file there.

#4

No, I don’t think so. This is not a bug.
It is a user error that is very easy to make.

#5

Utter slowness and unresponsiveness usually is a bug.

#6

Yes. I understand the generalization.

There are 16,384 cells in one row of a Calc spreadsheet.
When a user sloppily defines an entire row as a Database Range they are probably oblivious to the fact that they have just added “Database hooks/baggage” to each of those 16,384 cells. (Descriptors, indices, whatever…)
So when Calc subsequently takes a long time to “refresh” such a database the several seconds of unresponsiveness is only unexpected because the user did not realize they had unwittingly created a database initially and then subsequently triggered a refresh (or whatever) of that unintended database.

:thinking: Could the UI prompt the user with some message like:
"Are you sure you want to make this range of cells a Database?"
"(Would a Named Range be just as effective?)"

… Yes, I suppose it could … but then such a prompt becomes an annoying nag screen for experienced users who understand the difference between a “Named Range” and a “Database Range with a name”.

So yeah, after reflection … maybe the UI should present such a confirmation prompt so long as a checkbox such as:
":white_square_button: Do not show this message again."
serves as a one-time-only annoyance for experienced users.

1 Like
#7

‘The document is NOT conformant ODF1.3!’.

#8

@mariosv … wow, 44 Errors! … is this common for documents created with the latest version of LO?

In other words:

  • What things might a user do to inadvertently cause a spreadsheet to become non-compliant?

In the case of this very simple test case you can follow along with the step by step instructions in that sheet to see how few edits were actually made to a new sheet.

  • spacer

Version: 7.5.3.2 (X86_64) / LibreOffice Community
Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3
CPU threads: 12; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: en-AU (en_AU); UI: en-GB
Calc: threaded

#9

OK so I am learning a little more each day!

Starting with a brand new Calc file I save a separate copy of the file after each of the following edits:

  1. (0 errors 0 warnings) New sheet - no edits, just a save
  2. (1 error 0 warnings) plain text entered into 5 cells
  3. (1 error 0 warnings) that range of 5 cells defined as a Database Range
  4. (2 error 0 warnings) copied those 5 cells to another 5 cells
  5. (2 error 0 warnings) the entire row containing the copied cells is defined as a Database Range

Given how trivial the above edits are I am inclined to speculate that:

  • the validator is throwing false negatives or
  • the latest release of LO is generating nonconforming files
#10

In Menu/Tools/Options/Load&Save/General - Default file format for ODF Settings
it’s possible to select other versions to save for test.

#11

Please make sure to chose ODF version correctly in the validator. Unfortunately, it doesn’t detect extended variant, which is the default for LibreOffice - so OASIS ODF 1.3 (extended conforming) is needed to be chosen manually. And it is conformant.

#12

Thank you … yes I see now that the test case is conformant.

#13

Duly noted.

#2

Solution not requested. Experience and resolution sharing only.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.