Disable right click popupmenu of textboxes 6

[Crazyf]

hi guys.
I want to disable right click in textboxes. And that's why because i want to prevent the copy paste data from one textbox to another, i have created validations in textboxes, so every textbox has its own validation and i don't want the user copy paste data for one to another textbox. I have had a look at thread222-1070885, the code that refers there disables copy paste from clipboard and popupmenu appears when the user right cliks on the textbox, but i want something more than this, i want when the user right clicks in a textbox not appears the popupmenu. Any suggestions??
Any help will be much appreciated.

Thank you
in advanced

 

[vbSun]

In Textbox's Mouse Down event, check if the user has clicked the rightmouse button (If Button = vbRightButton Then) disable the text box. Show a message box 'Right Click is disabled'. When finished, enable the text box again.

Do not have VB6 around at the moment to test and provide a complete source code.

But whether this solution is in terms with the user experience that your application wants to provide is completely a different topic to discuss.

 

[Crazyf]

In Textbox's Mouse Down event, check if the user has clicked the rightmouse button (If Button = vbRightButton Then) disable the text box. Show a message box 'Right Click is disabled'. When finished, enable the text box again. "
vbsun i don't want to disable the textbox, i didn't mentione this.

 

[Error7]

vbSun, very nice. I like it.

Crazyf, you don't need to disable the text box. I just tried vbSun's idea and it works fine without disabling the text box.


[gray]Experience is something you don't get until just after you need it.[/gray]

 

[SBerthold]

>What exactly are lashes?

Whip lashes - for punishment when someone does something very wrong

 

[Crazyf]

Error7, do you mean just to show a message box that the right click is disabled as additional code, without disable textbox as told vbSun? If yes, really, it is not a bad idea.

 

[Crazyf]

What do you mean something very wrong? I don't understand.

 

[Error7]

Crazyf, yes. I don't think you need to disable the text box.

[gray]Experience is something you don't get until just after you need it.[/gray]

 

[Error7]

Private Sub Text1_MouseDown(Button As Integer, Shift As Integer, X As Single, Y As Single)

If Button = 2 Then
MsgBox "Right Click is disabled"
End If

End Sub

[gray]Experience is something you don't get until just after you need it.[/gray]

 

[Crazyf]

That exactly i did error7.
Thanks much everybody.

 

[SBerthold]

>What do you mean something very wrong? I don't understand.

The way
Clipboard.Clear
was suggested to be used. It should not be used except when the user explicitly wants to clear it, as for reasons which I posted on 20 Jun 07 5:10 and Hypetia posted on 20 Jun 07 5:15

 

[Error7]

for n = 1 to 30

next

[gray]Experience is something you don't get until just after you need it.[/gray]

 

[SBerthold]

lol

 

[vbSun]

LockWindowUpdate can be used to prevent the disabled appearence of textbox.
A custom popup menu can be used in place of a message box.

 

[BobRodes]

Good lord. A few random observations:

< If a user can accurately fill these textboxes
why would these same users start pasting inaccurate data.
If you build it, they will come....

< Clipboard.clear certainly achieves the objective.
Sort of like cutting off one's nose achieves the objective of spiting one's face?

< You still would have the problem when using the keyboard to paste (Shift-Ins and Ctrl-V).
Interestingly, I tried this yesterday, and found that when I put in this code

Private Sub Text1_Keypress(KeyAscii As Integer)
Select Case KeyAscii
    Case 48 To 57
    Case Else
        KeyAscii = 0
End Select
End Sub

Shift-Ins allowed the insert and Ctrl-V didn't. On further investigation, it's because KeyAscii gets set to 22 in the latter case. Trapping KeyDown should be the way to solve this.

>I think using the Change Event ...
So long as you're aware of all the times the Change event fires. Personally, I've always had trouble with the change event firing when I didn't want it to, like when loading the form, when programmatically setting the Text property of a box, whatever. I've generally taken the lazy way out and used a flag to ignore the event when I don't want to handle it.

I personally wouldn't disable the right click button for the same reasons that I've metioned already. Right clicking for a popup menu is part of the way that users use Windows, and interfering with that causes negative user acceptance overhead. ("Negative user acceptance overhead"...I like that! Geekspeak adds to its semantic lexicon...)

Another star for Hypetia.

Interesting thread.

Bob

 

[Error7]

> Right clicking for a popup menu is part of the way that users use Windows

Bob I agree to some extent but quite a number of websites disable right clicking. You may say that that isn't the same thing but to the user the interface is the interface, no matter what the operating system.

And no matter which way you achieve it, blocking the pasting of text into a text box goes against what people expect in a Windows environment.

[gray]Experience is something you don't get until just after you need it.[/gray]

 

[BobRodes]

I don't say it isn't the same thing (of course it isn't, though ), I say that it's not a good idea even though people do it. However, I could be being overly conservative there. Perhaps that's just what the kids are doing now...seriously, I think the reason that I've found that people do that is to make it harder for people to copy pictures off the internet. Also, if you look at standard UI behavior in the ASP.Net world, you'll find that people aren't doing this sort of thing so much, given that the UI capabilities there are as strong as the non-web-based ones. In fact, IE is becoming the standard UI container for pretty much all mid tier applications. ASP.Net/IE is the architectural UI standard in our company, for example. Forms are falling by the wayside.

As for your latter point, I've already addressed that by saying (in different words) that there are considerations that justifying overriding the standard UI, and data integrity and security is one of them. So my point is that a user shouldn't have the Undo capability and the Copy capability disabled in the popup menu just because you want to disable the Paste capability.

Ok?

Bob

 

[Crazyf]

Bob what do you mean saying that the Change event fires?
You are right that Ctrl-V doesn't allowed with select case event i realized it when i ran it. Well, your opinion is just to suppress the paste as in Hypetia's code thread222-1070885: Disable Paste function? Finally, i think that's the best solution, if i well understood it wouldn't be friendly to the user to disable right click menu and maybe would caused problems.

 

[SBerthold]

>So long as you're aware of all the times the Change event fires...I've generally taken the lazy way out and used a flag to ignore the event when I don't want to handle it.

Yes and yes.

The Change event fires for each change, but so does the KeyDown or KeyPress when a key is hit.
Any change of the edit box's contents needs validation, (except maybe when changed programically), which will also fire each time the KeyDow/KeyPress is fired, unless you are willing to settle for the Validate event. Using a flag is what I do to keep it from firing when setting the edit box to a value programically.

This should be no problem to validate the basics in the Change event, and you take care of code for this in the KeyDown and KeyPress.
What about all the code are you going to need to take care of any keys presses, context menue, Ctrl-V and Shift-Ins?

>Trapping KeyDown should be the way to solve this.
Nope. Not for Shift-Ins.
And, also, as you said, you usually do not just want to prevent these all together, but be able to first validate the clipboard contents and then allow/dis-allow the paste.

 

[BobRodes]

>Nope. Not for Shift-Ins.

Why not?

 

[Error7]

Ok Bob

[gray]Experience is something you don't get until just after you need it.[/gray]