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
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.
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.
Last edited by RealisticGraphics; Oct 5th, 2003 at 09:39 AM.
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.
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.