See topic.
If anyone knows this for sure, it would help me avoid a lot of testing.
Thanks for the tip.
But I think I’m too old to jump into the hustle and bustle.
IIUC, there should be only one guaranteed such an event: .uno:CalculateHard (Data → Calculate → Recalculate Hard (Ctrl+Shift+F9)).
When opening a document, and there is no setting for that document type to avoid full recalculation (Options → Calc → Formula), then full recalc would also happen there.
For all other cases, there should not be full recalculations. Even when they happen, these should not be relied upon, because there will likely be an effort to optimize these away. Only some affected subset of data must be recalculated, whenever a change occurs.
1 Like
I had mainly in mind the document-related events listed in the dialog under >Tools>Customise>>Events.
I looked for a way to block an UDF-based recalculation if insufficient readiness of the calc-document containing the calling formula must be expected.
The idea was to write date-time to global variables of the documnert’s Standard library for Basic code by one or more event handlers. I would name as candidates:
onOpenDocument
onDocumentLoadingFinished
onViewCreated
(possibly also onActivateDocument)
…
and the to check for an existing value and (depending) compare it…
IMO, we should by default consider “not ready” document for the macro purposes to be a bug. We need separate bugs for each of “this code, bound to this document event, fails for this document”; the hope is, that in most cases, we could fix that. An alternative solution would be to find out why the limitation exist, and which specific limitation that is; and documenting it in the API documentation - so that, e.g., it is known that “a, b, c may not be available at the moment when the event is processed”.
Sorry that I can’t answer your question directly.