VB - Intercepting Paste Command on RichTextBoxes

This code will show you how to intercept the Paste command that is sent to the RichTextBox control (RTB).

Now you may ask why you would need this... If you create a menu for Pasting and give it a shortcut key of Ctrl+V. Then when you paste to a RTB you get double whatever you had on the clipboard if you used Ctrl+V. The data on the clipboard will also paste as whatever Format it is in instead of plain text (in my case, I needed it to always be in plain text).

As I discovered, the RTB does NOT except the WM_PASTE message (as well as WM_COPY & WM_CUT). After hours of trying to figure out what message it was receiving, I came up with the code below.

Module:

VB Code:

Public Declare Function CallWindowProc Lib "user32" _
Alias "CallWindowProcA" _
(ByVal lpPrevWndFunc As Long, ByVal hwnd As Long, _
ByVal msg As Long, ByVal wParam As Long, _
ByVal lParam As Long) As Long
 
Public Declare Function SetWindowLong Lib "user32" Alias _
"SetWindowLongA" (ByVal hwnd As Long, _
ByVal nIndex As Long, ByVal dwNewLong As Long) As Long
 
Public lOldWinProc As Long
 
Public Const GWL_WNDPROC& = (-4)
Private Const WM_KEYDOWN = &H100
Private Const WM_PASTE = &H302
 
Public Function WndProc(ByVal hwnd As Long, _
ByVal uMsg As Long, ByVal wParam As Long, _
ByVal lParam As Long) As Long
 
Dim bCompleted As Boolean
bCompleted = False
 
Select Case uMsg
    Case WM_KEYDOWN
        Select Case wParam
            Case vbKeyV
                bCompleted = True
            Case vbKeyC
                bCompleted = True
            Case vbKeyX
                bCompleted = True
        End Select
    Case WM_PASTE
        MyPaste
        bCompleted = True
End Select
 
If bCompleted = False Then
    WndProc = CallWindowProc(lOldWinProc, hwnd, uMsg, wParam, lParam)
End If
End Function
 
Public Sub MyCopy()
Clipboard.SetText Form1.RTB.SelText, vbCFText
End Sub
 
Public Sub MyCut()
Clipboard.SetText Form1.RTB.SelText, vbCFText
Form1.RTB.SelText = ""
End Sub
 
Public Sub MyPaste()
Form1.RTB.SelText = Clipboard.GetText(vbCFText)
End Sub

As you can see I've created my own Cut, Copy, & Paste procedures to take over for the normal ones. In the procedure I'm using to intercept the commands you'll see WM_KEYDOWN. What this message tells us is that the Control key is pressed. If it is pressed, we then check wParam. wParam is the KeyCode for the key that is being pressed along with the Control key.

If we determine that Ctrl+C, Ctrl+X, or Ctrl+V is being pressed them we set bCompleted = True so that the commands will not be given to the RTB and our new commands will.

In a Form named Form1 with an RTB named RTB:

VB Code:

Private Sub Form_Load()
lOldWinProc = SetWindowLong(RTB.hwnd, GWL_WNDPROC, AddressOf WndProc)
End Sub
 
Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
SetWindowLong RTB.hwnd, GWL_WNDPROC, lOldWinProc
End Sub
 
Private Sub mnuCopy_Click()
MyCopy
End Sub
 
Private Sub mnuCut_Click()
MyCut
End Sub
 
Private Sub mnuPaste_Click()
MyPaste
End Sub

In the Form_Load and Form_QueryUnload event we Hook/Unhook the RTB. This just tells the RTB to use our new procedure instead of the default one first. The menu code should be pretty straight forward.

I've attached a copy of a project that shows this code in action.

VB Code:

Public Function WndProc(ByVal hwnd As Long, _
ByVal uMsg As Long, ByVal wParam As Long, _
ByVal lParam As Long) As Long
 
    If uMsg = WM_KEYDOWN And (wParam = vbKeyV Or wParam = vbKeyC Or wParam = vbKeyX) Then Exit Function
    If uMsg = WM_PASTE Then
        MyPaste
        Exit Function
    End If
 
    WndProc = CallWindowProc(lOldWinProc, hwnd, uMsg, wParam, lParam)
End Function

select case isn't as efficient as if then statements, also it might be better coding practice :confused:

:D

Unless I'm mistaken the Select Case is more memory efficient and if nothing else if is generally easier to go back and add more conditions.

You may be right but either way works and I like the structure of the select case better when I'm reading code.

For instance this part of your code:

wParam = vbKeyV Or wParam = vbKeyC Or wParam = vbKeyX

Each Or is checked. Even if wParam=vbKeyV I believe that each "or" after it is still checked. Whereas on a select case statement it only checks until it finds a match. I'm sure I read that someplace, I think it was in VSM.

afaik select case is broken down into effectively multiple if... then statements when compiled

VB Code:

Private Declare Function GetTickCount Lib "kernel32" () As Long
 
Private Sub Command1_Click()
Dim StartTimeSelect As Long
Dim StartTimeIfThen As Long
Dim rndVal As Long
 
StartTimeIfThen = GetTickCount()
 
For X = 0 To 10000000
    Randomize
    rndVal = Int((100 * Rnd) + 1)
    If rndVal < 10 Then
        
    ElseIf rndVal < 20 Then
        
    ElseIf rndVal < 30 Then
        
    ElseIf rndVal < 40 Then
        
    ElseIf rndVal < 50 Then
        
    ElseIf rndVal < 60 Then
        
    ElseIf rndVal < 70 Then
        
    ElseIf rndVal < 80 Then
        
    ElseIf rndVal < 90 Then
        
    Else
        
    End If
Next
 
 
 
MsgBox GetTickCount() - StartTimeIfThen
 
 
 
StartTimeSelect = GetTickCount()
 
For X = 0 To 10000000
    Randomize
    Select Case Int((100 * Rnd) + 1)
    Case Is < 10
        
    Case Is < 20
        
    Case Is < 30
        
    Case Is < 40
        
    Case Is < 50
        
    Case Is < 60
        
    Case Is < 70
        
    Case Is < 80
        
    Case Is < 90
        
    Case Else
        
    End Select
Next
 
MsgBox GetTickCount() - StartTimeSelect
 
End Sub

Try running them several times each in their own button. Sometimes one will beat the other one.

You're probably right though, judging from these numbers. But I still swear that I read an article someplace talking about the speed differences and that Select Case was the better choice.

Either way, they both run at about the same speed and the time difference is hardly noticable and either way will work.