1. Make new impress presentation
2. Menu -> Insert -> Object -> OlE OBJECT
3. Create from file
4. Take *.txt or ods or odt... File
5. Check "Link to file"
6. Press Ok
7. Edit -> Links... (if window is open you see file is already marked)
8. BUT! Update: Automated Manual is gray / disabled to uses. Manual is checked and cannot be reched to Automated.
The result: Always when you open the Impress-Presentation new, a dialog annoys you that asks if you want to update the file!
On pc Debian x86-64 with master sources updated today, I could reproduce this.
I confirm bug under Win8.1 x64 with LibO 18.104.22.168
I tested it with older LibO releases too and it never worked.
The same behaviour is present in OOo 3.3.0 and AOO 4.1.0 as well.
so issue is "inherited from OOo"
Created attachment 119935 [details]
edit links dialog screenshot
cui/source/dialogs/linkdlg.cxx line 222
222 if( FILEOBJECT & pLink->GetObjType() )
227 if( OBJECT_CLIENT_GRF == pLink->GetObjType() )
228 pLinkNm = 0, pFilter = &sLink;
Some testing show we go into the if because:
1) #define FILEOBJECT ( OBJECT_CLIENT_FILE & ~OBJECT_CLIENT_SO )
2) pLink->GetObjType() returns 0x92 (which corresponds to OBJECT_CLIENT_OLE)
1) Should FILEOBJECT macro be changed to:
#define FILEOBJECT ( OBJECT_CLIENT_FILE & ~OBJECT_CLIENT_SO & ~OBJECT_CLIENT_OLE) ?
2) Should pLink be initialized as OBJECT_CLIENT_SO and not OBJECT_CLIENT_OLE ?
3) These kind of links shouldn't be "updateable" indeed and so there's no bug
Here are the different types:
50 #ifndef OBJECT_DDE_EXTERN
51 #define OBJECT_INTERN 0x00
52 //#define OBJECT_SO_EXTERN 0x01
53 #define OBJECT_DDE_EXTERN 0x02
56 #define OBJECT_CLIENT_SO 0x80 // a Link
57 #define OBJECT_CLIENT_DDE 0x81
58 //#define OBJECT_CLIENT_OLE 0x82 // a Ole-Link
59 //#define OBJECT_CLIENT_OLE_CACHE 0x83 // a Ole-Link with SvEmbeddedObject
60 #define OBJECT_CLIENT_FILE 0x90
61 #define OBJECT_CLIENT_GRF 0x91
62 #define OBJECT_CLIENT_OLE 0x92 // embedded link
Michael: any thoughts or any idea who may help here?
Thankyou for giving the site of the code!
It is really strange! On the one side a dialog box comes all the time for asking to update for objects which shouldnt be as here described updateable if I see so? (bug 95302)
On the other side: why to give this option if always a FILE-OBJECT is eliminated? I mean is there anyother object which has a Link which is no file and in conclusion not updateable? This sounds really silly to me.
I experimented a little and enabled the radio buttons artificially. What came out that its really PSEUDO. When you come back to the dialog when keeping the file open it doesnt forget if a Link should be updateable automatically or manual. But if you reload the file after you saved it, it forget those preferences. It seems, there is no implementation behind it?
Bug 95302 made the conclusion to only implement general settings. This bug here could come to the conclusion to either
(1) delete those radio-options described in this bug
(2) or that if in the Links-dialog are made different settings, it can overwrite the general Impress-settings
(3) Eliminating Automatic or Manual per file and summarize it for all files. Because should there be 10 dialog files at the beginning so ask each file yes or no? If in general there is manual, then you still can go to Links and click 'update' for each selected file
Which speaks for (1) eleminating the radios - is that it is most easy because bug 95302 can create the more easy solution.
If for every file it need to be stored wether to be updated or not it seems that the file standard has to be changed, does it? This would affect the compatibility to Microsoft Office and other office programs much more?
For example if I first edit in Impress. Then update something in Powerpoint. Would the update automatic/manual Information would go away? Cause then this is a minus to make the dialog links in the automatic/manual-update function really work...?
How the community thinks about it? Only general settings or also individual settings by this dialog box Links? Making those settings in Links finally work or to eliminate them because general settings are the more ergonomic solution?
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present on a currently supported version of LibreOffice
(5.1.6 or 5.2.3 https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and
your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave
a short comment that includes your version of LibreOffice and Operating System
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to "inherited from OOo";
4b. If the bug was not present in 3.3 - add "regression" to keyword
Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
duplicate of https://bugs.documentfoundation.org/show_bug.cgi?id=48294 ?
*** This bug has been marked as a duplicate of bug 48294 ***