Bug 130945 - Writer: Preview of linked doc is not updated when edited
Summary: Writer: Preview of linked doc is not updated when edited
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Serge Krot (CIB)
URL:
Whiteboard: target:7.0.0 target:6.4.3
Keywords:
Depends on:
Blocks: OLE-Objects
  Show dependency treegraph
 
Reported: 2020-02-26 07:39 UTC by Serge Krot (CIB)
Modified: 2021-07-30 20:06 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Serge Krot (CIB) 2020-02-26 07:39:11 UTC
How to reproduce:
1.    create new calc file and enter some Numbers and save and close this file
2.    create new writer file and insert -> object -> OLE-object
3.    select create from file and select calc sheet of step one
4.    select "link to file"
5.    press ok
6.    edit the table in the writer document (change value of A1 cell)
7.    select a new cell (A2)
8.    click outside the table in the writer document
9.    in writer old preview image is used
Comment 1 Commit Notification 2020-03-02 00:39:56 UTC
Serge Krot committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/53735aeb937d7f2c1ac5bc0227e4a2fdc24e4947

tdf#130945 Writer: Preview of linked doc is not updated when edited

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 2 Commit Notification 2020-03-02 23:52:45 UTC
Serge Krot committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/b221b09739616a3776800b9784f82ec6b747a0dc

tdf#130945 Writer: Preview of linked doc is not updated when edited

It will be available in 6.4.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 3 BogdanB 2020-05-10 12:15:09 UTC
Everything now is ok.

Verified on
Version: 7.0.0.0.alpha1
Build ID: 6a03b2a54143a9bc0c6d4c7f1...
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 4 Armin Le Grand (allotropia) 2021-04-01 09:44:15 UTC
There are three aspects here:
(1) Display not updated when edited/deactivated -> fixed with commits

(2) Linked OLE gets modified independent from hosting document. In other words: When embedding a linked OLE, activating & changing it (also possible: activate & change size), deactivating, the OLE gets modified. This is not very intuitive from user's view and even not very logic when the hosting file (e.g. a new writer file) gets not saved itself. It would be much better to *synchronize* changes to the linked OLE to changes/svaing of the file/document the OLE is embedded to. Example:
- new Writer
- insert prepared calc OLE embedded
- activate it, change someting
- deactivate
- close Writer document without saving it
Result: prepared calc OLE is changed
Expected result: prepared calc OLE is *not* changed
-> A fix would need to couple saving of changed embedded OLEs to saving the hosing document

(3) A prepared OLE might be opened by two running instances of LO at the same time. In this scenario (besides also (2) creates irritation here) it is non-deterministic who's change gets applied. This depends on which instance of LO deactivates the shared OLE first (or with (2) fixed, who saves the hosting document first).
A fix of this would need to evtl. check when inserting the shared linked OLE if it is opened already by another instance, or - alternatively - check on save/deactivate and evtl. ask user if he wants to discard or copy the OLE - something like that, details need discussion.

All in all: Not all aspects are fixed here. I think about re-opening this task for (2) and (3), but it would also be possible to create new tasks for these...
Comment 5 Armin Le Grand (allotropia) 2021-04-06 09:07:57 UTC
While fixing (2) I stumbled upon 'break link' that also needs to be adapted. I thought my adaption does something wrong, but it seems broken on current master, too:

- create calc testfile with some content (a), save, close
- create writer, insert/Object/Ole-Object...
- create from file, choose (a), activate 'link from file' -> ok
- edit/link to external files...
- break link -> yes, close dialog
- activate OLE, change something, deactivate
- close writer, do not save
-> calc testfile (a) is modified -> error
This should *not* happen, the embedded OLE should be modified from now on.

Even when you *save* the writer, close, reload it asks for *updating* the contained links -> breaking link to OLE *is* broken.

ARGH. So to fix (2) I'll also have to fix this 1st - sigh...
Comment 6 Armin Le Grand (allotropia) 2021-04-06 16:21:02 UTC
Found out that m_xDocHolder used in OCommonEmbeddedObject::breakLink to call setModified *is* set when the document is already saved, so replacing above step

- create writer, insert/Object/Ole-Object...

with

- create writer, save it
- insert/Object/Ole-Object...

may make a difference - checking...
Comment 7 Armin Le Grand (allotropia) 2021-04-07 07:35:27 UTC
Opened/Created tdf#141528 now for Comment 5, grepped, on it...
Comment 8 Armin Le Grand (allotropia) 2021-04-07 07:40:56 UTC
Opened/Created tdf#141529 now for Comment 4, aspect (2), grepped, on it...
Comment 9 Armin Le Grand (allotropia) 2021-04-07 07:44:58 UTC
Opened/Created tdf#141530 now for Comment 4, aspect (3), grepped.
Comment 10 Armin Le Grand (allotropia) 2021-04-07 14:47:40 UTC
With the added tasks (see notes last three comments) this one can stay closed and fixed.