Steps to reproduce: (O/S Windows, MS Visio installed) 1. open/create Writer document 2. Insert - Object - OLE object - create from file 3. find - select visio file - OK 4. An object is inserted in the Writer document 5. double-click on the object to edit hte object 6. The LibreOffice image editor is activated expected behaviour: the object is opened by MS Visio for editing. Note: LibreOffice versions prior to 4.0.3 behave diferent. See bug 59405 for history.
Fridrich: I don't have Visio and don't know if Visio should indeed be used for edition. Any idea?
(In reply to comment #1) > Fridrich: I don't have Visio and don't know if Visio should indeed be used > for edition. Any idea? Julien, please have a look at bug 59405 (regression), from which this bug originates. Editing visio-objects with visio is a 'standard' behaviour from before LibreOffice started. With version 4 some regresssion occurred with visio-objects. Most have been solved, but this one is still open. Fridrich, excuse me for answering the question before you do, but I think I know the answer and so can help Julien.
Problem still present with version 4.2.0.2 on Windows 7
cannot reproduce this problem with 4.2.3.3 or master... OleComponent::LoadEmbeddedObject() just calls Win32 OleLoad(), and that's what determines which component is going to handle the OLE object, via the registry entries. OleComponent::RunObject() just calls OleRun(). there is code in setup_native/source/win32/customactions/reg4allmsdoc/reg4allmsi.cxx to create registry entries to associate Visio files with LO; presumably the problem is caused by these entries over-writing the entries that Visio itself creates. in my test i've installed Visio 2007 after installing LO, which would explain why i don't see the problem, presumably Visio will over-write all its entries. am not quite sure if it's possible to selectively disable/enable LO's registration for particular MSO document types; clearly all of it can be disabled with REGISTER_NO_MSO_TYPES... ah it checks also SELECT_WORD, SELECT_EXCEL, SELECT_POWERPOINT, SELECT_VISIO.... so i guess you can specify the SELECT_VISIO property when installing with msiexec to disable LO registration for Visio types. Andras, do we already check that we don't over-write existing entries in the registry when installing? in summary, not sure if there is a bug here at all.
(In reply to comment #4) I can reproduce the problem with version 4.2.4.2 on Windows7 (Dutch), with Visio 2007 installed after LO was installed, by following the steps in comment #1. There are various ways to import a Visio object in a Writer document and when editing the object, Visio is opened, _except_ when using the the way described in comment #1. This plus the fact hat it worked fine before version 4.0 makes me believe it is a bug and even regression.
ah sorry missed that it works in all other cases except for "Insert->Object->OLE Object->Create from file..." so i didn't test that one... yes "Create from file" does result in an OLE that opens only in Draw. but actually, is that wrong? the object gets a ClassID from a list in officecfg/registry/data/org/openoffice/Office/Embedding.xcu that list types such as "%PRODUCTNAME %PRODUCTVERSION Chart" "%PRODUCTNAME %PRODUCTVERSION Drawing" etc. i.e. it does _not_ list file types, but it lists *applications*. [so what i wrote about file type registrations in comment #4 is mostly irrelevant, or perhaps it only becomes relevant if the OLE object cannot be instantiated by OLE itself because the Class-ID of the object is not in the registry; there are a couple fall-backs for that case anyway...] reading a bit more on this, as i understand it the point of OLE is that an object opens in the same application that created it, and if you use "Create from file" then it is LO that creates the object; you can also only create objects for formats that LO can import via this mechanism, not anything that any application on your system could create as OLE. [oh, and don't try to insert an MP3 file as OLE via this method, Writer imports it as ASCII and takes a long time to layout it...] _but_, now i notice there's another way tp do it, that ends up in OleComponent::CreateObjectFromFile(), which calls Win32 OleCreateFromFile(), and that does exactly what you want! you can reach that from "Insert OLE object" dialog by "Create new", then click "Further objects", a dialog "Insert Object" pops up that again has "Create new" _and_ "Create from file" options! Apparently the "Insert OLE object" dialog is generic and available on all platforms, while the "Insert Object" dialog uses the "real" OLE and is only available on Windows. i think we need both ways to do it on Windows, since you may want to create OLE objects from files that are non-native to LO and for which you don't have the editing application installed... but the current UI is quite confusing. anyway, it looks to me there's not really a regression here?
(In reply to comment #6) > i think we need both ways to do it on Windows, since you may > want to create OLE objects from files that are non-native > to LO and for which you don't have the editing application > installed... but the current UI is quite confusing. > > anyway, it looks to me there's not really a regression here? A very informative comment, thank you. Being 1) a developer (though not of writer) and 2) a sort of spokesman for the users of the company I work for, this is a difficult one. The users our company that use Visio to make all sort of graphics in writer documents simply say that a) it worked with version 3 and no longer works with version 4 and b) the insert-object-OLE object-create new/other object-use file needs more actions than insert-object-OLE object-use file and so is inconvenient. a) made me to add regression b) is correct from a user's POV, especially as the difference between the 2, which took you a lot of lines to explain ;-), is totally invisible to users. I tend to call this bug report resolved for developers, but new for help text writers (is that a different mailing list?).
so i've tried it with LO 3.5.7 (with Visio filter) and 3.4.6 (without Visio filter). in 3.5.7 it works in the same way as 4.2. 3.4.6 will pop up a dialog to select the filter, since it can't read the file, and if you click "Cancel" it will fall-back to using OleCreateFromFile. so if anything it changed in 3.5. clearly the UI could use some improvement, it's all very confusing.
(In reply to comment #8) > clearly the UI could use some improvement, it's all very confusing. Would it be better to change the component to Documentation (or UI)?
*** Bug 82003 has been marked as a duplicate of this bug. ***
With respect, it is not possible to open the link to the bug referred to - message = server not found! ------ Original Message ------ From: bugzilla-daemon@freedesktop.org To: tim@timstone.com Sent: 02/08/2014 08:07:47 Subject: [Bug 64265] Inserted Visio object cannot be edited with Visio >Julien Nabetchanged bug 64265 >WhatRemovedAddedCC tim@timstone.com > >Comment # 10 on bug 64265 from Julien Nabet >*** Bug 82003 has been marked as a duplicate of this bug. *** >-------------------------------------------------------------------------------- >You are receiving this mail because:You are on the CC list for the bug.
Tim: I don't understand, what link are you trying to open. (please don't answer directly from your emailer but from Bugilla by using this link for example: https://bugs.freedesktop.org/show_bug.cgi?id=64265#)
Hi Julien, sorry about using my emailer, (new to this). Anyway, the problem seems to be that Visio has no way to open any of the files that Libre saves. This is possibly an industry standards problem rather than a Visio/Libre problem. I use Visio as it is a fairly easy drawing (to scale) program for woodwork projects and garden design. I have tried Turbocad etc and they are way too complex for quick and accurate small projects (huge learning curves). I have as yet not gone deeply into Libre's drawing program (sometime later today hopefully). So unless the drawing program writers come up with the equivalent of a JPEG standard for saving and swapping drawings I see no end to this particular problem, I would therefore hesitate to actually call this particular problem a Libre bug to be honest.
Tim: thank you for your feedback. It seems to me now that I was wrong and fdo#82003, I'll reopen this last one. Winfried/Michael: could it help a bit to add vsdx+vstx in g_Extensions from setup_native/source/win32/customactions/reg4allmsdoc/reg4allmsi.cxx?
so i think we came to the conclusion that this is not really a bug; it was and still is possible to do what the users want (insert a native Win32 OLE2 Visio object) but the UI is just really bad. so i'll close this "regression" bug, and file a new one strictly about the bad UI.