Problem decription: Since Microsoft Office 2010 is being widely deployed in many offices, a particular problem comes up regarding all ODF-file formats. At installation, MS Office 2010 registers itself as default programmes for ODF-file formats. However, they do not fully support the ODF standard. This is a particular problem with Excel, since it can open .ods files, but cannot save formulas. The changed and returned document is simply *useless* if the changes have been done in MS Office. Almost always, the respective persons had OpenOffice/LibreOffice installed on their computer, but they were opening the file with a double click (which opened MS Office and not LO).
The ultimate result is that *the ODF file formats cannot be used anymore in data exchange*. In my opinion, this is a severe issue.
Request / Solution: Please add an automatic check at start-up of LibreOffice, to check whether LO is the default programme for all ODF file formats and give the user the option re-register LO as default programme.
Thanks for new idea. In short:
Needed option something like "Make LibreOffice default program for odf files" that appears only if odf files (odt, ods, odp) assigned to another program.
Thanks Sasha, that's the perfect short summary.
I am almost inclined to increase the importance from medium to high, because the probem very frequently occurs that people send me back in-Office-2010-changed-and-almost-destroyed files, although these people have LibreOffice installed.
What do You think about this feature?
(In reply to comment #3)
> @ Andras
> What do You think about this feature?
Good idea, but I don't think I'll have time to implement it in the next few weeks. It should be hard, we could insert a Windows-only code somewhere at startup, that pops up a dialog, like e.g. Firefox does when it is not the default browser.
| LibreOffice detected that it is not the default handler of |
| OpenDocument file format. Would you like to restore file |
| associatiatons? |
| [ ] Do not ask again. |
| [Yes] [No] |
Startup code is in desktop module. I can mentor this easy hack.
Dear developers, dear Andras,
I really don't want to get on anybody's nerves ;-) when reiterating the importance of this enhancement.
The fact that a double-click on ODF files opens MS Office instead of LibreOffice on Windows already screwed up many ODF documents here and always results in lots of extra-editing work. Although I know that all my counterparts have LibreOffice or OpenOffice installed, I must revert back to send them .doc and .xls to not generate problems for myself.
If such a feature were there, I would only tell them to do once Open With -> LibreOffice and that would restore the file associations correctly.
Thanks a lot!
Please, can anyone look into this enhancement request? Today, I lost again a few hours of work, because someone opened the Calc file that I had sent him by double-clicking on it in Excel. Excel 2010, of course, destroyed all formulas in the file.
LibreOffice is installed on his computer and is also frequently used by him, but Microsoft Office took over the ODF file formats / Mime types. This move by Microsoft is a major threat to the success of ODF!
Thanks in advance!
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.
see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Migrating Whiteboard tags to Keywords: (easyHack, difficultyBeginner, skillCpp)
I would like to work on this.
Please help me through this. I did a bit of searching and found that it can be done by adding registry entry. http://stackoverflow.com/questions/1387769/create-registry-entry-to-associate-file-extension-with-application-in-c
I need some assistance in where exactly I should add this code to registry modification.
Thank you :)
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC)
I would like to know if someone is already working for the bug.If not, I would like to work on this as a project.
I can't confirm this, as I don't have MS Office. Does this problem still exist? Can we have some code pointers? Comment 9 does help a little, but still, we need code pointers. From what I see this bugs look pretty important.
You need to display a modal dialog at application startup. See how to display a modal dialog at desktop/source/app/cmdlinehelp.cxx. I think you can insert your code after CheckFirstRun( ); at desktop/source/app/app.cxx. You need to test your code from Windows XP SP3 to Windows 10. File associations may work differently.
@Andras, that helps a lot. Can you also tell me the way to generate that "cmdlinehelp.cxx" modal box inside LO, so that I can relate to things visually. Thanks.
change status to ASSIGNED
(In reply to abhilash300singh from comment #14)
> @Andras, that helps a lot. Can you also tell me the way to generate that
> "cmdlinehelp.cxx" modal box inside LO, so that I can relate to things
> visually. Thanks.
On Windows only:
I'm leaving this because I can't get LO to build on Windows. I've tried several times following the wiki, but some problem always seems to pop up. I might try this in future.
I would like to take up this task. But I am a beginner, and may need some help regarding this. Please let me know if you are willing to do so.
Thanks in advance!
i would like to work n this as my first easy hack.. wish me luck :)
(In reply to Fady Essam from comment #20)
> i would like to work n this as my first easy hack.. wish me luck :)
Thanks for working on this issue.
In case you have any question, please use the IRC channel #libreoffice-dev on freenode
Fady found this and shared on IRC: https://social.msdn.microsoft.com/Forums/office/en-US/b3146d10-4923-48ba-9578-ecd239356be4/how-to-programmatically-set-file-associations-in-windows-10?forum=windowsgeneraldevelopmentissues
There is nothing we can do, so closing.
Correct status would be CANTFIX
I felt free to reset this bug to NEW.
This information in a Microsoft forum does not seem to me to proof that setting file type associations by applications are impossible starting with MS Windows 8.
I have several questions doubting this statement in the Microsoft Forum:
(1) Is the LibreOffice installation tool able to associate ODF files with LibreOffice? I think the answer is yes.
(2) Does the bug still exist on Windows 10? Can anyone reproduce the issue that MS Office registers itself for ODF file types (and unregisters existing file associations of LibreOffice for ODF file types)?
(3) If the answer is "yes" to (1) and (2), then there must be a programmatic solution to this bug.
(In reply to Gerry from comment #23)
> I felt free to reset this bug to NEW.
> This information in a Microsoft forum does not seem to me to proof that
> setting file type associations by applications are impossible starting with
> MS Windows 8.
> I have several questions doubting this statement in the Microsoft Forum:
> (1) Is the LibreOffice installation tool able to associate ODF files with
> LibreOffice? I think the answer is yes.
> (2) Does the bug still exist on Windows 10? Can anyone reproduce the issue
> that MS Office registers itself for ODF file types (and unregisters existing
> file associations of LibreOffice for ODF file types)?
> (3) If the answer is "yes" to (1) and (2), then there must be a programmatic
> solution to this bug.
yes it can be set programatically during installation but as far as i know not after that.. for the last 2 days i have attempted to do it and everytime i write over the extention registery in HKEY_CURRENT_USER the windows wrtes back its default over it (windows 10)
(In reply to Gerry from comment #23)
> I felt free to reset this bug to NEW.
Yeah, so from that link, it should still be possible to assign another application - by calling IApplicationAssociationRegistrationUI::LaunchAdvancedAssociationUI (which requires the user to sign-off on that action)
A polite ping, still working on this bug?
Dear Fady Essam,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.
(In reply to Thorsten Behrens (CIB) from comment #25)
> (In reply to Gerry from comment #23)
> > I felt free to reset this bug to NEW.
> Yeah, so from that link, it should still be possible to assign another
> application - by calling
> IApplicationAssociationRegistrationUI::LaunchAdvancedAssociationUI (which
> requires the user to sign-off on that action)
This won't work on windows 10 as it stats-
"Starting in Windows 10, this does not launch the association dialog box. It displays a dialog to the user informing them that they can change the default programs used to open file extensions in their Settings"
Assigning to myself. Looks like the defaults to ask the user about are .ods, .odp, and .odt, so will check those.
> The way that default file associations work changed in Windows 10. For more
> information, see the section on Changes to how Windows 10 handles default
> apps in this post
From the referenced post:
> With Windows 10, all apps – both Classic Windows apps and Universal Windows
> apps – will be unable to invoke a prompt to change your defaults, only Windows.
> You remain in full control of your default experiences, while reducing some
> of the unwanted noise that multiple prompts can bring.
> So the prompt is shown in context when it matters, not randomly during setup
> or **when an app is launched**.
Note the last line there (emphasis is mine)! Implementing this clearly means working against the system.
I closed this once in 2018 and now closing again. Hopefully Gerry will believe Mike.
@Mike Kaganski @Buovjaga @Matt K:
(In reply to Mike Kaganski from comment #41)
> Note the last line there (emphasis is mine)! Implementing this clearly means
> working against the system.
Thanks for looking into this issue of default application setting.
The conclusion, which you take from the information on the Microsoft website, does not make sense, though. Almost all applications on Windows ask at the start-up something like "I am not the standard app for file type .xyz. Do you want me to be the default app". Also Microsoft Office does so at start-up of the application. At installation, MS Office even registers itself as default application for OpenDocument file types. Thus, IMHO this bug cannot be closed as RESOLVED -> WONTFIX. Not solving this issue gives LibreOffice a substantial competitive disadvantage.
Actually, after the Windows applications ask whether it should be set as default app for a certain file type, they guide you through the process to set itself as default application. The applications do this very different, please find attached two examples. One screenshot from MS Word and the other screenshot from Adobe Acrobat reader.
Some applications even use an smarter approach to register itself as default, but I cannot remember which application that was.
Created attachment 170519 [details]
PDF: Screenshots of Adobe Acrobat and MS Word, how they guide the user to register itself as default applications for certain file types.
Screenshots of Adobe Acrobat and MS Word, how they guide the user to register itself as default applications for certain file types:
Page 1-2: Adobe Acrobat‘s approach to register itself as default application for file type .pdf
Page 3: Microsoft Word‘s approach to set itself as default application for .docx:
(In reply to Gerry from comment #44)
> Page 1-2: Adobe Acrobat‘s approach to register itself as default application
> for file type .pdf
Yes. This is exactly what they try to disallow. Acrobat doing that does not prove it's correct to do.
> Page 3: Microsoft Word‘s approach to set itself as default application for
First of all: which version is that?
The dialog you see is exactly the one that is described in the blog mentioned in comment 41:
> We have had to do some compatibility work for Classic Windows apps and you
> might see a new dialog box appear in the places where Classic Windows apps
> previously asked you to set your default:
> ... screenshot with the blue banner as on your attachment 170519 [details] page 3 ...
> Over time, as apps are updated to align with the new Windows 10 model for
> defaults, you shouldn’t see this dialog any more.
Moreover, this is exactly the thing that LibreOffice does since tdf#44462.
I have MO Office 2016 installed on the system. It does not show such dialogs.
(In reply to Gerry from comment #43)
> At installation, MS Office even registers
> itself as default application for OpenDocument file types. Thus, IMHO this
> bug cannot be closed as RESOLVED -> WONTFIX. Not solving this issue gives
> LibreOffice a substantial competitive disadvantage.
We should not try to "compete". If MSO does that wrong does not mean we must follow that. We register LO as standard application for ODF. That's enough.
(In reply to Mike Kaganski from comment #45)
> Moreover, this is exactly the thing that LibreOffice does since tdf#44462.
... I meant, it shows that dialog *if user uses the button added there in that bug*, not that it checks associations at startup and shows a dialog. Sorry for being imprecise.
As per https://bugs.documentfoundation.org/show_bug.cgi?id=45735#c4, I was modelling the implementation after Firefox, which on the latest version still performs the default check and launches the Windows settings app for the user if selected. This is done through a public APIs Microsoft provides (IApplicationAssociationRegistration and IApplicationActivationManager), has been stable for several years now, and is documented at https://stackoverflow.com/questions/32178986/windows-10-equivalent-of-launchadvancedassociationui. If Microsoft didn't want applications to do this, they could remove these public APIs. As for the line from the blogpost in https://bugs.documentfoundation.org/show_bug.cgi?id=45735#c41, that is only referring to the specific prompt shown in the image; this work would not be launching that prompt, but instead directing the user directly to the Windows settings as a convenience rather than only telling them how to get there (or not telling them at all).
(In reply to Matt K from comment #47)
> If Microsoft didn't want applications to do
> this, they could remove these public APIs.
Heh. There are specific changes made by MS in their *multiple *APIs; there are descriptions in the documentation of the related functions, and explicit discussions in the public official blogs; yet people believe that "we have found yet another creative way to do what we were prohibited to do otherwise, and it's still not blocked, means it's the correct thing to do" :-)
> As for the line from the
> blogpost in https://bugs.documentfoundation.org/show_bug.cgi?id=45735#c41,
> that is only referring to the specific prompt shown in the image; this work
> would not be launching that prompt, but instead directing the user directly
> to the Windows settings as a convenience rather than only telling them how
> to get there (or not telling them at all).
Huh? Have you seen tdf#44462 I mentioned to See Also? Have you looked at https://git.libreoffice.org/core/commit/ae71570ee7db0a4a9d237424ed2cc3204e86f136, that uses IApplicationAssociationRegistrationUI::LaunchAdvancedAssociationUI ? Please compare the two screenshots - attachment 155904 [details] and attachment 155905 [details] - to see what specifically was blocked by MS. It is not only the specific dialog that was shown in the blog, it's also the normal per-app associations management. *If* MS wanted to keep it available, it would just adjusted the API that is created to provide access to that functionality (LaunchAdvancedAssociationUI name is telling, right?), instead of using IApplicationAssociationRegistration (with all functionality related to UI removed since W8) and IApplicationActivationManager ("You will normally use this interface in debuggers and design tools"), calling a cryptic app without any *published* documentation (or do you consider Stack Overflow or Mozilla implementation "the official MS documentation"?).
Having said that: I have not blocked your https://gerrit.libreoffice.org/c/core/+/112370, and have provided some feedback there to *help you make it better*. I expect you to simplify it greatly (IMO it's over-engineered currently, with all the checks and functions that duplicate existing API), make sure there's a way to *block* the dialog (e.g., using existing command line switches or configuration options), and make its code shared between the dialog and the button implemented in tdf#44462. Then I do not think it would be impossible to accept it.
(In reply to Mike Kaganski from comment #45)
> > Page 3: Microsoft Word‘s approach to set itself as default application for
> > .docx:
> First of all: which version is that?
The version is MS Word 2016 on Windows 10.
Thanks, it seems that you found some solution in comment #47 and comment #48.
Matt K committed a patch related to this issue.
It has been pushed to "master":
tdf#45735 New UI dialog at app startup to check default file formats
It will be available in 7.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:
Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #50)