|
Simon Hewitt
Guest
|
I have released an Office Add-in using v6.4.3056 and the Version Neutral interops.
In AddinInitialize I write some info to a log like this:-
logger.Log("Active Printer Name", App.ActivePrinter == null ? "(null)" : App.ActivePrinter.Length == 0 ? "(empty)" : App.ActivePrinter, LogLevel.Debug);
(where App is ADXAddinModule.HostApplication cast as the appropriate _Application - ie Word/Excel/PowerPoint)
This works fine for Office 2003/2007/2010 except Word 2010 when a document is opened that causes Protected Mode to kick in. A COMException is thrown which says "This command is not available." (the few other App properties I log still work fine)
This only happens in Word 2010 with protected mode - PowerPoint 2010 and Excel 2010 still work as expected opening protected documents.
Q1) Is this a bug in Add-in Express or in Word 2010? Are there any other known properties which need to be carefully handled under protected mode.
Whilst tracking this down, I tried to use the ProtectedViewWindowOpen and ProtectedViewWindowActivate events. The latter only seems to fire when I click on the protected document but the former does not fire at all.
Q2) Is there are problem with ProtectedViewWindowOpen?
I noticed that Office 2010 documents an "IsSandboxed" property on _Global. I can't see this anywhere within Add-in Express.
Q3) Is this not implemented and if so, which other 2010 interop items are missing - is there a list?
Q4) As well as being a workaround for the bug I was also hoping to use this to disable my Ribbon command to match all the other built-in commands (luckily, clicking on it doesn't cause a crash and does nothing!). How could I best do this?
My ultimate aim is to be able to intercept the opening of documents BEFORE any protected mode actually displays them. My add-in checks whether a user is allowed to see a document and throws up a full screen dialogue if they are not. Protected Mode messes this up because they can view the document before I can get control (ie after they click Enable Editing)
Q5) How can I get a lower-level of detecting the opening of a document and/or detect when a protected view is about to be displayed?
Cheers
Simon
PS - Q6) When are you going to remove '2005' from the names of your DLLs??? It is very confusing! |
|
|
Eugene Astafiev
Guest
|
Hi Simon,
Q1: It looks like this is a bug in Word. Moreover, I was able to reproduce the issue with a regular VSTO based add-in (without Add-in Express involved).
Q2: Nope. You can try to use the ProtectedViewWindowOpen event of the Application class in Word instead.
Q3: Do you mean the IsSanboxed property of the Application class? Anyway, please take a look at the Word.Global interface. Is it what you are looking for?
Q4: Unfortunately the Ribbon UI doesn't allow disabling built-in controls. Instead, you can hide the entire tab and show the required built-in controls on your own. You can read more about this in the http://msdn.microsoft.com/en-us/library/aa338202%28v=office.12%29.aspx article in MSDN.
Q5: Please try to use the ProtectedViewWindowOpen event of the Application class instead. Does it help?
Q6: We keep 2005 numbers for compatibility purposes. These numbers will be removed as soon as we decide not to support Visual Studio 2005. |
|
|
Simon Hewitt
Guest
|
Q1) Good - thought as much.
Q2) ProtectedViewWindowOpen - got this firing but it turns out it only happens after the user selected Edit. No good to me.
Q3) That is the property I was looking for but I couldn't see on the Version Neutral Interops which I thought were a superset of all versions. I have used late-binding and can access the property but unfortuntely it seems to always return false.
Q4) Not sure what you mean by this. The built-in controls are already disabled when opening a protected document. In my app, if I open a protected document and then click on the Review ribbon then everything is disabled except my single ribbon group containing a single ribbon button.
Q5) That event fires a bit too late - the document is visible and the user has to click Edit before it fires.
I did have a little success using late binding within Initialize to enumerate ProtectedViewWindows and to call Close() on each one found.
However I have come to the conclusion that the Initialize event is a bit flakey when protected mode is on. It also doesn't help with subsequent opens because Initialize doesnt fire again.
I need a foolproof way to catch all methods of opening a document (e.g. double-clicking on a webmail attachment which I assuming is passing the doc name via the command line; File Open, Dragging a doc onto the app and any others I may have missing).
I need to inspect the doc before (or immediately as) it is visible to the user so I can decide whether the user had to confirm they are authorised to see it.
Any help with this gratefully received.
Cheers
Simon |
|
|
Eugene Astafiev
Guest
|
|
Forums
Topics
Search
Help
Login
Register