Context
Currently I am developing a Word add-in that uses the new Javascript API's for Office. The add-in consists of some basic functionalities and a number templates. The templates (plain documents) automatically opens a taskpane when the document is opened. I have followed the following guide to achieve this. Manually adjusting the OOXML (webextensions) did not result in the desired effect. Fortunately, I was successful with implementing the automatically opening taskpanes via the API functions offered in Office.js
The Problem
The add-in manifests are hosted on the local filesystem (C:\AddInManifests). When a document is created and is adjusted to automatically open a taskpane on opening, it works only on the computer where it is created. More specifically it only works on the computer where the client side API methods are called to specify that the document has an automatically opening taskpane.
My suspicion is that it sees the add-ins of the two different computers as two different add-ins entirely. I am looking for way to overcome this, if it is possible to overcome.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<we:webextension xmlns:we="http://schemas.microsoft.com/office/webextensions/webextension/2010/11" id="{C3B1DD62-B056-4FA5-BF7F-5F3800D7C339}">
<we:reference id="4a53b5db-f60a-4c32-82ee-2cf3f4954538" version="1.0.0.1" store="\\.\C:\AddInManifests\" storeType="Filesystem"/>
<we:alternateReferences/>
<we:properties>
<we:property name="Office.AutoShowTaskpaneWithDocument" value="true"/>
</we:properties>
<we:bindings/>
<we:snapshot xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships"/>
</we:webextension>
EDIT
My suspicions seems validated. These problems do not arise when centralized deployment is used. So my presumption is that the manifests on a local harddisk will be seen as a different add-in on a different computer even though the manifest is located on the same location.
Settings like AutoOpen are specific to the manifest ID. For example, settings applied to a document via side-loaded add-in will not be seen when that add-in is published via Office Store (different manifest ID).
Related
I am trying to build a task-pane add-in for word online which can do mail merge like desktop office. Now I understand that word online does not support mail merge out of the box, so I thought about the following steps -
Create a template (DOTX) using desktop office which will contain Region or something like a merge field etc. Upload the template to one drive.
Open a blank doc and add a task pane add-in in word online. This is temporary step for now.
Click a button on the add-in.
This click will stream the template (DOTX) from server using an app service call.
Render the stream into word online web page.
Edit and save.
Close word online and reopen.
Click the doc link.
This will render the doc in word online.
Add the add-in in the task pane (temp step).
Click edit button.
Call app service to fetch the latest merge data source.
Traverse through the word xml and replace the values corresponding to the region or special keys.
Re-render the doc.
My users will have E1 subscription of office 365.
Is this thought process logical and achievable with word online? Thanks in advance!...
I think your approach is much more complicated than it needs to be. Word Online supports Add-ins created using the JavaScript APIs, as supported by the information in this article: https://msdn.microsoft.com/EN-US/library/office/dn833104.aspx
It should be possible for you to create the "template" on the Desktop (Word 2013 or 2016 is required - but only 2016 supports the current full scope of the JS API) and "insert" your add-in, which links it to the document. Opening the document in Word online should automatically load the add-in, that can then link to the data source and fill in the data.
As data targets ("merge fields"), I recommend you use Content Controls.
We have an existing web application written in Java. We want to give our users the ability to open a Word document that is stored in our application on the server. So when the user downloads the document from our server, Word pops up and they then can edit this document on the client. Once finished editing the document we would like to give them the ability to save this document automatically back to the server where they retrieved it, by simply selecting on the Word Save icon. Similar to how SharePoint does it.
Seems to me SharePoint would be a good solution for this and they do it very well, but unfortunately we cannot use SharePoint in our architecture.
There also seems to be a lot of server-side possibilities that we can use to upload and open word documents from our server, I feel we can solve these use cases easily.
My big problem is the automatic saving of an edited document by the client back to our server where the document was downloaded
I am not Microsoft proficient to know what the best solution would be.
Should we write a Word AddIn to save to our server?
How do we get the Word AddIn into our users desktops?
Can we embed a Word AddIn into the Word document that is opened on the client?
1.Should we write a Word AddIn to save to our server?
If you don't want to use SharePoint you can develop an add-in where you can implement all the required functionality and much more.
2.How do we get the Word AddIn into our users desktops?
You can develop an installer for the add-in. See Deploying an Office Solution for more information. Also you can use the group policy objects for deploying the software automatically.
3.Can we embed a Word AddIn into the Word document that is opened on the client?
You can develop a document-level add-in, i.e. the code will be run for a specific document only. But you will need to install it as an application level add-in. See Architecture of Document-Level Customizations for more information.
I have looked for a solution to this but all I have found are products that are close but not what I need.
We have a program that creates a word document on the fly based on data from our database, and stores it on our server, then the user can download this file to print,email,file away.
I need something that will allow the user to open the existing document from the server, edit it, and save it back to the server.
I need this to be able to work on all browser, so activex isn't a full solution.
This link is a proof of concept of using CKEditor to do what you describe.
The focus is on ensuring that the "long tail" of possible docx content is preserved across the editing process.
For example, take a look at the Microsoft demo docx, which they use to compare their web apps with Google Docs, at
google-documents-vs-word-web-app
I have a section of a web application I’m working on where there are mail merge templates. The documents are word documents. When a user has need to edit the template I’d like them to be able to simply click edit, which would cause word to load with the document loaded. When the user is done, they click save in word and the web page spots the change in the file and pushes this back to the server.
I managed to create a VBScript in a web page that could do all of this, but only when internet explorers security was turned down. The fact that I’m using VBScript to automate is not good as it restricts the browser choice and I’m not happy asking my users to turn their security down.
I don’t want the users to download the file, edit it, save it to their local machine and then upload it back to the server, it’s all very clunky. I also know that there are 3rd party controls that allow editing in a page, but I'd rather avoid them if I can.
Is there an alternative way of approaching this?
You can use Office Open XML to generate the word documents on the Server Side. There is an msdn article, sorry no time to go searching for it, explaining why you should not automate office from web servers using COM/DCOM because of security issues involving shared memory.
you could use google docs API, which is certainly more universal than using proprietary technology that works in one and only browser (IE).
I think you can go for the google docs API. It is more generic solution to go for too.
It is possible, with browser-security caveats, to open Word documents for edit from a browser via an UNC path on an internal network.
The best option currently is to WebDAV enable your website, and use the SharePoint plug-in client-side to open the file in Word over WebDAV.
The SharePoint plug-in for IE gets installed when you install Office. There is also a plug-in for Firefox/ Chrome referred to as NPAPI. Beware NPAPI seems to have an issue with long URL paths.
IT Hit make a terrific framework for WebDAV enabling a .NET-based website, see http://www.webdavsystem.com/. They also sell a client-side library that can open Word documents via Java instead of the plug-ins mentioned above. IIS has it own, more basic, WebDAV capability that you can use too.
I am not familiar with non-.Net / Apache solutions but just search for WebDAV products.
Office will require the use of HTTPS for editing via WebDAV.
I am planning to implement a small in-house document management system. It must have a web GUI for managing a remote folder structure stored in a database. In these folders are word documents stored (physically as blob in a database). Whenever a user clicks on a document link, a word binary is downloaded via browser and (hopefully) opened in Word on the user's PC.
This is the easy part ;)
Now the user hits "Save" or Ctrl-S. I want to have a functionality programmed inside Word that calls a custom function (maybe in a .NET DLL) that uploads the saved file back to the server (HTTP). The hard part seems to me:
How to intercept the Save process to call the extension functionality
How to deploy this to multiple users
Mike's link to the question I answered should do it for intercepting the file save. The specific button idMso for File->Save is "FileSave"
To deploy it to several users machine you can either
Create a setup project that will create an msi that you can run on all the users machines
if it's an intranet scenario, you can keep the assemblies on a network location and just add the neceassary registry settings to all the users machines. This article should describe the settings that you need to include. You would just need to change the path setting to point to the network location.
AFAIK, this is what Alfresco is doing with its Microsoft Office Add-ins (never tested myself though). As Alfresco is open-source, it must be possible to look at what they are doing. Or just ask your questions on Alfresco's forums.
You can try to override "save" from the ribbon or build your own ribbon tab with the behavior you want. It may be trickier overriding "Ctrl-S".
Overriding the ribbon: StackOverflow Question
Video on altering a standard ribbon button: Office Developer Center