How to disable right mouse button in worksheet from .net

[luukas9]

Hello, (sorry for my english)

I have a form with one WebBrowser object. In this object, I load an
Excel document.

I need / want that user can't copy or cut and paste the data of this
worksheet.

I'm trying to disable the right mouse button but only do it the first
time that I debug the proyect. The Code is this:

The axWBExcell is the WebBrowser object.

private void axWBExcell_DocumentCompleted(object sender,
WebBrowserDocumentCompletedEventArgs e)
{
Microsoft.Office.Interop.Excel.Application xlsApplication
=

(Microsoft.Office.Interop.Excel.Application)System.Runtime.InteropServices.Marshal.GetActiveObject("Excel.Application");

foreach (Microsoft.Office.Interop.Excel.Worksheet sheet in
xlsApplication.Worksheets)
{
if (!sheet.Name.Contains("myString"))
{
sheet.BeforeRightClick +=
new
Microsoft.Office.Interop.Excel.DocEvents_BeforeRightClickEventHandler(WorkSheet_BeforeRightClick);
}
}
}

protected void
WorkSheet_BeforeRightClick(Microsoft.Office.Interop.Excel.Range
target, ref bool cancel)
{
MessageBox.Show("This option is disable in this sheet");
cancel = true;
}

Someone have any idea how can i do this??? or why this code only is
success one time?? because if i do the same in a macro of excel, it's
success every time!!

Thanks for your help.

 

[Peter Duniho]

Hello, (sorry for my english)

I have a form with one WebBrowser object. In this object, I load an
Excel document.

I need / want that user can't copy or cut and paste the data of this
worksheet.

If you don't want the user to copy/cut the data from your presentation,
don't offer a presentation of the data that would normally allow that but
in which you've tried to disable the behavior. First, you will annoy the
user (frankly, this sort of thing pisses off lots of users, myself
included).

Second (and perhaps more compelling to you), you will not succeed in
completely disabling the behavior anyway; some user will get past your
attempt, because the data is really there waiting to be copied from the
presentation (the Excel spreadsheet in this case). Filtering right-clicks
is a really weak way to block copying (I haven't bothered to try to defeat
the exact method you're using here, but I regularly bypass it in other
contexts). It is _only_ annoying, and won't accomplish what you want.
The worst of both worlds.

If you want to present an Excel document that the user cannot copy data
from, use Excel's application interface to copy the spreadsheet to a
bitmap or metafile (see, for example, the Range.CopyPicture() method), and
then present _that_ to the user. The bitmap is more secure, but the
metafile will perform better (use less memory...though for a reasonably
small spreadsheet that may not matter).

In either case, it would still be theoretically possible for the user to
copy data (bitmap would require OCR, metafile has text embedded so if the
user can somehow get it to a tool that will extract the text, they've
still got the data), but in both cases the effort to get at the data would
be _much_ greater than that required to bypass whatever right-click
filtering you attempt. It will be simpler for the user to just get a
screen-shot and/or hand type the data in somewhere else (to name a couple
of techniques that you'll never be able to stop).

Doing it this way, the user also will never see something that _looks_
like they ought to be able to select and copy and paste but can't (keeping
in mind, of course, that if the spreadsheet is anywhere on the user's
computer, they _can_ get to it somehow...the goal here is just to not do
something that is so completely dumb as to require practically no effort
to bypass but still annoy the user ).

And if for some reason it's important to you that the user be able to
interact with the spreadsheet as an actual spreadsheet (select cells,
format them, etc.) then for crying out loud, stop trying to get in the
user's way when they want to use the context menu.

The last thing this world needs is yet another piece of software that
presumes it has more rights to the user's data than the user has (and make
no mistake...if the data is sitting there in front of the user, having
been delivered to his computer, it's _his_ data now, no matter where it
came from originally).

Pete

 

[luukas9]

Ok pete,

Thanks for your response.

Obviously that if I present the data in any format, the user can copy
theese data anyway... by print screen or whit a pen... even if I show
them from a bitmap!

The question isn't the security of theese data. If the security was
the important in this application, I'll develop different profiles
with different users.

The question is if is posible to disable the right click button in
this object. So your answer not response my question.

 

[luukas9]

Perhaps, it can be a solution:

http://msdn2.microsoft.com/en-us/library/aa741313(VS.85).aspx

I'm not probe it yet.

 

[DeveloperX]

Perhaps, it can be a solution:

http://msdn2.microsoft.com/en-us/library/aa741313(VS.85).aspx

I'm not probe it yet.

If you disable the context menu, what's to stop the user simply
selecting a range and pressing CTRL + C?

 

[luukas9]

If you disable the context menu, what's to stop the user simply
selecting a range and pressing CTRL + C?

Yes, you were right. That is why I need handle the keyboard events
too. but this is another question.

thanks for your response.

 

[Peter Duniho]

[...]
The question is if is posible to disable the right click button in
this object. So your answer not response my question.

Not true. It definitely was a _response_ to your question. It may not
have _answered_ the specific question you asked, but it was definitely a
response, and IMHO it was a more useful one than had I actually answered
the question.

I think it's especially interesting that you say the security of the data
is not at issue here. If not security, then what? Securing the data is a
fairly weak justification for what you're trying to do, but it's still one
of the most compelling reasons. Any other reason just makes the user
annoyance even more offensive.

I have seen lots of software that makes an attempt to block mouse
right-clicks. I've never seen any attempt that worked reliably, and I
have also never seen such an attempt done in a context where there was
actually any valid reason to do so.

I suppose there's a chance that after all these years, you're the one guy
who's come up with the one valid scenario to restrict and annoy your users
in this way, as well as who will be able to discover a previously unknown
technique for doing so reliably. Miracles can happen. But the odds
aren't in your favor.

Pete

 

[luukas9]

I suppose there's a chance that after all these years, you're the one guy  

who's come up with the one valid scenario to restrict and annoy your users 
in this way, as well as who will be able to discover a previously unknown  
technique for doing so reliably.  Miracles can happen.  But the odds  
aren't in your favor.

Ok pete... how to explain you this...

Logically if I develop a new application the first that I analize is
the security data...
But if "someone" requieres that you must do anything even advising him
that is preferable doing it in another way... What can we do? :S

I must to do it, not I want to do it... ok?

ALL in this life is possible... don't forget it

 

[luukas9]

Hello

I try another solution... I can disable the copy and cut options at
context menu:

private void webBrowser1_DocumentCompleted(object sender,
WebBrowserDocumentCompletedEventArgs e)
{
//retry excel application object
Microsoft.Office.Interop.Excel.Application xlsApplication
=

(Microsoft.Office.Interop.Excel.Application)System.Runtime.InteropServices.Marshal.GetActiveObject("Excel.Application");

xlsApplication.CommandBars["Cell"].Controls[1].Enabled =
false;
xlsApplication.CommandBars["Cell"].Controls[2].Enabled =
false;
xlsApplication.CommandBars["Column"].Controls[1].Enabled =
false;
xlsApplication.CommandBars["Column"].Controls[2].Enabled =
false;
xlsApplication.CommandBars["Row"].Controls[1].Enabled =
false;
xlsApplication.CommandBars["Row"].Controls[2].Enabled =
false;
}

Thanks, good bye

 

[luukas9]

Yes, you were right. That is why I need handle the keyboard events
too. but this is another question.

thanks for your response.

xlsApplication.OnKey("^c", "");
xlsApplication.OnKey("^x", "");
xlsApplication.OnKey("+{DEL}", "");
xlsApplication.OnKey("^{INSERT}", "");