Video Screencast Help

How to change the extension of .odt to .docx for Libre Office application?

Created: 20 Jan 2012 | 11 comments

Comments 11 CommentsJump to latest comment

EdT's picture

Rename filename.odt filename.docx

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

Thriymapagan's picture

Hi EdT,

 

Thanks for your update.

I am doing repackage of the Libre Office Application. Requirement is change the extension .odt to docx format default. Whenever we give the save as, the format will be changed automatically(.docx). 

 

thanks,

EdT's picture

It makes a lot more sense when you take the time to explain in detail what you are trying to accomplish.

I am unfamiliar with the Libre Office application, but assuming that there is a user option to change the default extension from .odt to .docx, it is equally reasonable to assume that the user choice will be stored somewhere in HKCU.

What I would recommend is that you use a capture tool to record any registry (and file) changes that occur when the user selects .DOCX as the default file format. Make sure that the options window is closed before performing the second snapshot.

Once you know which registry keys are involved (or what file changes are made - perhaps in an INI or XML file) then you can add these into your package as a self healing operation or an active setup.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

Thriymapagan's picture

Hi EdT,

Yes, Under %APPDATA%\Roaming\LibreOffice\3\user\registrymodifications.xcu, The file only doing the changes. After installing the application, the file and the folder would not displayed. Whenever we launching the application, and doing the changes for requirement (Libre OfficeWriter-Tools Menu-Options-Load & Save- General- Select MS Word 2007 XML) then only the  Registrymodifications.xcu file is displayed. We copied this file and implemented in MST, through Active Setup. It is not working.

 

Thanks

EdT's picture

Have you compared the RegistryModifications.xcu file from different test machines?  There may be other content in this file that is either machine or user specific, so just copying the file is not enough, it also needs to be changed for each situation.

What happens to the .XCU file if you check the settings for the test user after the package is installed and after active setup has run - does it report the correct setting, or is the file re-created?

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

Thriymapagan's picture

Hi,

 

In Administrator also the file is not changed. I have used Active setup. The file is not changed.

EdT's picture

Try logging the install and the active setup process and check whether the changes are being made in the correct location.  At the moment, there is far too little detail in your postings to enable anyone to make a precise diagnosis of your problem.

As another test, try following up the installation of your package with a manual update of the .XCU file before you test the install. If it now works, then at least you know that the necessary changes are correct, and all you then need to do is fix your active setup process. Also do not forget that active setup requires the user to log out and back in again after deployment for the changes to take effect.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

piyushnasa's picture

You need to make sure that your user is able to access the source MSI, from where it was installed at first place, when it is logging in the machine. If suppose you have placed it is another user's desktop, then the Active Setup will not work.

Try to keep it in C:\<somefolder> or on a network location which is accessible by all the users.

Piyush Nasa Altiris Certified Professional (ACP)

http://msiworld.blogspot.com/

EdT's picture

Are you aware that the MSI tables of each install are cached in C:\windows\installer, and from V5 of Windows Installer, the entire MSI is cached ?

As long as the self healing operation calls msiexec <product code> with the required switches, there is no issue with the MSI being found. The only thing you need to consider is placing the user repair components into their own feature to avoid unnecessary repair activity.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

piyushnasa's picture

@EdT,

I am very much aware of what you want to say but are you aware that it still prompts for the source file if not available?

This post will help you understand what I was saying.

http://blogs.msdn.com/b/heaths/archive/2009/02/02/changes-to-package-caching-in-windows-installer-5-0.aspx

Piyush Nasa Altiris Certified Professional (ACP)

http://msiworld.blogspot.com/

EdT's picture

Yes, but of course you can add the cache location to the sourcelist, which the article also alludes to.

However, in the context of this thread, correctly authoring the MSI will avoid calls to the source anyway.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.