Locking things down

[wagaman]

Here is my situation. I need to beable to 100% lock these Office Web
components, while still allowing the user to drill into the data. The
users should not be able to add fields to the chart/pivot table.
Likewise, they should not be allowed to remove fields from the object.
Is this possible, or is it just wishful thinking?

Any help getting this to function as needed would be appreciated .

Tim Wagaman

 

[dpoindexter]

I am also interested in accomplishing this sort of task. In particular
I want to just lock down certain rows and columns. If you find a
answer, please share. Thanks

 

[Alvin Bruney - ASP.NET MVP]

one easy solution is to force read only mode. This would give you some of
the requirements. Read-only mode is a settable property of the object.
Another option is to explicitly disable the access thru code. You need to
pay attention to the cases where menus and keyboard shortcuts can surface
the functionality. For instance, if you require that users not be able to
remove a row in a spreadsheet, use code to remove the "add row"
functionality in the context menu.

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET
-------------------------------------------------------

I am also interested in accomplishing this sort of task. In particular,
I want to just lock down certain rows and columns. If you find an
answer, please share. Thanks!

http://www.officehelp.in/archive/index.php |
http://www.officehelp.in/index/index.php

 

[wagaman]

2 Questions about that:

1. Doesn't Readonlymode only protect the data, not the fields on the
object itself?

2. If my assumption on question 1 is wrong, then how do you go about
forcing readonlymode? That property seems to be read only.

 

[Alvin Bruney - MVP ASP.NET]

Readonly mode enforces the non-interactive requirement. It does not
necessarily limit itself to readonly data.

I was hoping that readonly was not only readonly (that is writable as well)
but it does not seem to be the case. part of the reason for this is that the
code can read this property to determining interactivity and imply licensing
compliance from it. Making the property writable would allow code to subvert
some of the licensing restrictions.

In a nutshell, you would have to go with code that explicitly removes these
features or renders them unusable. Another thing that comes to mind, which
is probably safer, you can catch the event and cancel it. For instance, if
you wanted to prevent export, you would cancel the export event with a
message dialog box explaining why to the user.

--
Regards,
Alvin Bruney

Shameless Author Plug
[The Microsoft Office Web Components Black Book with .NET]
www.lulu.com/owc, Amazon, Barnes & Noble etc
Forth-coming VSTO.NET