CtrlV Shortcut causes a conflict with a Paste Menu Item

I have a form with a Menu Item, that I call "mnuPaste" that has a CtrlV shortcut associated to it.   On this form I have a TextEntry control.  If you try to paste text into the TextEntry control by hitting Ctrl-V, it will not paste because the Ctrl-V gets consumed by the mnuPaste Menu Item.

Now I still haven't found the perfect solution.  Ideally I would like the innermost control to have precedence.  So first TextEntry gets the Ctrl-V, then if we are not on the TextEntry control,  the Form's mnuPaste has precedence.  However, I can't seem to get this going.

The best I can do is direct the Ctrl events to the ActiveControl like this:

In the Form declare this function:

Private Declare Auto Function SendMessage Lib "user32" ( ByVal hwnd As IntPtr, ByVal wMsg As Integer, ByVal wParam As IntPtr, ByVal lParam As IntPtr ) As IntPtr

Then overide ProcessCmdKey in the Form:

Protected Overrides Function ProcessCmdKey(ByRef msg As System.Windows.Forms.Message, ByVal keyData As System.Windows.Forms.Keys) As Boolean
  SendMessage(Me.ActiveControl.Handle, msg.Msg, msg.WParam, msg.LParam)
End Function

You can also use this type of call to send Ctrl from the MDI Parent to the Child form.  In that case you would replace Activecontrol with ActiveMdiChild.

Initialize an array

This might seem very simple, but for some reason I forgot how to initialize an array in vb.net

In C++ you would do something like this:
int values[] = {1,2,3}

But I couldn't remember how to do it in VB.NET.
Anyways, below is how one would do it:

Dim values() As Integer = {1, 2, 3}

sender or eventSender object, what is the point?

When looking at the MouseMove problem, I wandered over to the first argument passed to MouseMove, MouseDown, etc.

sender as System.Object (sometimes referred to as eventSender as System.Object).

What was the point of this this?  We never used it in our code, so why was it being passed?

From this article - http://www.informit.com/articles/article.aspx?p=102148&seqNum=3 I realized that you can use that argument to figure out the who called the function.  For example, if you have the MouseDown handle the call from 10 buttons, you can use the sender object to figure which button called the MouseDown routine.  What you need to do is convert (cast) it to an Control or a Button, and then you can get the Button's text.

Another use I found for this is if you manually call MouseDown, or manually call MouseMove.  In that past if we called a MouseMove event from the MouseDown routine, we just passed the sender from MouseDown to MouseMove.  Sample code below:

    Private Sub Form1_MouseDown(ByVal sender As Object, ByVal e As System.Windows.Forms.MouseEventArgs) Handles MyBase.MouseDown
        Form1_MouseMove(sender, e)
    End Sub

At first I thought in MouseMove, we could use the sender object to see if the routine was called by code or by the Form.  But in MouseMove, when you look at the sender object, you cannot tell.  So one way to tell is do something like this:

    Private Sub Form1_MouseDown(ByVal sender As Object, ByVal e As System.Windows.Forms.MouseEventArgs) Handles MyBase.MouseDown
        Form1_MouseMove("FromMouseDown", e)
    End Sub

Then in MouseMove, you can do the following:
    Private Sub Form1_MouseMove(ByVal sender As Object, ByVal e As System.Windows.Forms.MouseEventArgs) Handles MyBase.MouseMove
        If TypeOf sender Is String Then
          'Do Something, you can even test what the string value is
          Dim aString as String = DirectCast(sender, String)
             If aString = "FromMouseDown" Then
                MsgBox("FromMouseDown")
             End If
        End If
    End Sub

MouseMove put to rest

Ok, the problem initially seemed to be because of my trackball mouse.  After putting a workaround where i saved the position of the mouse in mousedown and in mousemove checked to see if the position was different, I just cleaned my trackball, and lo and behold the problem went away.  It seems that because my trackball was dirty, the mousemove event kept getting called, even though the position wasn't changing.

MouseMove oddity

So far the previous problem only occurs on my machine.  I have a trackball mouse, and this only occurs on my machine.  On a machine with a regular mouse, this does not occur.  Now it just might be my trackball mouse.

MouseMove event is always fired

I've always coded with the idea that the MouseMove event in VB.NET occurs when the mouse actually moves.  However, maybe its my machine, but I created a new project.  Added a MouseMove event to the form, with a Debug Statement.  This debug statement is always called, even when my mouse is not moving.  Odd.  I'm using .NET 2003.  The problems this causes are many if you assume the mousemove event should only be called when the mouse is actually moving.

Textbox ignores the first character if you set the CharacterCasing property in the KeyPress event

I had this situation where I had a Textbox on a Form, and in the KeyPress event, I set the CharacterCasing to either Upper or Lower depending on the field I was working on.  The problem I had was that the first character was getting ignored.  It turned out that the problem was that for some reason setting the CharacterCasing in the KeyPress event causes you to lose the first character.  The solution was to move the CharacterCasing block to the TextBox.Enter event. 

To recreate this error, open a form, add a textbox to the form.  Create a Keypress Event, and set the TextBox's CharacterCasing to True.  If you run the program and click in the textbox, and enter a value, the first value will be ignored.

The solution was to move it to the TextBox.Enter subroutine.