When editing a DOC document with an OLE object done in Visio, it shows correctly but after primary double-clicking for edition it is not openned in Draw (Word and Visio are not installed). I'd expect the OLE diagram to be opened in Draw. Instead I get the following: Windows Server 2012 TS: LOO 4.1.3.x/4.1.4.2 "Error general de OLE." something like "OLE general error". Ubuntu 12.04: LOO 4.1.4.2 Chromium is opened and downloads a .tmp file from a local temporary file :)
Could you attach an example file so we can try to reproduce the problem?
Created attachment 91648 [details] Document to reproduce the problem reported This is a simple example
I confirm behaviour with version 4.2.0.2 on Windows7-64 (no MS Visio installed): General OLE error. On a machine which has MS Visio installed (LO version 4.2.0.2 on Windows 7-32) the OLE object opens correctly in MS Visio. Will try to produce stack-trace at moment of error message.
Created attachment 92260 [details] message with master on openSUSE Attached screenshot shows how master (on openSUSE 12.3) reacts when opening the OLE-object. (have not been able to produce a stack-trace of version 4.2.0.2 on Windows with winDbg - Symbol file could not be found...)
using gdb with master on openSUSE 13.1 produces the following backtrace when opening the OLE object (breakpoint set at first line of SfxFrameLoader_Impl::impl_handleCaughtError_nothrow() in /sfx2/source/view/frmload.cxx. (Hope this information helps) #0 SfxFrameLoader_Impl::impl_handleCaughtError_nothrow (this=0x7fffa82bb2b8, i_rCaughtError=..., i_rDescriptor=...) at /home/winfried/git/libo/sfx2/source/view/frmload.cxx:388 #1 0x00007ffff4ea2f4f in SfxFrameLoader_Impl::load (this=0x7fffa82bb2b8, rArgs=..., _rTargetFrame=...) at /home/winfried/git/libo/sfx2/source/view/frmload.cxx:627 #2 0x00007fffcf6bb47d in framework::LoadEnv::impl_loadContent (this=0x7fffffffb000) at /home/winfried/git/libo/framework/source/loadenv/loadenv.cxx:1184 #3 0x00007fffcf6b7a0f in framework::LoadEnv::startLoading (this=0x7fffffffb000) at /home/winfried/git/libo/framework/source/loadenv/loadenv.cxx:402 #4 0x00007fffcf6b6616 in framework::LoadEnv::loadComponentFromURL (xLoader=..., xContext=..., sURL=..., sTarget=..., nFlags=0, lArgs=...) at /home/winfried/git/libo/framework/source/loadenv/loadenv.cxx:173 #5 0x00007fffcf6f20b7 in framework::Desktop::loadComponentFromURL (this=0x7fffe063b530, sURL=..., sTargetFrameName=..., nSearchFlags=0, lArguments=...) at /home/winfried/git/libo/framework/source/services/desktop.cxx:616 #6 0x00007fffaafa5681 in OwnView_Impl::CreateModelFromURL (this=0x7fffb4056aa0, aFileURL=...) at /home/winfried/git/libo/embeddedobj/source/msole/ownview.cxx:147 #7 0x00007fffaafa5afe in OwnView_Impl::CreateModel (this=0x7fffb4056aa0, bUseNative=0 '\000') at /home/winfried/git/libo/embeddedobj/source/msole/ownview.cxx:186 #8 0x00007fffaafa7a38 in OwnView_Impl::Open (this=0x7fffb4056aa0) at /home/winfried/git/libo/embeddedobj/source/msole/ownview.cxx:518 #9 0x00007fffaaf89b6f in OleEmbeddedObject::doVerb (this=0x7fffc403a010, nVerbID=-9) at /home/winfried/git/libo/embeddedobj/source/msole/oleembed.cxx:866 #10 0x00007ffff4ea8712 in SfxInPlaceClient::DoVerb (this=0x26f55c0, nVerb=0) at /home/winfried/git/libo/sfx2/source/view/ipclient.cxx:947 #11 0x00007fffb53928b8 in SwWrtShell::LaunchOLEObj (this=0x15b0610, nVerb=0) at /home/winfried/git/libo/sw/source/ui/wrtsh/wrtsh1.cxx:586 #12 0x00007fffb51ae6ac in SwEditWin::MouseButtonDown (this=0x153d260, _rMEvt=...) at /home/winfried/git/libo/sw/source/ui/docvw/edtwin.cxx:3300 #13 0x00007ffff228095b in ImplHandleMouseEvent (pWindow=0x157f2d0, nSVEvent=1, bMouseLeave=0 '\000', nX=581, nY=405, nMsgTime=4833807, nCode=1, nMode=3) at /home/winfried/git/libo/vcl/source/window/winproc.cxx:780 #14 0x00007ffff228640e in ImplHandleSalMouseButtonDown (pWindow=0x157f2d0, pEvent=0x7fffffffc880) at /home/winfried/git/libo/vcl/source/window/winproc.cxx:2050 #15 0x00007ffff22853ca in ImplWindowFrameProc (pWindow=0x157f2d0, nEvent=3, pEvent=0x7fffffffc880) at /home/winfried/git/libo/vcl/source/window/winproc.cxx:2420 #16 0x00007fffe725f373 in SalFrame::CallCallback (this=0x15800d0, nEvent=3, pEvent=0x7fffffffc880) at /home/winfried/git/libo/vcl/inc/salframe.hxx:243 #17 0x00007fffe725b2f5 in GtkSalFrame::signalButton (pEvent=0x140a800, frame=0x15800d0) at /home/winfried/git/libo/vcl/unx/gtk/window/gtksalframe.cxx:3219 #18 0x00007fffe69a99d5 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #19 0x00007fffedd6a318 in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #20 0x00007fffedd7bcad in ?? () from /usr/lib64/libgobject-2.0.so.0 #21 0x00007fffedd83689 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #22 0x00007fffedd83c72 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #23 0x00007fffe6ab9864 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #24 0x00007fffe69a8184 in gtk_propagate_event () from /usr/lib64/libgtk-x11-2.0.so.0 #25 0x00007fffe69a853b in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0 #26 0x00007fffe6618a8c in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #27 0x00007fffedaa1316 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #28 0x00007fffedaa1668 in ?? () from /usr/lib64/libglib-2.0.so.0 #29 0x00007fffedaa170c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #30 0x00007fffe72206a5 in GtkData::Yield (this=0x62baf0, bWait=true, bHandleAllCurrentEvents=false) at /home/winfried/git/libo/vcl/unx/gtk/app/gtkdata.cxx:576 #31 0x00007fffe72246e0 in GtkInstance::Yield (this=0x62ba40, bWait=true, bHandleAllCurrentEvents=false) at /home/winfried/git/libo/vcl/unx/gtk/app/gtkinst.cxx:425 #32 0x00007ffff1ce9481 in ImplYield (i_bWait=true, i_bAllEvents=false) at /home/winfried/git/libo/vcl/source/app/svapp.cxx:364 #33 0x00007ffff1ce5bc5 in Application::Yield () at /home/winfried/git/libo/vcl/source/app/svapp.cxx:396 #34 0x00007ffff1ce5b75 in Application::Execute () at /home/winfried/git/libo/vcl/source/app/svapp.cxx:345 #35 0x00007ffff7871485 in desktop::Desktop::Main (this=0x7fffffffd920) at /home/winfried/git/libo/desktop/source/app/app.cxx:1709 #36 0x00007ffff1ceec3b in ImplSVMain () at /home/winfried/git/libo/vcl/source/app/svmain.cxx:160 #37 0x00007ffff1ceed45 in SVMain () at /home/winfried/git/libo/vcl/source/app/svmain.cxx:196 #38 0x00007ffff78b3201 in soffice_main () at /home/winfried/git/libo/desktop/source/app/sofficemain.cxx:85 #39 0x000000000040096c in sal_main () at /home/winfried/git/libo/desktop/source/app/main.c:48 #40 0x000000000040094d in main (argc=1, argv=0x7fffffffdc08)
Created attachment 93041 [details] odt-document with embedded visio objects Problem also occurs with version 4.2.0.3 and odt-document with embedded Visio-object, which is a regression.
broken in 4.1.0.4 already
Could this bug be related to bug 64265?
I don't think so, I'd be happy with the bug 64265 behaviour in this bug. I want to be able to edit an embedded Visio object with Draw (there is no Visio installed) :) Thanks On 03/02/14 08:17, bugzilla-daemon@freedesktop.org wrote: > > *Comment # 8 <https://bugs.freedesktop.org/show_bug.cgi?id=73363#c8> > on bug 73363 <https://bugs.freedesktop.org/show_bug.cgi?id=73363> from > Winfried Donkers <mailto:winfrieddonkers@libreoffice.org> * > Could this bug be related tobug 64265 <show_bug.cgi?id=64265>? > ------------------------------------------------------------------------ > You are receiving this mail because: > > * You reported the bug. >
(In reply to comment #9) > I don't think so, I'd be happy with the bug 64265 behaviour in this bug. > I want to be able to edit an embedded Visio object with Draw (there is > no Visio installed) :) Hi Eneko, What I mean is this: - in bug 73363 an embedded Visio object is not opened in Draw when Visio is not installed and - in bug 64265 an embedded Visio object (embedded is a certain way) is not opened in Visio when Vision _is_ installed. The common factor is that the expected application (Draw respectively Visio) is not 'found' to open the object. And I'm quite certain that you will not be happy with the bug 64265 behaviour when you have Visio installed ;)
*Comment # 10 <https://bugs.freedesktop.org/show_bug.cgi?id=73363#c10> on bug 73363 <https://bugs.freedesktop.org/show_bug.cgi?id=73363> from Winfried Donkers <mailto:winfrieddonkers@libreoffice.org> * > (In reply tocomment #9 <show_bug.cgi?id=73363#c9>) > > I don't think so, I'd be happy with thebug 64265 <show_bug.cgi?id=64265> behaviour in this bug. > > I want to be able to edit an embedded Visio object with Draw (there is > > no Visio installed) :) > > Hi Eneko, > What I mean is this: > - inbug 73363 <show_bug.cgi?id=73363> an embedded Visio object is not opened in Draw when Visio is not > installed > and > - inbug 64265 <show_bug.cgi?id=64265> an embedded Visio object (embedded is a certain way) is not > opened in Visio when Vision _is_ installed. > > The common factor is that the expected application (Draw respectively Visio) is > not 'found' to open the object. > > And I'm quite certain that you will not be happy with thebug 64265 <show_bug.cgi?id=64265> behaviour > when you have Visio installed ;) Hi Winfried, I understand that they may be related, it seems there's a problem with the OLE handling; from what I have read it seems a problem registering the OLE handlers but I don't have the LibreOffice code knowledge to say whether it's the same bug or not. I think it'd be good to debug both problems together, though. BTW, my goal is not to have MS Office installed ;)
ee53857e984fea54b7dc08b99079b38766f0b796..153621f98ee98e4eacaebcf7d62f74d54755cab6 regression from: commit 1a3c7b84b7b22109d691a770649af42c1033d709 Author: Kohei Yoshida <kohei.yoshida@gmail.com> AuthorDate: Wed Mar 6 02:00:02 2013 -0500 Test all file format types regardless of document services. The old type detection would only test file format types that are relevant to the current document service. But this would not work if the user tries to open an Excel document whose name ends with a non-default extension (such as .tmp) from Writer UI. To amend this, we need to test all possible format types that are supported by all our modules regardless of the current module, but prioritize them per current module. TODO: The above scenario doesn't work yet. I still need to fix the individual type detection services to get it to work. unfortunately the filter detection for PPT happened to be borked, fixed on master.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e62339f856efa0b8ef03df3bf8b93e098c4ac0d3 fdo#73363: sd: fix mis-detection of Visio files as PPT The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3bb16f0eeb7fc8fe0331e0aa11f65e2114928d09&h=libreoffice-4-1 fdo#73363: sd: fix mis-detection of Visio files as PPT It will be available in LibreOffice 4.1.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6a6e61368f252c24bb761417b78dceb9b7dea210&h=libreoffice-4-2 fdo#73363: sd: fix mis-detection of Visio files as PPT It will be available in LibreOffice 4.2.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Fix works as expected with Ubuntu 12.04: LOO 4.2.4.2