After switching to LibO from Oo, I have found that the "Open with.." Windows explorer shortcuts are not available for LibO. They are useful in places where Microsoft Office is installed and it is needed on occasion to open .DOC/.XLS/.PPT files using LibO.
@Michael Pappas Please attach a secreenshot with "shortcuts" and missing shortcuts, and information concerning your WIN version. Did you check all MS doc types during installation? I'ts a known problem that some MS document types currently will not be associated to WIN during installation.
Created attachment 53242 [details] open with openoffice writer shortcut (In reply to comment #1) > @Michael Pappas > Please attach a secreenshot with "shortcuts" and missing shortcuts, and > information concerning your WIN version. Deployed this 100+ Windows XP Pro 32-bit (Greek) SP3. Screenshot shows a system that has both MS Office and LibO 3.4.3 installed. I can not produce a screenshot with the shortcuts not missing in LibO. Instead, I have provided a screenie with Oo 3.3 that depicts that these shortcuts are not missing in Oo.Soecifically, you can see that for a MS Word file (.doc), apart from the default option to open the file with MS Word, an option is also given to open it with OpenOffice Writer. This option and the similar ones are the ones missing. > Did you check all MS doc types during installation? As I described in the original report, LibO is used alongside MS Office. I do *not* wish to associate LibO with .doc/.xls/.ppt files! Installation is performed via group policy, leaving REGISTER_ALL_MSO_TYPES to 0. When I had Oo (and not LibO), it did the following: * MS Office files remained associated with MS Office * selecting "Open With..." on a MS Office filetype from windows explorer displayed options to open the MS Office file (eg a .doc) with Openoffice Write. The latter does not happen in LibO 3.4.3
I understand. At least for me it's one of the few last big mysteries how WINDOWS decides what programs should be listed as "Alternative Editors" (or how you want to call it). It seems if I asked often enough WIN accepts my wish. I doubt that it's a bug, but it might be a nice feature (may be for an Extension). Let's gain some more knowledge first, I will ask on <discuss@documentfoundation.org>
(In reply to comment #3) > I understand. At least for me it's one of the few last big mysteries how > WINDOWS decides what programs should be listed as "Alternative Editors" (or how > you want to call it). It seems if I asked often enough WIN accepts my wish. Registry thing, if I understand correctly, see also this: http://www.howtogeek.com/howto/18119/remove-programs-from-open-with-menu-in-explorer/
This problem occurs when you have both LibreOffice and OpenOffice. Windows only shows OpenOffice because .exe have the same names in both.
(In reply to comment #5) > This problem occurs when you have both LibreOffice and OpenOffice. > Windows only shows OpenOffice because .exe have the same names in both. I don't have both of them installed. I either have MS Office and Oo, or MS Office and LibO.
Yes, I believe GerardF's comment describes an additional problem that is not relevant here. In this bug we only try to find a solution that LibO will be listed as alternative to MS-Office for MS-Office documents (but not as default program to edit those documents)?!
Hi Everyone, I think that it will be useful if we could also _set/unset_ *after installation* (from Tools -> Options menu -> Load/Save -> ..., of course) the following capabilities: - LibreOffice file associations (proprietary ones, Open Document ones); - LibreOffice file "open with" list for each file type. What do you think about? Have a nice day, Carlo
@Carlo Strata: Yes, of course, many other programs have an 'Options -> Set file type associations'.. But I believe that's a different Enhancement request. Can you check and if still unknown submit a Bug for that?
(In reply to comment #9) > @Carlo Strata: > Yes, of course, many other programs have an 'Options -> Set file type > associations'.. But I believe that's a different Enhancement request. Can you > check and if still unknown submit a Bug for that? Hi Rainer, yes sure I will do that within tomorrow. Have a nice evening, Carlo
@Rainer As well as I have promised I do: Bug 33784. I see my suggestion was already of others since 3.3.0 release and not only for Windows but also for MacOS X and Linux! ;-) Have a nice Sunday, Carlo
reproduced in LibO 3.5.0 beta 3 on Windows XP 32 bit docx, ppt, xls have no option Open with where LibreOffice mentioned
*** Bug 42129 has been marked as a duplicate of this bug. ***
Another interesting idea about this problem: Bug 44462 - Provide a proper 'File Association Manager' for the windows version of Libreoffice
No longer reproducible with "LibreOffice 3.6.6.2 release " German UI/ German Locale [Build-ID: f969faf] {pull date 2013-04-03} on German WIN7 Home Premium (64bit). I additionally have installed OOo 1.1.5 and OOo 2.0.3. Problem vanished or only my particular configuration?
(In reply to comment #15) > No longer reproducible with "LibreOffice 3.6.6.2 release " German UI/ > German Locale [Build-ID: f969faf] {pull date 2013-04-03} on German WIN7 Home > Premium (64bit). I additionally have installed OOo 1.1.5 and OOo 2.0.3. > > Problem vanished or only my particular configuration? I can verify your findings, problem is not reproducible here as well, with Greek LibreOffice 3.6.6.3 (build id: f969faf) on a Greek Windows 7 Pro SP1 32-bit installation. Feel free to close this bug report.
Of course the problem haven't gone anywhere. It will happen next time when the next version will install itself into "Libreoffice 4.1" folder.
*** Bug 62335 has been marked as a duplicate of this bug. ***
Yes, this is an issue. Yes, it is reproducible. Yes, it causes users serious frustration. Please sit back while I explain in detail. Firstly, the symptoms. On Windows, the context menu for files (ie the dialog received when right-clicking a file) has an `Open with` submenu which lists various programs Windows thinks you might want to open the file with. It also includes a `Choose program` option. If I'd like to open, for example, a comma separated values file with LibreOffice Calc but it is not on the submenu, I can choose `Choose program` and a dialog is provided whereby I can select from a list of programs or, if my desired program is not listed, I can navigate to the executable and hit `OK`. Now, normally navigating to a program adds it to the list, then I hit `OK` and the file is opened. However, after upgrading LibreOffice (or even switching from OpenOffice to LibreOffice) nothing will happen after I navigate to and select my desired executable; there is no error message and the program is not added to the list. Literally, nothing happens. Not only is this bewildering to most users... it's extremely frustrating too. OK, now the causes. The short explanation is that LibreOffice includes a version number in it's installation path (ie C:\Program Files\LibreOffice 3.5\program\scalc.exe). Why does that matter? Because Windows registers programs using only the executable name as the key in a variety of places and stores full paths as values; and, because the LO installer/uninstaller does not "clean up" those registry keys. This means after upgrading, say from 3.5 to 4.0, there is a bunch of registry keys with expired values (paths). To be fair, it's not really LO's responsibility to clean up the registry. Oh well. Because the executable name is the same as in the prior version, and keys already exist, Windows does not create new keys when a user performs an upgrade; nor does Windows overwrite/update the existing keys. These expired paths in existing keys are the root source of the symptoms described above: Windows launches the desired program based on the name of the executable the user selects (ignoring the actual path to that executable) and when the path returned via the registry is found invalid, Windows fails silently. Since this is a registry functionality issue, it can be expected to affect Windows users across the globe. I don't know with certainty but do have excellent reason to believe it is an issue on all versions of Windows in all languages. If you want to reproduce this issue, install an older version of LO in a clean VM then update to a newer version. Be sure to use default install paths or you might be cheating. Try to use the `Open with` menu before and after the upgrade. So how can it be fixed? The only successful way (that I know of yet) is to manually find and edit the erroneous registry keys. Searching the registry for the name of the installation folder of the previous version (say "LibreOffice 3.5") will work but that can still be difficult. For example, in fixing one machine, I had to look for "openoffice.org 3", "LibreOffice 3.4" and "LibreOffice 3.5". A more effective method might be to look for the name of the executable, say "scalc.exe". Unfortunately, this requires searching for each program included in LO (scalc.exe, swriter.exe, simpress.exe, soffice.exe, ...). What are some permanent solutions? The simplest by far would be for LO to stop including version numbers in the installation path. This simple step prevents paths in registry keys from 'expiring'. It has the minor drawback of complicating multiple LO installations (but what non-dev user does that anyway?). The larger drawback is that existing symptoms won't be remedied (!). The collary solution is to add version info to the executable name (say, "scalc40.exe" vs "scalc41.exe"). This isn't pretty IMO but it does force Windows to create new keys and, thus, maintain correct paths. A minor side benefit is that multiple installations could coexist peacefully (multiple 'LibreOffice Calc' entries could exist on the `Open with` list). Of course, it would be necessary to include version numbers in the program's display-name too so users can differentiate them on the `Open with` list. More complex alternatives might involve having the LO installer search for and update paths in the registry and the uninstaller find and remove such keys. Such solutions would also (hopefully) correct the problem for users currently experiencing it.
Would you please raise the priority for this bug? It's very annoying and has a severe impact on productivity.
It's not just an OOo to Lo upgrade problem. The system: Win7 with MS Office 2010 and LibreOffice 4.0 - LO 4.0 uninstall, restart, LO 4.1 install. During the installation LO does not set as default for MS documents and after the installation you cannot associate LO with MS documents. LO 4.1 uninstall, restart, LO 4.1 intall with MS ducument association and it works. LO 4.1 uninstall, restart, LO 4.1 install without association and again, you cannot associate with MS documents, so uninstall again and delete everything from registry which contains libreoffice, scalc, etc. After the installation, you can associate with MS documents. So it seems it does not matter which version you had before, if you intall LO 4.1 without MS document association, you cannot associate or "open with LO" later.
(In reply to comment #21) I'm talking about LibreOffice 4.1.2.3 for Windows.
Installer cannot do that, as Applications key is overridden by per-user settings. LO itself should check whether the current user's SOFFICE.EXE association points at the current executable each time.
tilus06, this bug isn't about setting LibreOffice programs as default editors for MS docs. It's about the 'Open with..' submenu of the file selection context menu (right-clicking a file) becoming unusable after an upgrade because of changes to the default installation path. It's fairly like the cause of this issue also mucks up file associations but that's speculation on my part. Urmas, the program names are used as keys in a variety of places, not just in the per-user settings. I want to say most are under HKLM but I don't have a winbox handy to check. It wouldn't help to have LO verify associations whenever it's launched because the major symptom of this bug is that LO never gets launched (Windows silently fails to locate the desired executable). The LO installer could search the entire registry for all instances of each exe (soffice.exe, scalc.exe, swriter.exe, ...) in either key or value, then for each instance found, check if the value is a path and if so verify/update the path to the new install destination. Using a static installation path across versions would save future users from this mess. Current users have to fix it manually; see paragraph 6 of comment #19.
It cannot 'search the registry' as some hives are physically not there during install.
Two Points: 1. NEW is correct status not REOPENED - moving to such; 2. I see "new requests" in the comments - those are entirely unhelpful and will be ignored. 1 report = 1 bug/enhancement request. For those who have requested additional things in comments, please report a separate issue. Thanks
** 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.0.4 or later) 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 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) http://downloadarchive.documentfoundation.org/libreoffice/old/ 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
Operating system: Windows 8.1 enterprise; LIBO v: 5.0.3.2 I did not experience the problem when moving from LIBO 4 to LIBO 5 under my previous Win 7 machine. I suspect that LIBO 5 was a virginal install on this 8.1 machine, but preceding sentence makes the fix "worksforme". All the best for 2016.