Description: In the latest versions of updates, starting from 7.5.3, an error has appeared activating the OLE object. Steps to Reproduce: 1.Open the DB_news file 2.In the "Forms" bookmarks, open the "Form" form 3.The built-in OLE object "Object1" does not open. Actual Results: The built-in OLE object "Object1" does not open. Expected Results: The embedded Calc table should open in the OLE object's inset. Reproducible: Always User Profile Reset: Yes Additional Info: Before the 7.5.3 update, the OLE object opened normally. In the subsequent version 7.5.4, the problem persisted.
Created attachment 187800 [details] Demo files - DB_new demo file, - document scan in version 7.5.2 - document scans in version 7.5.3 with error
- Download Demo zip files. - Unzip the archive to any convenient location. - Run the DB_new file. - Enter the "Forms" bookmarks. - Launch the form "Form".
It is a pity that so far none of the developers have paid attention to this error. My five-year work is based on using the capabilities of OLE attachments and five programs and databases have been written. It will be a pity if this error persists in the future and the possibility of using OLE attachments in Base forms will be impossible.
The database file need macros, which aren't content of the package. So the form and Base will hang when trying to close it. So I have to kill LO every time Calc document (inside the Base form) will open … The Calc document will appear in LO 7.4.6.2 and earlier, won't appear in LO 7.4.7.2. Calc document will also appear in LO 7.5.2.2 and earlier 7.5., won't appear since LO 7.5.3.2 Tested here with OpenSUSE 15.4 64bit rpm Linux.
Created attachment 187947 [details] Corrections Sorry. I completely forgot to disable the attached macro. Fixed it. In the latest version of LO 7.5.4.2, the Calc file does not open. If you click on the puzzle symbol (select an OLE object), and then enter Edit / OLE Object / Edit in the menu, an error is displayed: Error activating object: General OLE error.
Created attachment 187948 [details] Demo files
This seems to have begun at the below commit in bibisect repository/OS linux-64-7.6. Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one? Thanks 4633fe2e703ec66a040028e11c6660e93249243c is the first bad commit commit 4633fe2e703ec66a040028e11c6660e93249243c Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu Apr 13 16:55:51 2023 +0200 source 52aa46468531918eabfa2031dedf50377ae72cf7 149971: query getUserAllowsLinkUpdate for the case of content in a floating frame | https://gerrit.libreoffice.org/c/core/+/149971
Created attachment 187958 [details] Demo files I used division in half to search for regression from version LO 7.5. to version LO 7.6 I got this result: kadet@Andrey MINGW64 /d/libo/win64-7.6 ((85bff399f...)|BISECTING) $ git bisect bad 85bff399f401b72ff6ca13c6ecd6624a0b1e636a is the first bad commit commit 85bff399f401b72ff6ca13c6ecd6624a0b1e636a Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Thu Apr 13 09:19:15 2023 -0700 source 52aa46468531918eabfa2031dedf50377ae72cf7 source 52aa46468531918eabfa2031dedf50377ae72cf7 instdir/program/setup.ini | 2 +- instdir/program/sfxlo.dll | Bin 5693440 -> 5693440 bytes instdir/program/version.ini | 2 +- 3 files changed, 2 insertions(+), 2 deletions(-) kadet@Andrey MINGW64 /d/libo/win64-7.6 ((85bff399f...)|BISECTING)
Used bisect to search for regressions from version LO 7.4 to version LO 7.5 I didn't find any errors. The Ole in the OLE object opens
A database with a writer-based report in it with a floating frame in that with a non-file-url target but instead private:factory/scalc to get a spreadsheet into it. I don't think the UI even offers that last option, cunning to find that possibility in the first place
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e55a1ca02b281d8a841361c1315b7e0ee7d75119 Resolves: tdf#155750 allow private:factory urls in floating frames It will be available in 24.2.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.
allowed in trunk again, backports to 7-6 and 7-5 in gerrit
Thanks
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/b8129f3df425b879a63239b35845b741ccc34dc3 Resolves: tdf#155750 allow private:factory urls in floating frames It will be available in 7.5.5. 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/cdf4efb4ca8f4ad5d982e5acef3aaba2c8678010 Resolves: tdf#155750 allow private:factory urls in floating frames It will be available in 7.6.0.0.beta2. 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.
Created attachment 188571 [details] Demo files Unpack the archive where it is convenient. File Figures.jpg put in a folder - C:\Users\Public\ Files LO_7_5_2_x.jpg - they show how it should be. Files LO_7_5_5_x.jpg - show how it is done in LO 7.5.5 (the latest available version). I think that in LO 7.5.5 the problem is not completely solved. - In LO 7.5.5, the file attached to the frame does not open Figures.jpg (examples LO_7_5_2_1.jpg, LO_7_5_5_1.jpg, LO_7_5_5_2.jpg). To check: run the DB_new 1.odb file and open the Form1 form; - In LO 7.5.5, OLE-frames do not hold relative sizes. (examples LO_7_5_2_2.jpg , LO_7_5_5_3.jpg , LO_7_5_5_4.jpg ). To check: run the DB_new 1.odb file and open the Form or Form1 form;
The relative sizes of OLE-frames are not fixed. It is incorrectly set relative to the page size.
Tested the LO_7_6_0_2 version. The problem with the size of the frame and loading the file into the frame persists.
Created attachment 189207 [details] Demo file Fixed the errors. Required non-existent macros. The Figures.odt file needs to be copied to the folder: C:\Users\Public
Created attachment 189223 [details] DB with a ref in a form This bug, titled "Error activating object General OLE error, private:factory/scalc as floating frame target", is rightfully RESOLVED FIXED, because the *private:factory/scalc* embedding works now. Initially, the title/summary was simply "Error activating object General OLE error"; but as the developer chose to narrow the issue, the rest needs to be filed and tracked separately. The new attachment here has the correctly sanitized sample, with all the images, events removed, the referenced document created from scratch to not distract with unnecessary stuff, and the reference to point to the same directory as the database file: "The Figures.odt file needs to be copied to the folder: C:\Users\Public" was wrong, because the old reference was relative, and would e.g. look at "D:\Downloads\Public" in my case, and would point completely elsewhere on e.g. Linux. The Form1 in the database, when opened in 7.6 and master, does not show the content of the left-hand OLE frame, which references the 'ref.odt' that should be next to the 'bd_with_ref.odb'; while the right frame opens the new Calc sub-document, using the 'private:factory/scalc' ref. The problem is the same - that 52aa46468531918eabfa2031dedf50377ae72cf7 disallows to open the link, while the form has no way to ask/confirm the loading of external links, and there is no honoring of security settings' trusted locations. In general, handling this is very inconsistent in different modules - e.g., sc does that in ScDocShell::SetInitialLinkUpdate, which calls GetLinkUpdateModeState, and considers many different things; other modules do much simpler job, like sd in DrawDocShell::Load, and sw in SwDocShell::Load, simply disallowing loading unconditionally. There's nothing base-specific in the codebase.
Thanks!